text:
RFC 2768 - Network Policy and Services: A Report of a Workshop o
[ RFC Index | Usenet FAQs | Web FAQs | Documents | Cities | People Search | Restaurant inspections ]
Network Working Group B. Aiken Request for Comments: 2768 J. Strassner Category: Informational Cisco Systems B. Carpenter IBM I. Foster Argonne National Laboratory C. Lynch Coalition for Networked Information J. Mambretti ICAIR R. Moore UCSD B. Teitelbaum Advanced Networks & Services, Inc. February 2000 Network Policy and Services: A Report of a Workshop on Middleware Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Contextual Framework . . . . . . . . . . . . . . . . . . . . 3 2.0 What is Middleware? . . . . . . . . . . . . . . . . . . . . 4 3.0 Application Perspective . . . . . . . . . . . . . . . . . . 6 4.0 Exemplary Components . . . . . . . . . . . . . . . . . . . . 7 5.0 Application Programming Interfaces and Signaling . . . . . . 8 6.0 IETF AAA . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.0 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.0 Directories . . . . . . . . . . . . . . . . . . . . . . . . 12 9.0 Resource Management . . . . . . . . . . . . . . . . . . . . 15 10.0 Networked Information Discovery and Retrieval Services . . . 17 11.0 Network QOS . . . . . . . . . . . . . . . . . . . . . . . . 18 12.0 Authentication, authorization, and access management . . . . 21 13.0 Network Management, Performance, and Operations . . . . . . 22 14.0 Middleware to support multicast applications . . . . . . . . 23 15.0 Java and Jini TM . . . . . . . . . . . . . . . . . . . . . . 24 16.0 Security Considerations . . . . . . . . . . . . . . . . . . 24 17.0 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 24 18.0 Participants . . . . . . . . . . . . . . . . . . . . . . . . 26 19.0 URLs/references . . . . . . . . . . . . . . . . . . . . . . 27 20.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27 21.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . 29 Introduction This document describes the term "middleware" as well as its requirements and scope. Its purpose is to facilitate communication between developers of both collaboration based and high-performance distributed computing applications and developers of the network infrastructure. Generally, in advanced networks, middleware consists of services and other resources located between both the applications and the underlying packet forwarding and routing infrastructure, although no consensus currently exists on the precise lines of demarcation that would define those domains. This document is being developed within the context of existing standards efforts. Consequently, this document defines middleware core components within the framework of the current status of middleware-related standards activities, especially within the IETF and the Desktop Management Task Force (DMTF). The envisioned role of the IETF is to lead the work in defining the underlying protocols that could be used to support a middleware infrastructure. In this context, we will leverage the information modeling work, as well as the advanced XML and CIM/DEN-LDAP mapping work, being done in the DMTF. (The recently constituted Grid Forum is also pursuing relevant activities.) This document also addresses the impact of middleware on Internet protocol development. As part of its approach to describing middleware, this document has initially focused on the intersections among middleware components and application areas that already have well defined activities underway. This document is a product of an ad hoc Middleware Workshop held on December 4-5 1998. The Workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to define the term middleware and its requirements on advanced network infrastructures as well as on distributed applications. These definitions will enable a set of core middleware components to subsequently be specified, both for supporting advanced application environments as well as for providing a basis for other middleware services. Although this document is focused on a greater set of issues than just Internet protocols, the concepts and issues put forth here are extremely relevant to the way networks and protocols need to evolve as we move into the implementation stage of "the network is the computer". Therefore, this document is offered to the IETF, DMTF, Internet2, Next Generation Internet (NGI), NSF Partnerships for Advanced Computational Infrastructure (PACI), the interagency Information Technology for the 21st Century (IT2) program, the Grid Forum, the Worldwide Web Consortium, and other communities for their consideration. This document is organized as follows: Section 1 provides a contextual framework. Section 2 defines middleware. Section 3 discusses application requirements. Subsequent sections discuss requirements and capabilities for middleware as defined by applications and middleware practitioners. These sections will also discuss the required underlying transport infrastructure, administrative policy and management, exemplary core middleware components, provisioning issues, network environment and implementation issues, and research areas. 1.0 Contextual Framework Middleware can be defined to encompass a large set of services. For example, we chose to focus initially on the services needed to support a common set of applications based on a distributed network environment. A consensus of the Workshop was that there was really no core set of middleware services in the sense that all applications required them. This consensus does not diminish the importance of application domain-specific middleware, or the flexibility needed in determining customized approaches. Many communities (e.g., Internet2, NGI, and other advanced Internet constituencies) may decide on their own set of common middleware services and tools; however, they should strive for interoperability whenever possible. The topics in this workshop were chosen to encourage discussion about the nature and scope of middleware per se as distinct from specific types of applications; therefore, many relevant middleware topics were not discussed. Another consensus of the Workshop that helped provide focus was that, although middleware could be conceptualized as hierarchical, or layered, such an approach was not helpful, and indeed had been problematic and unproductive in earlier efforts. The better approach would be to consider middleware as an unstructured, often orthogonal, collection of components (such as resources and services) that could be utilized either individually or in various subsets. This working assumption avoided extensive theological modeling discussions, and enables work to proceed on various middleware issues independently. An important goal of the Workshop was to identify any middleware or network-related research or development that would be required to advance the state of the art to support advanced application environments, such as those being developed and pursued by NGI and Internet2. Consequently, discussion focused on those areas that had the maximum opportunity for such advances. 2.0 What is Middleware? The Workshop participants agreed on the existence of middleware, but quickly made it clear that the definition of middleware was dependent on the subjective perspective of those trying to define it. Perhaps it was even dependent on when the question was asked, since the middleware of yesterday (e.g., Domain Name Service, Public Key Infrastructure, and Event Services) may become the fundamental network infrastructure of tomorrow. Application environment users and programmers see everything below the API as middleware. Networking gurus see anything above IP as middleware. Those working on applications, tools, and mechanisms between these two extremes see it as somewhere between TCP and the API, with some even further classifying middleware into application-specific upper middleware, generic middle middleware, and resource-specific lower middleware. The point was made repeatedly that middleware often extends beyond the "network" into the compute, storage, and other resources that the network connects. For example, a video serving application will want to access resource discovery and allocation services not just for networks but also for the archives and computers required to serve and process the video stream. Through the application of general set theory and rough consensus, we roughly characterize middleware as those services found above the transport (i.e., over TCP/IP) layer set of services but below the application environment (i.e., below application-level APIs). Some of the earliest conceptualizations of middleware originated with the distributed operating research of the late 1970s and early 1980s, and was further advanced by the I-WAY project at SC'95. The I-WAY linked high performance computers nation-wide over high performance networks such that the resulting environment functioned as a single high performance environment. As a consequence of that experiment, the researchers involved re-emphasized the fact that effective high performance distributed computing required distributed common computing and networking resources, including libraries and utilities for resource discovery, scheduling and monitoring, process creation, communication and data transport. Subsequent research and development through the Globus project of such middleware resources demonstrated that their capabilities for optimizing advanced application performance in distributed domains. In May 1997, a Next Generation Internet (NGI) workshop on NGI research areas resulted in a publication, "Research Challenges for the Next Generation Internet", which yields the following description of middleware. "Middleware can be viewed as a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment". This definition could further be refined to include persistent services, such as those found within an operating system, distributed operating environments (e.g., JAVA/JINI), the network infrastructure (e.g., DNS), and transient capabilities (e.g., run time support and libraries) required to support client software on systems and hosts. In summary, there are many views of what is middleware. The consensus of many at the workshop was that given the dynamic morphing nature of middleware, it was more important to identify some core middleware services and start working on them than it was to come to a consensus on a dictionary-like definition of the term. Systems involving strong middleware components to support networked information discovery have also been active research areas since at least the late 1980s. For example, consider Archie or the Harvest project, to cite two examples. One could easily argue that the site logs used by Archie or the broker system and harvest agents were an important middleware tool, and additional work in this area is urgently needed in order to improve the efficiency and scope of web- based indexing services. "As long ago" as 1994, the Internet Architecture Board held a workshop on "Information Infrastructure for the Internet" reported in RFC 1862, which in many ways covered similar issues. Although its recommendations were summarized as follows: - increased focus on a general caching and replication architecture - a rapid deployment of name resolution services, and - the articulation of a common security architecture for information applications." it is clear that this work is far from done. Finally, this workshop noted that there is a close linkage between middleware as a set of standards and protocols and the infrastructure needed to make the middleware meaningful. For example, the DNS protocol would be of limited significance without the system of DNS servers, and indeed the administrative infrastructure of name registry; NTP, in order to be useful, requires the existence of time servers; newer middleware services such as naming, public key registries and certificate authorities, will require even more extensive server and administrative infrastructure in order to become both useful and usable services. 3.0 Application Perspective From an applications perspective, the network is just another type of resource that it needs to use and manage. The set of middleware services and requirements necessary to support advanced applications are defined by a vision that includes and combines applications in areas such as: distributed computing, distributed data bases, advanced video services, teleimmersion (i.e., a capability for providing a compelling real-life experience in a virtual environment based for example on CAVE technologies), extensions with haptics, electronic commerce, distance education, interactive collaborative research, high-rate instrumentation (60 MByte/s and above sustained), including use of online scientific facilities (e.g. microscopes, telescopes, etc.), effectively managing large amounts of data, computation and information Grids, adaptable and morphing network infrastructure, proxies and agents, and electronic persistent presence (EPP). Many of these applications are "bleeding edge" with respect to currently deployed applications on the commodity Internet and hence have unique requirements. Just as the Web was an advanced application in the early 1990s, many of the application areas defined above will not become commonplace in the immediate future. However, they all possess the capability to change the way the network is used as well as our definition of infrastructure, much as the Web and Mosaic changed it in the early 90s. A notable recent trend in networks is the increasing amount of HTTP, voice, and video traffic, and it was noted that voice and video particularly need some form of QoS and associated middleware to manage it. A quick review of the requirements for teleimmersion highlight the requirement for multiple concurrent logical network channels, each with its own latency, jitter, burst, and bandwidth QoS; yet all being coordinated through a single middleware interface to the application. For security and efficiency those using online instruments require the ability to steer the devices and change parameters as a direct result of real-time analysis performed on the data as it is received from the instruments. Therefore, network requirements encompass high bandwidth, low latency, and security, which must all be coordinated through middleware. Large databases, archives, and digital libraries are becoming a mainstay for researchers and industry. The requirements they will place on the network and on middleware will be extensive, including support of authentication, authorization, access management, quality of service, networked information discovery and retrieval tools, naming and service location, to name only a few. They also require middleware to support collection building and self-describing data. Distributed computing environments (e.g., Globus, Condor, Legion, etc.) are quickly evolving into the computing and information Grids of the future. These Grids not only require adaptive and manageable network services but also require a sophisticated set of secure middleware capabilities to provide easy- to-use APIs to the application. Many application practitioners were adamant that they also required the capability for "pass through" services. This refers to the ability to bypass the middleware and directly access the underlying infrastructure such as the operating system or network), even though they were eager to make use of middleware services and see more of it developed to support their own applications. In addition, authentication and access control, as well as security, are required for all of the applications mentioned above, albeit at different levels. 4.0 Exemplary Components In an attempt to describe middleware and discuss pertinent issues relating to its development and deployment, an exemplary set of services were selected for discussion. These services were chosen to stimulate discussion and not as an attempt to define an exclusive set of middleware services. Also, it is the intent of this effort not to duplicate existing IETF efforts or those of other standards bodies (e.g., the DMTF), but rather to leverage those efforts, and indeed to highlight areas where work was already advanced to a stage that might be approaching deployment. 5.0 Application Programming Interfaces and Signaling Applications require the ability to explicitly request resources based on their immediate usage needs. These requests have associated network management controls and network resource implications; however, fulfillment of these requests may require multiple intermediate steps. Given the preliminary state of middleware definition, there currently is no common framework, much less a method, for an application to signal its need for a set of desired network services, including quality and priority of service as well as attendant resource requirements. However, given the utility of middleware, especially with regard to optimization for advanced applications, preliminary models for both quality and priority of service and resource management exist and continue to evolve. however, without an agreed-to framework for standards in this area, there is the risk of multiple competing standards that may further delay the deployment of a middleware-rich infrastructure. This framework should probably include signaling methods, access/admission controls, and a series of defined services and resources. In addition, it should include service levels, priority considerations, scheduling, a Service-Level-Agreement (SLA) function, and a feedback mechanism for notifying applications or systems when performance is below the SLA specification or when an application violates the SLA. Any such mechanism implies capabilities for: 1) an interaction with some type of policy implementation and enforcement, 2) dynamic assessment of available network resources, 3) policy monitoring, 4) service guarantees, 5) conflict resolution, and 6) restitution for lack of performance. Application programmers are concerned with minimizing the interfaces that they must learn to access middleware services. Thus the unification of common services behind a single API is of great interest to middleware users. Examples of common APIs that may be achievable are: * Environmental discovery interface, whether for discovering hardware resources, network status and capabilities, data sets, applications, remote services, or user information. * Remote execution interface, whether for distributed metacomputing applications, or for access to a digital library presentation service, or a Java analysis service. * Data management interface, whether for manipulating data within distributed caches, or replication of data between file systems, or archival storage of data. * Process management interface, whether for composing data movement with remote execution, or for linking together multiple processing steps. 6.0 IETF AAA The IETF AAA (authentication, authorization, and accounting) effort is but one of many IETF security initiatives. It depends heavily on a Public key infrastructure, which is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model). The IETF AAA working group has recently been formed. IETF AAA working group efforts are focused on many issues pertaining to middleware, including defining processes for access/admission control and identification (process for determining a unique entity), authentication (process for validating that identity), authorization (process for determining an eligibility for resource requests/utilization) and accounting (at least to the degree that resource utilization is recorded). To some degree, AAA provides for addressing certain levels of security, but only at a preliminary level. Currently, AAA protocols exist, although not as an integrated model or standard. One consideration for AAA is to provide for various levels of granularity. Even if we don't yet have an integrated model, it is currently possible to provide for basic AAA mechanisms that can be used as a basis to support SLAs. Any type of AAA implementation requires a policy management framework, to which it must be linked. Currently, a well-formulated linking mechanism has not been defined. Middleware AAA requirements are also driven by the distributed interoperation that can occur between middleware services. The distribution of application support across multiple autonomous systems will require self-consistent third-party mechanisms for authentication as well as data movement. Conceptually, an application may need access to data that is under control of a remote collection, to support the execution of a procedure at a third site. The data flow needs to be directly from the collection to the execution platform for efficiency. At the same time, the procedure will need access permission to the data set while it is acting on behalf of the requestor. How the authentication is done between the remote procedure and the remote data collection entities raises significant issues related to transitivity of trust, and will require establishment of a trust policy for third-party mechanisms. This is exacerbated when a collection of entities, such as is required for visualization applications, is involved. 7.0 Policy The IETF Policy Framework working group is addressing a policy framework definition language, a policy architecture model, policy terminology and, specifically, a policy model that can be used for signaled as well as provisioned QoS. The policy meta-model links high-level business requirements, such as those that can be specified in an SLA, to low-level device implementation mechanisms, ranging from specific access control and management of services, objects and other resources to configuration of mechanisms necessary to provide a given service. Polices are an integral component of all middleware services, and will be found within most middleware services in one form or another. Policies are often represented as an "if condition then action" tuple. Policies can be both complex and numerous; therefore, policy management services must be able to identify and resolve policy conflicts. They also need to support both static (i.e. loaded at boot time via a configuration file) and dynamic (i.e. the configuration of a policy enforcing device may change based on an event) modes. A generalized policy management architecture (as suggested by the IETF policy architecture draft) includes a policy management service, a dedicated policy repository, at least one policy decision point (PDP), and at least one policy enforcement point (PEP). The policy management service supports the specification, editing, and administration of policy, through a graphical user interface as well as programmatically. The policy repository provides storage and retrieval of policies as well as policy components. These policy components contain definitional information, and may be used to build more complex policies, or may be used as part of the policy decision and/or enforcement process. The PDP (e.g. resource manager, such as a bandwidth broker or an intra-domain policy server) is responsible for handling events and making decisions based on those events (e.g., at time x do y) and updating the PEP configuration appropriately. In addition, it may be responsible for providing the initial configuration of the PEP. The PEP (e.g., router, firewall or host) enforces policy based on the "if condition then action" rule sets it has received from the PDP. Policy information may be communicated from the PDP to the PEP through a variety of protocols, such as COPS or DIAMETER. A proxy may be used to translate information contained in these protocols to forms that devices can consume (e.g., command line interface commands or SNMP sets). Additional information, contained in Policy Information Bases (PIBs), may also be used to translate from an intermediate specification to specific functions and capabilities of a device. For example, a policy may specify "if source IP address is 184.108.40.206, then remark traffic with a DSCP of 5". The PIB would be used to translate the device-specific meaning of the conditioning specified by the DiffServ code point of 5 (e.g., a specific set of queue and threshold settings). Policy requires AAA functions, not only for access control, but also to establish the trust relationships that will enable distributed policy interactions. PDPs may require the requesting end systems and applications to be authenticated before the PDP will honor any requests. The PDP and PEP must be authenticated to each other to reduce the probability of spoofing. This will be true whichever protocol is utilized for supporting communications between these entities. Audit trails are essential for all of these transactions. In addition, trust management policies will need to be developed as well as the supporting middleware mechanisms to enable inter-domain policy negotiation. Ultimately, many policy processes link entities to resources, And therefore require interactions with entity identification mechanisms, resource identification mechanisms, and allocation mechanisms. The distributed computing community has already started efforts developing policy definition languages and systems. Globus uses its Resource Services Language (RSL) to define the resources and policies associated with them. Condor uses a matchmaking bidding technique to match those providing and those acquiring services. Similarly, the IETF has several policy definition languages in varying stages of development, including RPSL, RPCL, SPSL, PFDL, PAX, and Keynote. Ultimately, these efforts should be merged into a single specification (or at least a smaller group of specifications) to enable distributed computing applications to be able to effectively communicate and utilize network resources and services. Directories play a crucial role in policy systems. Directories are ideally suited for storing and retrieving policy information, due to their exceptionally high read rates, ability to intelligently replicate all or part of their information, per-attribute access control, and use of containment. To this end, the IETF Policy Framework working group (in conjunction with the DMTF) is developing a core information model and LDAP schema that can be used to represent policy information that applications can use. This core model is used to provide common representation and structure of policy information. Applications can then subclass all or part of the classes in this core schema to meet their own specific needs, while retaining the ability to communicate and interoperate with each other. 8.0 Directories Directories are critical resource components that provide support to many other elements in the middleware environment, especially policy. As network-based environment evolves, it will no longer be viable to encode policy information directly into each individual application. The prevailing model in use today is for each application to store its view of a device's data (e.g., configuration) in its own private data store.These data include relevant information concerning network resources and services as well as clients wanting to use those resources (e.g., people, processes, and applications). The same resource (or aspects of that resource, such as its physical vs. logical characteristics) may be represented in several data stores. Even if the device is modeled the same way in each data store, each application only has access to its own data. This leads to duplication of data and data synchronization problems. The promise of technologies like CIM and DEN is to enable each application to store data describing the resources that they manage in a single directory using a common format and access protocol. This results in the data describing the resource being represented only once. Defining a logically centralized common repository, where resources and services are represented in a common way, enables applications of different types to utilize and share information about resources and services that they use. Not only does this solve the data duplication and synchronization problems, it also provides inherent extensibility in describing the characteristics of an object - a single entity can be represented by multiple directory objects, each representing a different aspect of the entity. Different applications can be responsible for managing the different objects that together make up a higher-level object, even if the applications themselves can not communicate with each other. This enables these applications to effectively share and reuse data. This provides significant benefits for users and applications. In the short term, users and applications will benefit from having all of the data in one place. In the long term, users and applications will be able to take advantage of data managed by other applications. Directories are key to supporting advanced network-based application environments. Directory purists say that the directory is not middleware; rather, it is a dumb storage device that is made into an intelligent repository by encapsulating it within middleware. Although a directory associates attributes with objects, what makes it different from a database are four key things: - directory objects are essentially independent of each other, whereas database objects are related to each other (sometimes in very complex ways) - directories organize their information using the notion of containment, which is not naturally implemented in databases - directory objects can have specific access controls assigned to an object and even attributes of an object - directories, unlike databases, are optimized to perform a high number of reads vs. writes. Directories use a common core schema, supporting a common set of syntaxes and matching rules, that defines the characteristics of their data. This enables a common access protocol to be used to store and retrieve data. Containment can be used for many purposes, including associating roles with objects. This is critical in order to support a real world environment, where people and elements may assume different roles based on time or other context.Containment may also be used to provide different naming scopes for a given set of data. Directories use attribute inheritance - subclasses inherit the attributes of their superclasses. This enables one to define generalized access control at a container (e.g., a group) and then refine the access control on an individual basis for objects that are inside that container (e.g., different objects have different access privileges). Currently, directories are used mostly to represent people, servers, printers, and other similar objects. CIM, DEN, and other similar efforts have encouraged directories to be used to contain common objects in a managed environment. For networked applications, this enables clients of the network (e.g., users and applications) to be bound to services available in the network in a transparent manner. The "Grid" community is making extensive use of directory services for this purpose, using them to maintain information about the structure and state of not only networks but also computers, storage systems, software, and people. The DMTF is using directories to contain CIM and DEN information, which enables a common information model to be applied to objects in a managed environment. The IETF is using directories for many different purposes, not the least of which is to contain common policy information for users and applications of an environment, as well as services and configuration information of network devices. 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 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 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. 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 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. There is specific work going on in defining various types of metadata for applications such as rights management; ultimately this will imply the development of middleware services. It will also impact the use of directory, database, and similar services in the storage, access, and retrieval of this information. Similarly, there will be a need for services to connect descriptive metadata and identifiers (URNs). (See also the NSF/ERCIM report on metadata research issues at http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.html http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.ps http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.pdf Finally, there is a need for a set of middleware services which build upon the research work already integrated into services such as Archie and Harvest. These services permit the efficient extraction of metadata about the contents of network information objects and services without necessarily retrieving and inspecting those services. This includes the ability to dispatch "indexing agents" or "knowbots" that can run at a site to compute such indexing, under appropriate security and authentication constraints. In addition, a set of "push-based" broker services which aggregate, filter and collect metadata from multiple sites and provide them to interested applications are also required. Such services can provide a massive performance, quality, comprehensiveness and timeliness improvement for today's webcrawler-based indexing services. 11.0 Network QoS As noted earlier, applications may need to explicitly request resources available in the network to meet their requirements for certain types of communication, or in order to provide service with an appropriate guarantee of one or metrics, such as bandwidth, jitter, latency, and loss. One type of request that has been the focus of much effort recently is for services beyond best effort, particularly with respect to services running over IP. This is particularly important for the advanced applications noted previously (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 <firstname.lastname@example.com>, Bob Aiken <firstname.lastname@example.com>, Guy Almes <firstname.lastname@example.com>, Chase Bailey <email@example.com>, Fred Baker <firstname.lastname@example.com>, Pete Beckman <email@example.com>, Javad Boroumand <email@example.com>, Scott Bradner <firstname.lastname@example.com>, George Brett <firstname.lastname@example.com>, Rich Carlson <email@example.com>, Brian Carpenter <firstname.lastname@example.com>, Charlie Catlett <email@example.com>, Bill Cheng <email@example.com>, Kim Claffy <email@example.com>, Bill Decker <email@example.com>, Christine Falsetti <firstname.lastname@example.com>, Ian Foster <firstname.lastname@example.com>, Andrew Grimshaw <email@example.com>, Ed Grossman <firstname.lastname@example.com>, Ted Hanss <email@example.com>, Ron Hutchins <email@example.com>, Larry Jackson <firstname.lastname@example.com>, Bill Johnston <email@example.com>, Juerg von Kaenel <email@example.com>, Miron Livny <firstname.lastname@example.com>, Cliff Lynch <email@example.com>, Joel Mambretti <email@example.com>, Reagan Moore <firstname.lastname@example.com>, Klara Nahstedt <firstname.lastname@example.com>, Mike Nelson <firstname.lastname@example.com>, Bill Nitzberg <email@example.com>, Hilarie Orman <firstname.lastname@example.com>, John Schnizlein <email@example.com>, Rick Stevens <firstname.lastname@example.com>, John Strassner <email@example.com>, Ben Teitelbaum <email@example.com>, George Vanecek <email@example.com>, Ken Klingenstein <firstname.lastname@example.com>, Arvind Krishna <firstname.lastname@example.com>, Dilip Kandlur <firstname.lastname@example.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: firstname.lastname@example.com Authors: Bob Aiken Cisco Systems, Inc. 6519 Debold Rd. Sabillasville, Md. 21780 USA Phone: +1 301 271 2919 EMail: email@example.com John Strassner Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 408 527 1069 EMail: firstname.lastname@example.com Brian E. Carpenter IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire SO21 2JN, UK EMail: email@example.com Ian Foster Argonne National Laboratory The University of Chicago Argonne, IL 60439 USA Phone: +1 630 252 4619 EMail: firstname.lastname@example.com Clifford Lynch Coalition for Networked Information 21 Dupont Circle Washington, DC 20036 Phone: +1 202 296 5098 EMail: email@example.com Joe Mambretti International Center for Advanced Internet Research 1890 Maple, Suite 150 Northwestern University, Evanston, Illinois 60201 Phone: +1 847 467 3911 EMail: firstname.lastname@example.com Reagan Moore University of California, San Diego NPACI/SDSC, MC 0505 9500 Gilman Drive La Jolla, CA 92093-0505 USA EMail: email@example.com Benjamin Teitelbaum Advanced Networks & Services, Inc. EMail: email@example.com 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 RFC Editor function is currently provided by the Internet Society. User Contributions:Comment about this RFC, ask questions, or add new information about this topic: |


text:
New Car/Review
2000 Toyota ECHO
SEE ALSO: Toyota Buyer's Guide
by Carey Russ
The Tercel, the entry-level Toyota since 1980, was discontinued after the 1998 model year. Was Toyota abandoning the entry-level market? As it turns out, most emphatically not. The Tercel has been replaced by the ECHO, an all-new and very different car. Compared to the Tercel, the ECHO offers unique character, increased interior room, and, most surprisingly, a lower price.
The ECHO is more than just a new nameplate in the Toyota lineup. It's a new concept for a small, low-cost car. If the styling is unconventional, there is logic and purpose behind it. Despite the ECHO's subcompact-class length - close to that of the Tercel - it boasts compact-class interior space, nearly as much as is found in the larger and more expensive Corolla. And the high roofline makes it seem even roomier. The ECHO is aimed at young, first-time buyers - people who often live in crowded urban environments where parking is difficult. But the small outside / larger inside design can work anywhere. Need a second car but have limited parking?
Like the Tercel, the ECHO is offered in two-door and four- door sedan bodystyles, and uses a 1.5-liter four-cylinder engine. The engine is an all-new powerplant bristling with the latest high- tech features. It makes more power than the Tercel's engine - 108 hp to 93 - with improved fuel economy and LEV emissions levels. Transmission choices are a five-speed manual and sophisticated four-speed automatic, not the three-speed more common in the low-price class.
I had the recent opportunity to sample both a two-door and four-door ECHO during consecutive weeks. The two-door had the five-speed; the four-door had the automatic. Both were comfortable, easy-to-park vehicles with plenty of useful space for their size and a minimal thirst for ever more expensive gas. Both were also pretty much fully-equipped, pushing the price up into the lower end of compact territory. Hey, comfort costs...but even at a lesser-equipped level, the ECHO has plenty of comfort and useful space. Toyota is serious about filling every automotive niche, and fills the (not so) basic transportation niche very well with the ECHO.
APPEARANCE: In a class noted mostly for un-notable styling, the ECHO stands out. It is unmistakable, with a generally rounded shape and a wedge-like profile emphasized by a sharp shoulder line. Like several other new European and Japanese designs, the ECHO gains space with height. It has an almost toylike appearance thanks to its high stance, large passenger cabin placed well forward, and short overhangs. Large, complexly-shaped headlights and an interestingly-shaped grille give it a distinctive face. Protective black plastic lower cladding is part of the "upgrade kit." Bolt-on hubcaps cover the pressed-steel wheels for a more upscale look.
COMFORT: The ECHO's high stance and large passenger cabin may look strange from the outside, but can be easily appreciated from the inside. There's an amazing amount of inside for such a small amount of outside, thanks in part to the upright, minivan-like seating positions. Headroom and legroom front and rear is better than in most compact and many midsized sedans. Three passengers are quite possible, if a bit cozy, in the rear seat. The high, roomy trunk and available split folding rear seat add convenience. The ECHO's interior styling is as unique as its exterior, and just as practical. The centrally-mounted instrument pod takes some getting used to, but increases direct forward vision. Large storage spaces flanking the central control module hold CDs, cassettes, and other items; a tray below the steering wheel is also quite useful. Manual windows and mirror adjustment are among the few clues to the ECHO's low-budget status, but such features are appreciated by some people because of their simplicity.
SAFETY: The ECHO's chassis is designed for safety. All seating positions have three-point safety belts, and antilock brakes are available.
ROADABILITY: The Echo is a class or two above its subcompact level in comfort and quiet on the road. Its MacPherson strut front, torsion beam rear suspension matches spring and shock rates well for a good ride quality. Cornering abilities are good for its class, although the high seating position does make body roll more noticeable.
PERFORMANCE: The Echo's light weight ensures that the 108 horsepower developed by its 1.5-liter engine is plenty for any job at hand. The newly-designed twincam, 16-valve four-cylinder uses Toyota's sophisticated "VVT-i" variable valve timing system for improved power delivery, better fuel economy, and lower emissions. With a minimal weight difference between the two- and four-door models, performance is virtually identical. As expected, the five-speed manual gearbox gives noticeably better acceleration and slightly better gas mileage than the four-speed automatic. But the automatic is smoother than the norm for the class, and has electronic control to prevent "hunting" between gears on hills. It works well in everyday driving, and is a fine choice.
CONCLUSIONS: Not only has Toyota has not abandoned entry- level small car buyers, it has given them a great new car with the ECHO.
SPECIFICATIONS 2000 Toyota ECHO 2-Door 4-Door (if different) Base Price $ 9,995 $ 11,095* Price As Tested $ 13,819 $ 14,964 * includes automatic transmission in base price Engine Type dual overhead cam 16-valve 4-cylinder with VVTi variable valve timing Engine Size 1.5 liters / 91 cu. in. Horsepower 108 @ 6000 rpm Torque (lb-ft) 105 @ 4200 rpm Transmission 5-speed manual 4-speed electronically- controlled automatic Wheelbase / Length 93.4 in. / 163.3 in. Curb Weight 2020 lbs. 2080 lbs Pounds Per Horsepower 18.7 19.2 Fuel Capacity 11.9 gal. Fuel Requirement regular unleaded gasoline, 87 octane Tires P175/65 SR14 Bridgestone Potenza RE92 Brakes, front/rear vented disc / drum Suspension, front/rear independent MacPherson strut / torsion beam Drivetrain front engine, front-wheel drive PERFORMANCE EPA Fuel Economy - miles per gallon city / highway / observed 34 / 41 / 34 31 / 38 / 31 0 to 60 mph, sec 9.0 manual, 10.7 automatic OPTIONS AND CHARGES (both equipped same) All-weather guard package - includes: heavy-duty battery, rear heater, rear defogger $ 275 Antilock brakes with daytime running lights $ 590 Upgrade package #1 - includes: sports body kit, power steering, intermittent wipers, dual; remote outer mirrors, 60/40 split folding rear seat, digital clock $ 1,020 Upgrade package # 2 - includes: air conditioning, deluxe AM/FM/cassette/CD stereo, power door locks $ 1,465 Carpet floor mats $ 64 Destination charge $ 455

subset: commoncrawl


text:
Solar Thermal Concentrating Power Plants
Solar thermal plants utilize the heat from the sun's rays. The sun's rays are concentrated via reflectors in an absorber to heat a fluid that generates water vapor using a heat exchanger. The water vapor is used to drive turbines and generators as in conventional thermal power plants. Solar thermal power plants include parabolic trough, Fresnel and solar tower power plants. Dish Stirling power plants are a special variant where concentrated sunlight directly drives a Stirling engine that in turn drives a generator.
In systems where the sun's rays are concentrated from heliostats on absorbers in solar towers, the tracking systems of the mirrors must be moved with high precision and high accuracy. The bearing supports must operate using the lowest possible friction and high rigidity.
Improved performance in tracking systems with high-precision bearing supports
Rolling and plain bearings such as maintenance-free half shells with a metal-polymer composite sliding layer are used in tracking systems. In parabolic trough structures that can measure almost 200 meters in length, they minimize the torsion of the long axis that compromises the reflection of the sun's rays on the absorber pipes.
Schaeffler supplies rigid angular contact roller bearings with high load carrying capacity for two-axis gearboxes for heliostats that measure 120 m², for example. These components enable the high loads generated by the weight of the mirrors and wind forces to be reliably supported. This means the power plant precisely tracks the sun's path.
INA plain bearings
Metal-polymer composite plain bearings
Metal-polymer composite bearings are a cost-effective alternative for applications with minimum available space and a comparatively high sliding speed. In solar power plants, they can be used in the bearing supports of tracking systems, for example in the elevation axis. Our plain bearings are available as bushes and flanged bushes, as well as thrust washers, half-shells, and strips.
- Low maintenance or maintenance-free
- Wear-resistant
- Constant low friction values throughout the whole operating period
Plain bearing bushes with ELGOTEX
Plain bearing bushes with ELGOTEX are resistant to shocks and tilting. Customer-specific solutions with special dimensions or special tolerances, for example, are available on request. The bearings are available with and without integrated seals.
- Maintenance-free
- Extremely robust
- Very good damping behavior
- Low wear with a constant friction value (dry lubrication)
- Resistant to contamination
- Corrosion-resistant
Plain bushes with ELGOGLIDE
Plain bushes with ELGOGLIDE have excellent damping behavior. Bearings with an additional coating applied to the steel support body as anti-corrosion protection are also available. These plain bearing bushes are also available with integrated seals.
- Maintenance-free
- Extremely high static and dynamic load carrying capacity within a small design envelope
- Dry lubrication
- Very low friction
- Very low breakaway torque without the "stick slip" effect
INA spherical plain bearings
Maintenance-free spherical plain bearings
Maintenance-free spherical plain bearings are used as dry plain bearings for precise swiveling motion of parabolic troughs without stick-slip. Different ELGOGLIDE and PTFE sliding layers as well as designs with an additional anti-corrosion coating are available depending on the application and loads.
- High load carrying capacity and low weight
- Very suitable for slow and precise swiveling movements
- Long rating life
Spherical plain bearings requiring maintenance
Bearings requiring maintenance must be lubricated due to the steel/steel or steel/bronze sliding contact surface. When designing the bearing support, it must be ensured that the bearing position can be adequately supplied with grease. These bearings are available as radial, angular contact and axial bearings.
- Wide product range
- All lubricants for initial greasing are tested before use in our in-house lubricant laboratory
Rod ends
Rod ends are used as linking elements in levers, linkages, and hydraulic and pneumatic cylinders. They support radial loads in a tensile or compressive direction. Rod ends are available with internal or external threads as maintenance-free variants or variants requiring maintenance.
- Corrosion protection
- Can be clamped or welded
INA axial angular contact roller bearings
With its AXS axial angular contact roller bearings, Schaeffler has developed a bearing series with a particularly small cross-section that is capable of supporting very high loads.
Typical applications are reflector adjustment systems. These rolling bearing supports facilitate the movement of the azimuth and elevation axis in double-axis drive units.
Axial angular contact roller bearings AXS comprise thin-walled drawn bearing rings and injection-molded plastic cages with cylindrical rollers. They can support axial forces as well as radial forces and tilting moments. When fitted in pairs, they can transfer very high loads safely. Axial angular contact roller bearings are suitable for O and X arrangement.
- High load carrying capacity and rigidity
- Precise guidance accuracy
- Small axial and radial design envelope
- Especially suitable for low speeds
INA slewing rings
INA slewing rings are used in solar power plants for the precise alignment of particularly large reflectors and collectors, for example in double-axis tracking systems with two separate drives. In the case of separate drives, slewing rings are used in the bearing supports of azimuth axes.
INA slewing rings are known worldwide as premium products in the field of rolling bearing technology. A single bearing can reliably support radial, axial and tilting moment loads. It is therefore possible in many cases to replace bearing supports comprising a combination of radial and axial bearings by a single bearing, despite the high loads involved. This reduces, in some cases considerably, the costs and work required in the design of the adjacent construction and the fitting of bearings.
Slewing rings are sealed on both sides and lubricated with high-quality lubricating grease. They can be lubricated via lubrication nipples. The bearing rings are supplied without gear teeth or, in order to achieve simple drive solutions, are available with external or internal gear teeth. Customer-specific special solutions are also possible. INA slewing rings are available as single or double row four-point bearings as well as crossed roller bearings.
- High load carrying capacity and rigidity
- Very cost-effective
- Extremely versatile
- Easy to fit
INA radial insert ball bearings and housing units
Depending on the power plant involved, radial insert ball bearings and housing units of cast iron, sheet steel and plastic are used to support the elevation axis in single-axis tracking systems. These bearings are available in various designs with anti-corrosion protection, for example with Corrotect® coating. INA radial insert ball bearings and housing units are filled with lithium soap grease that is especially resistant to corrosion and aging. They are also available with square and hexagonal bores. To make the mounting process easier, split housings are also available that can also be used with various plain bearing types.
- Particularly economical - without engineering compromises
- Easy to fit
- Robust and reliable
- Prevention of shaft misalignment due to self-alignment facility
INA track rollers
INA track rollers are used on the rail systems for adjusting the azimuth axis of solar modules or for swiveling the parabolic mirrors. They are used in photovoltaic, Stirling and solar tower power plants. The rollers are designed as needle roller bearings, ball bearings or plain bearings. These bearings can also support high radial forces and axial forces in both directions. Our INA track roller range comprises more than 3,000 basic designs for all current applications.
- Compact and small design
- Reliable and resistant to wear
- Low maintenance or maintenance-free
Above all, the technical superiority of INA track rollers compared with conventional components is due to the lower contact pressure.


text:
We have the answer for Riffs on, modernly crossword clue if it has been stumping you! Solving crossword puzzles can be a fun and engaging way to exercise your mind and vocabulary skills. Remember that solving crossword puzzles takes practice, so don't get discouraged if you don't finish a puzzle right away. Keep practicing and you'll get better with time–but we're always here with answers if you need a helping hand!
Now, let's get into the answer for Riffs on, modernly crossword clue most recently seen in the NYT Crossword.
Riffs on, modernly Crossword Clue Answer is…
Answer: MEMES
This clue last appeared in the NYT Crossword on December 22, 2023. If you need help with other clues, head to our NYT Crossword December 22, 2023 Hints page. You can also find answers to past NYT Crosswords.
Related NYT Crossword Answers
Clue | |
Get on the job | |
Appealing to an indie audience, maybe | |
Plays the wrong way | |
Tackles | |
Riffs on, modernly | |
Buds | |
Knock hard | |
Make it up? | |
Bed cover | |
"Take my word for it, you're going to love this" | |
You can play the NYT Crossword online or by downloading its mobile app (Google Play/Apple App Store).
Historical Usage in Crossword Puzzles
About the NYT Crossword
The New York Times crossword was first published in The New York Times in 1942 and has been a daily feature ever since. It is known for its high level of difficulty and for its clever, often playful, clues and themes. The puzzles range in size from 15x15 grids on weekdays to larger 21x21 grids on Sundays, with varying levels of difficulty.
The New York Times crossword is created by a team of skilled puzzle constructors and editors, who work to ensure that each puzzle is both entertaining and challenging for solvers. The puzzles are often themed, with clues and answers related to a particular subject or concept, and they frequently feature wordplay and puns.
Solving the New York Times crossword has become a beloved pastime for many, and there are even competitions and clubs devoted to crossword puzzle solving. The New York Times crossword is available in print in the newspaper and online, and it has a dedicated following of loyal solvers who eagerly await each day's puzzle.
That should be all the information you need to solve for the Riffs on, modernly crossword clue answer to help you fill in more of the grid you're working on! Be sure to check more Crossword Clues, Crossword Answers, and our other Word Game coverage.


text:
Experience Ubiquitous Service with UBNTEK's Technology
On the go
Throughout the age of information technology, we haveexperienced our lives getting simpler through the use of computers. Computer technology is becoming more and more integrated into our everyday routines, and as the technology becomes available we come to rely upon it.
Many companies and organizations are eagerly looking forward to the ubiquitous future, and how soon everything will have a chip in it that will allow it to be digitally tracked, its history digitally stored, and its unique appeal digitally erased from existence. The ubiquitous future involves devices, a million billion little devices, that all interoperate, communicate, collaborate, and facilitate pretty much everything. In the very near future, ubiquitous wireless sensor network is allowing us to more easily provide valuable public and private services, enhancing the well-being of our community.
For the ubiquitous future, UBNTEK leads technologies with ubiquitous service solutions as the following main areas.
uLBS is a ubiquitous Location Based Service system based on Ubiquitous Sensor Networks (USN) which provides an information and entertainment service in a variety of contexts, such as health, work, personal life, social networks, etc.,
uSmartHome is a home automation with wireless sensors and security solution to make home more energy efficient, control security on the Internet and run everything off a smart phone miles away from home.
uCamPro with Server & Client Viewer offers surveillance solutions for virtually every situation, which will save customers time and money and give them peace of mind. Scalable architecture supports thousands of concurrent users viewing the same camera or multiple cameras with Wi-Fi coverage or even cellular networks.
Main Business Activities
We offer a variety of impressive services including home automation, mobile surveillance beyond the framework of IT and national borders as follows:


text:
there are some stories that never get old. for those of you who may not have heard the story that began this crazy journey, this is for you.
the first pregnancy is the most exciting. that's not to say that other pregnancies aren't full of wonder but the first one is full of all things new. every change is a new experience and the unknown helps to add to the thrill of it all. i was like a lot of first time pregnant moms. i enjoyed that first pregnancy...until i noticed a kiwi sized lump growing in my armpit. the worst of scenarios raced through my mind. did i have cancer? was this a tumor? when the doctor ordered an ultrasound of the lump, i was thinking the worst.
sitting in the office of the ultrasound technician, i stared at the monitor trying to figure out what she was seeing on that little screen. "what is it?" "all i can see is breast tissue. i'll send the results to your doctor." i felt a sense of relief. no tumor, just breast tissue...in my armpit. i had no idea why that would be and my ob-gyn was actually of very little help in that department. i was told it was just breast tissue. breasts swell during pregnancy and that it should go back to normal after giving birth. this was a great theory but, after looking around, no other pregnant women seemed to be walking around with a kiwi in one pit.
finally a lactation consultant friend of mine told me it could be an extra mammary gland. this was confirmed in the hospital after i gave birth to my first son. a second lactation consultant came in to check on the nursing situation and i blurted out, "i think i have a third boob." to this, in the tradition of lactation consultants getting all up in your boob business, she peeled back my hospital gown to examine the said appendage. here's where it gets good. this lady had all the good information. apparently, your milk lines run from your armpit all the way down your abdomen (think a cat or a dog with a litter of puppies). you can be born with extra mammary glands or extra nipples anywhere along your milk line and, unless you have a visible nipple, you may not know it's even there until your breasts swell during pregnancy. the consultant then proceeded to tell me that there was a woman in the hospital the day before with eight boobs. (i can hear the collective gasps through the computer.) i all of a sudden felt pretty happy just to have the one. she then continued by saying that it would go away after nursing and that, because there was no visible nipple, it would dry up and shrink back to its former undetectable size.
here is where she got it wrong. my milk finally came in for my first born and while i was nursing him, i asked my husband if he'd turn up the air conditioning because i felt like i was sweating profusely. i then looked down to see that no, i wasn't sweating. what i thought had been the tiniest of brown freckles was instead a nipple that was currently dripping milk down into a puddle on my shirt. yep...sign me up for the circus people. not only do i have a third boob but it lactates. lac. tates.
i had to nurse with a towel in my armpit and while most nursing moms got to walk around with just absorbent breast pads in their nursing bras, i got to do that and wear a huge band-aid on my armpit. just so we're all aware here, my son was born in june...tank top weather. fabulous.
so, there you have it. i think the third boob can give everyone a brighter outlook on life and on their after-baby bodies. your stomach may look like a venetian blind from the stretch marks you earned or you may have skin that now somehow resembles an elephant's trunk. still, looking in the mirror at yourself you can always say, "at least it doesn't lactate." so, here's to you, third boob. thanks for making most of the world feel a little bit better about themselves...and for giving us a great story to tell. cheers!


text:
Falling Out of Time
By David Grossman
By David Grossman
By David Grossman
By David Grossman
Part of Vintage International
Part of Vintage International
Dec 02, 2014 | ISBN 9780345805850
Mar 25, 2014 | ISBN 9780385350143
I Will Hold
Land of Marvels
General A.P. Hill
The Confabulist
Literary Occasions
The Succession
Raven's Bride
Flashman and the Tiger
"A strange and riveting book." —The New York Times Book Review
"An almost unbearably personal work. . . . The monologues evoke both the raw declarations of Athenian tragedy and the homespun lamentations of Robert Frost's narrative poem." —The Wall Street Journal
"Spare and poetic." —The New York Review of Books
"A richly emotional, mystical and philosophical tapestry . . . [Falling Out of Time] deserves recognition among the greatest works in the brave and indispensable tradition of art that pushes back against catastrophe." —Jewish Daily Forward
"Slim in dimension but as solid as sculpted rock. . . . Although it grows from a private, incomparable ordeal, this noble fable speaks for all." —The Independent (London)
"Part narrative poem, part play, part novel . . . [a] poignant study of bereavement and loss." —Financial Times
"[Grossman is] the greatest Israeli writer of his generation. . . . Talmudic, polyphonic, yearning, [Falling Out of Time] comes from a place of pain and darkness and is acutely moving." —The Daily Telegraph (London)
"The language of its composition makes it particular to Israel, but once translated [Falling Out of Time] becomes universal." —The Times Literary Supplement (London)
"Grossman is perhaps Israel's most important contemporary novelist. . . . [Falling Out of Time] resembles a play by Beckett or a Greek tragedy. . . . A haunting, affecting and even beautiful book." —The Toronto Star
"It's not a novel, but a mixture of poetry, prose and drama . . . as true and as powerful as CS Lewis's great A Grief Observed." —The Times (London)
"A book that needed to be written. . . . Poetic. . . . [A] triumph." —The Observer (London)
"At once more universal and more personal than anything [Grossman] has written before." —Sunday Times (London)
"Falling Out of Time is short, and clearly a deeply personal book, but its importance and impact ought not to be underestimated." —The Guardian (London)
"A significant new departure in literature." —Jewish Chronicle
"Sensual and uncompromising. . . . Written with such simplicity it appears to be speaking directly to the reader, Falling Out Of Time is at times Biblical in its imagery, at others weird and fantastical. . . . It's a measure of Grossman's clarity of thought and his theatrical timing that one reaches its end and feels, in some small way, glad to have been in his characters' company however grim the road they travel." —The Herald Scotland
"An impassioned exploration of existential questions about life and death. . . . The precision and sensory depth of Grossman's language renders this unconventional work an unforgettable and magnificent document of suffering." —Publishers Weekly (starred review)
21 Books You've Been Meaning to Read
Just for joining you'll get personalized recommendations on your dashboard daily and features only for members.
Find Out More Join Now Sign In