idnits 2.17.1 draft-aiken-middleware-reqndef-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 18) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 139 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 9 has weird spacing: '...shop on middl...' == Line 130 has weird spacing: '...icy and manag...' == Line 791 has weird spacing: '...ncoding the d...' == Line 793 has weird spacing: '...ve such metad...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 GENERAL: Middleware Bob Aiken, John Strassner, Cisco Systems 2 INTERNET DRAFT Brian Carpenter, IBM 3 28 May 1999 Ian Foster, Argonne National Laboratory 4 Clifford Lynch, Coalition for Networked Information 5 Joe Mambretti, ICAIR 6 Reagan Moore, UCSD 7 Benjamin Teitelbaum, Advanced Networks & Services, Inc. 9 Terminology for network policy and services: a report of a workshop on middleware. 10 draft-aiken-middleware-reqndef-02.txt 12 Status of Memo 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 32 An ad hoc middleware workshop was held at the International Center for 33 Advanced Internet Research in December 1998. The Workshop was 34 organized and sponsored by Cisco, Northwestern University's 35 International Center for Advanced Internet Research (iCAIR), IBM, and 36 the National Science Foundation (NSF). The goal of the workshop was to 37 identify existing middleware services that could be leveraged for new 38 capabilities as well as identifying additional middleware services 39 requiring research and development. The workshop participants 40 discussed the definition of middleware in general, examined the 41 applications perspective, detailed underlying network transport 42 capabilities relevant to middleware services, and then covered various 43 specific examples of middleware components. These included APIs, 44 authentication, authorization, and accounting (AAA) issues, policy 45 framework, directories, resource management, networked information 46 discovery and retrieval services, quality of service, security, and 47 operational tools. The need for a more organized framework for 48 middleware R&D was recognized, and a list of specific topics needing 49 further work was identified. 51 Table of Contents 53 Introduction 55 1.0 Contextual Framework 56 2.0 What is Middleware? 57 3.0 Application Perspective 58 4.0 Exemplary Components 59 5.0 Application Programming Interfaces and Signaling 60 6.0 IETF AAA 61 7.0 Policy 62 8.0 Directories 63 9.0 Resource Management 64 10.0 Networked Information Discovery and Retrieval Services 65 11.0 Network QOS 66 12.0 Authentication, authorization, and access management. 67 13.0 Network Management, Performance, and Operations 68 14.0 Middleware to support multicast applications 69 15.0 Java and Jini TM 70 16.0 Security Considerations 71 17.0 Summary 72 18.0 Participants 73 19.0 URLs 74 20.0 Authors 76 Introduction: 78 This document describes the term "middleware" as well as its 79 requirements and scope. Its purpose is to facilitate communication 80 between developers of both collaboration based and high-performance 81 distributed computing applications and developers of the network 82 infrastructure. Generally, in advanced networks, middleware consists of 83 services and other resources located between both the applications and 84 the underlying packet forwarding and routing infrastructure, although 85 no consensus currently exists on the precise lines of demarcation that 86 would define those domains. This document is being developed within the 87 context of existing standards efforts. Consequently, this document 88 defines middleware core components within the framework of the current 89 status of middleware-related standards activities, especially within 90 the IETF and the Desktop Management Task Force (DMTF). The envisioned 91 role of the IETF is to lead the work in defining the underlying 92 protocols that could be used to support a middleware infrastructure. In 93 this context, we will leverage the information modeling work, as well 94 as the advanced XML and CIM/DEN-LDAP mapping work, being done in the 95 DMTF. (The recently constituted Grid Forum is also pursuing relevant 96 activities.) 98 This document also addresses the impact of middleware on Internet 99 protocol development. As part of its approach to describing middleware, 100 this document has initially focused on the intersections among 101 middleware components and application areas that already have well 102 defined activities underway. 104 This document is a product of an ad hoc Middleware Workshop held on 105 December 4-5 1998. The Workshop was organized and sponsored by Cisco, 106 Northwestern University's International Center for Advanced Internet 107 Research (iCAIR), IBM, and the National Science Foundation (NSF). The 108 goal of the workshop was to define the term middleware and its 109 requirements on advanced network infrastructures as well as on 110 distributed applications. These definitions will enable a set of core 111 middleware components to subsequently be specified, both for supporting 112 advanced application environments as well as for providing a basis for 113 other middleware services. 115 Although this document is focused on a greater set of issues than just 116 Internet protocols, the concepts and issues put forth here are 117 extremely relevant to the way networks and protocols need to evolve as 118 we move into the implementation stage of "the network is the computer". 119 Therefore, this document is offered to the IETF, DMTF, Internet2, Next 120 Generation Internet (NGI), NSF Partnerships for Advanced Computational 121 Infrastructure (PACI), the interagency Information Technology for the 122 21st Century (IT2) program, the Grid Forum, the Worldwide Web 123 Consortium, and other communities for their consideration. 125 This document is organized as follows: Section 1 provides a contextual 126 framework. Section 2 defines middleware. Section 3 discusses 127 application requirements. Subsequent sections discuss requirements and 128 capabilities for middleware as defined by applications and middleware 129 practitioners. These sections will also discuss the required underlying 130 transport infrastructure, administrative policy and management, 131 exemplary core middleware components, provisioning issues, network 132 environment and implementation issues, and research areas. 134 1.0 Contextual Framework 136 Middleware can be defined to encompass a large set of services. For 137 example, we chose to focus initially on the services needed to support 138 a common set of applications based on a distributed network 139 environment. A consensus of the Workshop was that there was really no 140 core set of middleware services in the sense that all applications 141 required them. This consensus does not diminish the importance of 142 application domain-specific middleware, or the flexibility needed in 143 determining customized approaches. Many communities (e.g., Internet2, 144 NGI, and other advanced Internet constituencies) may decide on their 145 own set of common middleware services and tools; however, they should 146 strive for interoperability whenever possible. The topics in this 147 workshop were chosen to encourage discussion about the nature and scope 148 of middleware per se as distinct from specific types of applications; 149 therefore, many relevant middleware topics were not discussed. 151 Another consensus of the Workshop that helped provide focus was that, 152 although middleware could be conceptualized as hierarchical, or 153 layered, such an approach was not helpful, and indeed had been 154 problematic and unproductive in earlier efforts. 156 The better approach would be to consider middleware as an unstructured, 157 often orthogonal, collection of components (such as resources and 158 services) that could be utilized either individually or in various 159 subsets. This working assumption avoided extensive theological 160 modeling discussions, and enables work to proceed on various middleware 161 issues independently. 163 An important goal of the Workshop was to identify any middleware or 164 network-related research or development that would be required to 165 advance the state of the art to support advanced application 166 environments, such as those being developed and pursued by NGI and 167 Internet2. Consequently, discussion focused on those areas that had 168 the maximum opportunity for such advances. 170 2.0 What is Middleware? 172 The Workshop participants agreed on the existence of middleware, but 173 quickly made it clear that the definition of middleware was dependent 174 on the subjective perspective of those trying to define it. Perhaps it 175 was even dependent on when the question was asked, since the middleware 176 of yesterday (e.g., Domain Name Servive, Public Key Infrastructure, and 177 Event Services) may become the fundamental network infrastructure of 178 tomorrow. Application environment users and programmers see everything 179 below the API as middleware. Networking gurus see anything above IP as 180 middleware. Those working on applications, tools, and mechanisms 181 between these two extremes see it as somewhere between TCP and the API, 182 with some even further classifying middleware into application-specific 183 upper middleware, generic middle middleware, and resource-specific 184 lower middleware. The point was made repeatedly that middleware often 185 extends beyond the "network" into the compute, storage, and other 186 resources that the network connects. For example, a video serving 187 application will want to access resource discovery and allocation 188 services not just for networks but also for the archives and computers 189 required to serve and process the video stream. Through the 190 application of general set theory and rough consensus, we roughly 191 characterize middleware as those services found above the transport 192 (i.e., over TCP/IP) layer set of services but below the application 193 environment (i.e., below application-level APIs). 195 Some of the earliest conceptualizations of middleware originated with 196 the distributed operating research of the late 1970s and early 1980s, 197 and was further advanced by the I-WAY project at SC'95. The I-WAY 198 linked high performance computers nation-wide over high performance 199 networks such that the resulting environment functioned as a single 200 high performance environment. As a consequence of that experiment, the 201 researchers involved re-emphasized the fact that effective high 202 performance distributed computing required distributed common computing 203 and networking resources, including libraries and utilities for 204 resource discovery, scheduling and monitoring, process creation, 205 communication and data transport. 207 Subsequent research and development through the Globus project of such 208 middleware resources demonstrated that their capabilities for 209 optimizing advanced application performance in distributed domains. 211 In May 1997, a Next Generation Internet (NGI) workshop on NGI research 212 areas resulted in a publication, "Research Challenges for the Next 213 Generation Internet", which yields the following description of 214 middleware. "Middleware can be viewed as a reusable, expandable set of 215 services and functions that are commonly needed by many applications to 216 function well in a networked environment". This definition could 217 further be refined to include persistent services, such as those found 218 within an operating system, distributed operating environments (e.g., 219 JAVA/JINI), the network infrastructure (e.g., DNS), and transient 220 capabilities (e.g., run time support and libraries) required to support 221 client software on systems and hosts. 223 In summary, there are many views of what is middleware. The consensus 224 of many at the workshop was that given the dynamic morphing nature of 225 middleware, it was more important to identify some core middleware 226 services and start working on them than it was to come to a consensus 227 on a dictionary-like definition of the term. 229 Systems involving strong middlware components to support networked 230 information discovery have also been active research areas since at 231 least the late 1980s. For example, consider Archie or the Harvest 232 project, to cite two examples. One could easily argue that the site 233 logs used by Archie or the broker system and harvest agents were an 234 important middleware tool, and additional work in this area is urgently 235 needed in order to improve the efficiency and scope of web-based 236 indexing services. 238 "As long ago" as 1994, the Internet Architecture Board held a workshop 239 on "Information Infrastructure for the Internet" reported in RFC 1862, 240 which in many ways covered similar issues. Although its recommendations 241 were summarized as follows: 243 - increased focus on a general caching and replication architecture 244 - a rapid deployment of name resolution services, and 245 - the articulation of a common security architecture for 246 information applications." 248 it is clear that this work is far from done. 250 Finally, this workshop noted that there is a close linkage between 251 middleware as a set of standards and protocols and the infrastructure 252 needed to make the middleware meaningful. For example, the DNS protocol 253 would be of limited signifigance without the system of DNS servers, and 254 indeed the administrative infrastructure of name registry; NTP, in 255 order to be useful, requires the existance of time servers; newer 256 middleware services such as naming, public key registries and 257 certificate authorities, will require even more extensive server and 258 administrative infrastructure in order to become both useful and 259 useable services. 261 3.0 Application Perspective 263 >From an applications perspective, the network is just another type of 264 resource that it needs to use and manage. The set of middleware 265 services and requirements necessary to support advanced applications 266 are defined by a vision that includes and combines applications in 267 areas such as: distributed computing, distributed data bases, advanced 268 video services, teleimmersion (i.e., a capability for providing a 269 compelling real-life experience in a virtual environment based for 270 example on CAVE technologies), extensions with haptics, electronic 271 commerce, distance education, interactive collaborative research, high- 272 rate instrumentation (60 MByte/s and above sustained), including use of 273 online scientific facilities (e.g. microscopes, telescopes, etc.), 274 effectively managing large amounts of data, computation and information 275 Grids, adaptable and morphing network infrastructure, proxies and 276 agents, and electronic persistent presence (EPP). Many of these 277 applications are "bleeding edge" with respect to currently deployed 278 applications on the commodity Internet and hence have unique 279 requirements. Just as the Web was an advanced application in the early 280 1990s, many of the application areas defined above will not become 281 commonplace in the immediate future. However, they all possess the 282 capability to change the way the network is used as well as our 283 definition of infrastructure, much as the Web and Mosaic changed it in 284 the early 90s. A notable recent trend in networks is the increasing 285 amount of HTTP, voice, and video traffic, and it was noted that voice 286 and video particularly need some form of QoS and associated middleware 287 to manage it. 289 A quick review of the requirements for teleimmersion highlight the 290 requirement for multiple concurrent logical network channels, each with 291 its own latency, jitter, burst, and bandwidth QoS; yet all being 292 coordinated through a single middleware interface to the application. 293 For security and efficiency those using online instruments require the 294 ability to steer the devices and change parameters as a direct result 295 of real-time analysis performed on the data as it is received from the 296 instruments. Therefore, network requirements encompass high bandwidth, 297 low latency, and security, which must all be coordinated through 298 middleware. Large databases, archives, and digital libraries are 299 becoming a mainstay for researchers and industry. The requirements they 300 will place on the network and on middleware will be extensive, 301 including support of authentication, authorization, access management, 302 quality of service, networked information discovery and retrieval 303 tools, naming and service location, to name only a few. They also 304 require middleware to support collection building and self-describing 305 data. Distributed computing environments (e.g., Globus, Condor, 306 Legion, etc.) are quickly evolving into the computing and information 307 Grids of the future. These Grids not only require adaptive and 308 manageable network services but also require a sophisticated set of 309 secure middleware capabilities to provide easy-to-use APIs to the 310 application. 312 Many application practitioners were adamant that they also required the 313 capability for "pass through" services. This refers to the ability to 314 bypass the middleware and directly access the underlying infrastructure 315 such as the operating system or network), even though they were eager 316 to make use of middleware services and see more of it developed to 317 support their own applications. In addition, authentication and access 318 control, as well as security, are required for all of the applications 319 mentioned above, albeit at different levels. 321 4.0 Exemplary Components 323 In an attempt to describe middleware and discuss pertinent issues 324 relating to its development and deployment, an exemplary set of 325 services were selected for discussion. These services were chosen to 326 stimulate discussion and not as an attempt to define an exclusive set 327 of middleware services. Also, it is the intent of this effort not to 328 duplicate existing IETF efforts or those of other standards bodies 329 (e.g., the DMTF), but rather to leverage those efforts, and indeed to 330 highlight areas where work was already advanced to a stage that might 331 be approaching deployment. 333 5.0 Application Programming Interfaces and Signaling 335 Applications require the ability to explicitly request resources based 336 on their immediate usage needs. These requests have associated network 337 management controls and network resource implications; however, 338 fulfillment of these requests may require multiple intermediate steps. 339 Given the preliminary state of middleware definition, there currently 340 is no common framework, much less a method, for an application to 341 signal its need for a set of desired network services, including 342 quality and priority of service as well as attendant resource 343 requirements. However, given the utility of middleware, especially with 344 regard to optimization for advanced applications, preliminary models 345 for both quality and priority of service and resource management exist 346 and continue to evolve. however, without an agreed-to framework for 347 standards in this area, there is the risk of multiple competing 348 standards that may further delay the deployment of a middleware-rich 349 infrastructure. This framework should probably include signaling 350 methods, access/admission controls, and a series of defined services 351 and resources. In addition, it should include service levels, priority 352 considerations, scheduling, a Service-Level-Agreement (SLA) function, 353 and a feedback mechanism for notifying applications or systems when 354 performance is below the SLA specification or when an application 355 violates the SLA. Any such mechanism implies capabilities for: 1) an 356 interaction with some type of policy implementation and enforcement, 2) 357 dynamic assessment of available network resources, 3) policy 358 monitoring, 4) service guarantees, 5) conflict resolution ,and 6) 359 restitution for lack of performance. 361 Application programmers are concerned with minimizing the interfaces 362 that they must learn to access middleware services. Thus the 363 unification of common services behind a single API is of great interest 364 to middleware users. Examples of common APIs that may be achievable 365 are: 367 * Environmental discovery interface, whether for discovering hardware 368 resources, network status and capabilities, data sets, applications, 369 remote services, or user information. 370 * Remote execution interface, whether for distributed metacomputing 371 applications, or for access to a digital library presentation service, 372 or a Java analysis service. 373 * Data management interface, whether for manipulating data within 374 distributed caches, or replication of data between file systems, or 375 archival storage of data. 376 * Process management interface, whether for composing data movement 377 with remote execution, or for linking together multiple processing 378 steps. 380 6.0 IETF AAA 382 The IETF AAA (authentication, authorization, and accounting) effort is 383 but one of many IETF security initiatives. It depends heavily on a 384 Public key infrastructure, which is intended to provide a framework 385 which will support a range of trust/hierarchy environments and a range 386 of usage environments (RFC1422 is an example of one such model). 388 The IETF AAA working group has recently been formed. IETF AAA working 389 group efforts are focused on many issues pertaining to middleware, 390 including defining processes for access/admission control and 391 identification (process for determining a unique entity), 392 authentication (process for validating that identity), authorization 393 (process for determining an eligibility for resource 394 requests/utilization) and accounting (at least to the degree that 395 resource utilization is recorded). To some degree, AAA provides for 396 addressing certain levels of security, but only at a preliminary level. 397 Currently, AAA protocols exist, although not as an integrated model or 398 standard. One consideration for AAA is to provide for various levels of 399 granularity. Even if we don't yet have an integrated model, it is 400 currently possible to provide for basic AAA mechanisms that can be used 401 as a basis to support SLAs. Any type of AAA implementation requires a 402 policy management framework, to which it must be linked. Currently, a 403 well-formulated linking mechanism has not been defined. 405 Middleware AAA requirements are also driven by the distributed 406 interoperation that can occur between middleware services. The 407 distribution of application support across multiple autonomous systems 408 will require self-consistent third-party mechanisms for authentication 409 as well as data movement. Conceptually, an application may need access 410 to data that is under control of a remote collection, to support the 411 execution of a procedure at a third site. 413 The data flow needs to be directly from the collection to the execution 414 platform for efficiency. At the same time, the procedure will need 415 access permission to the data set while it is acting on behalf of the 416 requestor. How the authentication is done between the remote procedure 417 and the remote data collection entities raises significant issues 418 related to transitivity of trust, and will require establishment of a 419 trust policy for third-party mechanisms. This is exacerbated when a 420 collection of entities, such as is required for visualization 421 applications, is involved. 423 7.0 Policy 425 The IETF Policy Framework working group is addressing a policy 426 framework definition language, a policy architecture model, policy 427 terminology and, specifically, a policy model that can be used for 428 signaled as well as provisioned QoS. The policy meta-model links high- 429 level business requirements, such as those that can be specified in an 430 SLA, to low-level device implementation mechanisms, ranging from 431 specific access control and management of services, objects and other 432 resources to configuration of mechanisms necessary to provide a given 433 service. 435 Polices are an integral component of all middleware services, and will 436 be found within most middleware services in one form or another. 437 Policies are often represented as an "if condition then action" tuple. 438 Policies can be both complex and numerous; therefore, policy management 439 services must be able to identify and resolve policy conflicts. They 440 also need to support both static (i.e. loaded at boot time via a 441 configuration file) and dynamic (i.e. the configuration of a policy 442 enforcing device may change based on an event) modes. 444 A generalized policy management architecture (as suggested by the IETF 445 policy architecture draft) includes a policy management service, a 446 dedicated policy repository, at least one policy decision point (PDP), 447 and at least one policy enforcement point (PEP). The policy management 448 service supports the specification, editing, and administration of 449 policy, through a graphical user interface as well as programmatically. 450 The policy repository provides storage and retrieval of policies as 451 well as policy components. These policy components contain definitional 452 information, and may be used to build more complex policies, or may be 453 used as part of the policy decision and/or enforcement process. The PDP 454 (e.g. resource manager, such as a bandwidth broker or an intra-domain 455 policy server) is responsible for handling events and making decisions 456 based on those events (e.g., at time x do y) and updating the PEP 457 configuration appropriately. In addition, it may be responsible for 458 providing the initial configuration of the PEP. The PEP (e.g., router, 459 firewall or host) enforces policy based on the "if condition then 460 action" rule sets it has received from the PDP. 462 Policy information may be communicated from the PDP to the PEP through 463 a variety of protocols, such as COPS or DIAMETER. A proxy may be used 464 to translate information contained in these protocols to forms that 465 devices can consume (e.g., command line interface commands or SNMP 466 sets). Additional information, contained in Policy Information Bases 467 (PIBs), may also be used to translate from an intermediate 468 specification to specific functions and capabilities of a device. For 469 example, a policy may specify "if source IP address is 198.10.20.132, 470 then remark traffic with a DSCP of 5". The PIB would be used to 471 translate the device-specific meaning of the conditioning specified by 472 the DiffServ code point of 5 (e.g., a specific set of queue and 473 threshold settings). 475 Policy requires AAA functions, not only for access control, but also to 476 establish the trust relationships that will enable distributed policy 477 interactions. PDPs may require the requesting end systems and 478 applications to be authenticated before the PDP will honor any 479 requests. The PDP and PEP must be authenticated to each other to reduce 480 the probability of spoofing. This will be true whichever protocol is 481 utilized for supporting communications between these entities. Audit 482 trails are essential for all of these transactions. In addition, trust 483 management policies will need to be developed as well as the supporting 484 middleware mechanisms to enable inter-domain policy negotiation. 486 Ultimately, many policy processes link entities to resources, 487 And therefore require interactions with entity identification 488 mechanisms, resource identification mechanisms, and allocation 489 mechanisms. The distributed computing community has already started 490 efforts developing policy definition languages and systems. Globus 491 uses its Resource Services Language (RSL) to define the resources and 492 policies associated with them. Condor uses a matchmaking bidding 493 technique to match those providing and those acquiring services. 494 Similarly, the IETF has several policy definition languages in varying 495 stages of development, including RPSL, RPCL, SPSL, PFDL, PAX, and 496 Keynote. Ultimately, these efforts should be merged into a single 497 specification (or at least a smaller group of specifications) to enable 498 distributed computing applications to be able to effectively 499 communicate and utilize network resources and services. 501 Directories play a crucial role in policy systems. Directories are 502 ideally suited for storing and retrieving policy information, due to 503 their exceptionally high read rates, ability to intelligently replicate 504 all or part of their information, per-attribute access control, and use 505 of containment. To this end, the IETF Policy Framework working group 506 (in conjunction with the DMTF) is developing a core information model 507 and LDAP schema that can be used to represent policy information that 508 applications can use. This core model is used to provide common 509 representation and structure of policy information. Applications can 510 then subclass all or part of the classes in this core schema to meet 511 their own specific needs, while retaining the ability to communicate 512 and interoperate with each other. 514 8.0 Directories 516 Directories are critical resource components that provide support to 517 many other elements in the middleware environment, especially policy. 518 As network-based environment evolves, it will no longer be viable to 519 encode policy information directly into each individual application. 520 The prevailing model in use today is for each application to store its 521 view of a device's data (e.g., configuration) in its own private data 522 store.These data include relevant information concerning network 523 resources and services as well as clients wanting to use those 524 resources (e.g., people, processes, and applications). The same 525 resource (or aspects of that resource, such as its physical vs. logical 526 characteristics) may be represented in several data stores. Even if the 527 device is modeled the same way in each data store, each application 528 only has access to its own data. This leads to duplication of data and 529 data synchronization problems. 531 The promise of technologies like CIM and DEN is to enable each 532 application to store data describing the resources that they manage in 533 a single directory using a common format and access protocol. This 534 results in the data describing the resource being represented only 535 once. Defining a logically centralized common repository, where 536 resources and services are represented in a common way, enables 537 applications of different types to utilize and share information about 538 resources and services that they use. 540 Not only does this solve the data duplication and synchronization 541 problems, it also provides inherent extensibility in describing the 542 characteristics of an object - a single entity can be represented by 543 multiple directory objects, each representing a different aspect of the 544 entity. Different applications can be responsible for managing the 545 different objects that together make up a higher-level object, even if 546 the applications themselves can not communicate with each other. This 547 enables these applications to effectively share and reuse data. 548 This provides significant benefits for users and applications. In the 549 short term, users and applications will benefit from having all of the 550 data in one place. In the long term, users and applications will be 551 able to take advantage of data managed by other applications. 553 Directories are key to supporting advanced network-based application 554 environments. Directory purists say that the directory is not 555 middleware; rather, it is a dumb storage device that is made into an 556 intelligent repository by encapsulating it within middleware. Although 557 a directory associates attributes with objects, what makes it different 558 from a database are four key things: 560 - directory objects are essentially independent of each other, 561 whereas database objects are related to each other (sometimes in 562 very complex ways) 563 - directories organize their information using the notion of 564 containment, which is not naturally implemented in databases 565 - directory objects can have specific access controls assigned to 566 an object and even attributes of an object 567 - directories, unlike databases, are optimized to perform a high 568 number of reads vs. writes. 570 Directories use a common core schema, supporting a common set of 571 syntaxes and matching rules, that defines the characteristics of their 572 data. This enables a common access protocol to be used to store and 573 retrieve data. 575 Containment can be used for many purposes, including associating roles 576 with objects. This is critical in order to support a real world 577 environment, where people and elements may assume different roles based 578 on time or other context.Containment may also be used to provide 579 different naming scopes for a given set of data. 581 Directories use attribute inheritance - subclasses inherit the 582 attributes of their superclasses. This enables one to define 583 generalized access control at a container (e.g., a group) and then 584 refine the access control on an individual basis for objects that are 585 inside that container (e.g., different objects have different access 586 privileges). 588 Currently, directories are used mostly to represent people, servers, 589 printers, and other similar objects. CIM, DEN, and other similar 590 efforts have encouraged directories to be used to contain common 591 objects in a managed environment. For networked applications, this 592 enables clients of the network (e.g., users and applications) to be 593 bound to services available in the network in a transparent manner. 594 The "Grid" community is making extensive use of directory services for 595 this purpose, using them to maintain information about the structure 596 and state of not only networks but also computers, storage systems, 597 software, and people. The DMTF is using directories to contain CIM and 598 DEN information, which enables a common information model to be applied 599 to objects in a managed environment. The IETF is using directories for 600 many different purposes, not the least of which is to contain common 601 policy information for users and applications of an environment, as 602 well as services and configuration information of network devices. 604 CIM and DEN are conceptual information models for describing the 605 management of entities ranging from network elements to protocols to 606 hosts and services. CIM and DEN are platform- and technology- 607 independent. DEN is an extension of CIM that, among other things, 608 describes how to map CIM data into a form usable by LDAP. 610 The CIM Specification describes the meta schema, information model, 611 language, naming, and mapping techniques to other management models, 612 such as SNMP MIBs and DMTF MIFs. DEN provides a good start on a model 613 that addresses the management of the network and its elements; DEN is 614 an extension of CIM to include the management of networks as a whole 615 and not just the individual elements. DEN addresses the requirements 616 for abstracting a complex entity, such as a router, into multiple 617 components that can be used to manage individual aspects of that 618 complex entity. The DEN information model, like CIM, incorporates both 619 static and dynamic information. DEN provides a mapping to directories 620 for the storage and retrieval of data. DEN will also rely heavily on 621 the use of AAA services in order to maintain the integrity of the 622 directory and its policies as well as to manage the distribution of 623 policies among the policy repositories, PDPs and PEPs. Resource 624 managers and applications will also rely heavily on directories for the 625 storage of policy and security information necessary for the management 626 and allocation of resources. 628 Since much of the information associated with a person, agent or 629 element is stored in a directory, and access to that information will 630 be controlled with appropriate security mechanisms, many voiced the 631 need for a single user/process sign on. 633 Future advanced applications (e.g., NGI, Internet2, PACI, Grids) may 634 require a variety of PDPs to manage a variety of resource types (i.e., 635 QOS, security, etc.). In this case, a general model would have to be 636 developed that defines the protocols and mechanisms used by cooperating 637 resource managers (i.e., PDPs) of different domains and different 638 genres of resource (i.e., network, security, storage, proxy agents, 639 online facility, etc.). For policies to be implemented in a coherent 640 fashion, it is necessary to have a mechanism that discovers and tracks 641 resources and utilization. 643 There is an architectural issue of central importance, which has most 644 recently surfaced in the directory area. Many applications, and many 645 middleware components, need what is essentially a highly scalable, 646 distributed database service. In other words, people want to take the 647 best of what directories and databases have to offer. This would result 648 in a distributed, replicated database that can use containment to 649 effectively organize and scope its information. It would be able to 650 have exceptional read response time, and also offer transactional and 651 relational integrity. It would support simple and complex queries. Such 652 a service has never been defined as a middleware component; the 653 complexities involved in specifying and implementing such a service are 654 certainly formidable. However, in the absence of such a general 655 service, many middleware components have attempted to use the closest 656 service available, which is deployed - historically first using DNS, 657 and more recently, directory services. 659 It will be important to clarify the limitations of the appropriate use 660 of directory services, and to consider whether a more general data 661 storage and retrieval service may be required, or whether directory 662 services can be seamlessly integrated (from the point-of-view of the 663 applications using them) with other forms of storage and retrieval 664 (such as relational databases) in order to provide an integrated 665 directory service with these capabilities. 667 9.0 Resource Management 669 Policy implementation processes need to be linked to Resource Managers 670 in a more sophisticated way than those that currently exist. Such 671 processes must be dynamic, and able to reflect changes in their 672 environment (e.g., adjust the quality of service provided to an 673 application based on environmental changes, such as congestion or new 674 users with higher priorities logging onto the system). We need to 675 determine how different types of resource managers learn about one 676 another and locate each other - as well as deal with associated cross- 677 domain security issues. Another aspect of this problem is developing a 678 resource definition language that can describe the individual elements 679 of the resource being utilized, whether that is a network, processor, 680 agent, memory or storage. This will require developing an appropriate 681 metadata representation and underlying meta schema that can be applied 682 to multiple resource types. 684 Some models of resource managers are currently being used to provide 685 for the management of distributed computing and Grid environments 686 (e.g., Condor, Globus, and Legion). These resource managers provide 687 languages, clients, and servers to support accessing various types of 688 distributed computing resources (e.g. processors, memory, storage and 689 network access). There is a broad interest in the distributed and 690 parallel computing communities in developing an automated access 691 control architecture, using policies, to support the evolving IETF 692 differentiated services architecture. However, this work has not yet 693 been incorporated into any IETF working group charter. The term 694 "bandwidth broker" has been used to refer to the agents that will 695 implement this functionality through network resource management, 696 policy control, and automated edge device configuration. The IETF 697 Policy Framework working group is currently working on a policy 698 architecture framework, information model, and policy definition 699 language that is targeted initially at policy management within a 700 single domain. However, this work is fundamental in defining inter- 701 domain policy management issues, such as those that are required in 702 implementing a network resource manager / bandwidth broker. Many 703 resource managers being deployed today rely on directory services for 704 storing policy information as well as X.509 for certificate-based 705 authentication and authorization to these resources. Middleware will be 706 required to translate the needs of distributed and parallel computing 707 applications within and across different policy domains. It is crucial 708 that a standard means for representing and using resource management be 709 developed. 711 Advance reservation of resources, as well as dynamic requests for 712 resources, is a crucial aspect of any resource management system. 713 Advance reservations are more of a policy issue than a provisioning 714 issue; however, the mechanisms for exchanging and propagating such 715 requests between resource managers located within different 716 administrative domains is a currently unsolved problem that needs to be 717 addressed. In addition, it is important to address the issue of 718 possible deadlock and/or the inefficient use of resources (i.e., the 719 time period between a request, or set of requests, being initiated and 720 honored and resources being allocated). There is also a need for 721 rendezvous management in resource allocation services, where an 722 application must gather resource reservations involving multiple sites 723 and services. 725 A mesh of cooperating resource managers, which interact with each other 726 using standards based protocols (e.g. COPS), could be the model for a 727 resource management infrastructure. Each of these may manage different 728 sets of resources. For example, one may be a bandwidth broker that only 729 manages network bandwidth, while another may be a general-purpose 730 resource manager that manages security, IP address allocation, storage, 731 processors, agents, and other network resources. There are already 732 plans for middleware resource managers that not only allocate the 733 resources but also manage the composition of a group of services that 734 may includesecurity services, billing services, shaping of multimedia 735 composite images, etc.). Another form of resource manager may provide 736 mapping between a set of related services (i.e., mapping an IP based 737 RSVP request to an ATM SVC, as was demonstrated in a pilot project on 738 the vBNS). 740 Resource managers depend on the use of locator services to find other 741 resource managers as well as to locate the AAA server(s) for the 742 requestor and the associated directories containing applicable policy 743 information. They may also need to query the network to determine if a 744 policy request for bandwidth can be satisfied. It is essential that 745 these (and other) different uses of resource management be integrated 746 to provide an end-to-end service for applications and users alike. 748 10.0 Networked Information Discovery and Retrieval Services 750 There are a wide range of middleware services broadly related to the 751 discovery and retrieval of networked information. Because such a broad 752 range of applications (and not just high-performance, distributed, or 753 parallel applications) requires these services, this area is under very 754 active development and new reqirements are constantly emerging. 756 Perhaps the most basic service in this area is persistent naming and 757 location services (and infrastructure) that can resolve names to 758 locations (i.e., URLs). The IETF has done considerable work in defining 759 a syntax for Uniform Resource Identifiers (URIs), which are intended to 760 be persistent name spaces administered by a wide range of agencies. 761 URIs are resolved to URLs using resolver services; there are a number 762 of different proposals for such resolver services, and some 763 implementations exist such as the CNRI Handler Service. Many 764 organizations are beginning to establish and manage URI namespaces, 765 notably the publishing community with their Digital Object Identifier 766 (DOI). however, there are many unresolved questions, such as how to 767 most effectively deal with the situation where the resource named by a 768 URI exists in multiple places on the network (e.g., find the "closest" 769 mirror in terms of network connectivity and resource availability). 770 There is a need for an extensive set of infrastructure around 771 resolvers, including how resources are registered and identifiers are 772 assigned, the ongoing management of data about the current location of 773 resources that are identified by a specific URI, and the operation of 774 sets of resolvers for various name spaces. Finally, given a URI, one 775 needs to locate the resolver services that are connected with that 776 namespace; the IETF has done initial work on resolution service 777 location for URI namespaces. 779 URIs are intended to be processed primarily by machines; they are not 780 intended to necessarily be easy to remember, though they are intended 781 to be robust under transcription (not sensitive to whitespace, for 782 example). More recently, the IETF has begun work on defining 783 requirements for human friendly identifier systems that might be used 784 to register and resolve mnemonic names. 786 Another set of issues revolves around various types of metadata - 787 descriptive, ratings, provenance, rights mangement, and the like, that 788 may be associated with objects on the network. The Resource Description 789 Framework (RDF) from the Worldwide Web Consortium (W3C) provides a 790 syntax for attaching such descriptions to network objects and for 791 encoding the descriptions; additional middleware work is needed to 792 locate metadata associated with objects that may be stored in 793 repositories, and to retrieve such metadata. Validation of metadata is 794 a key issue, and both IETF and W3C are working on XML canonicalization 795 algorithms that can be used in conjunction with public key 796 infrastructure to sign metadata assertions. However, such an approach 797 implies a complex set of trust relationships and hierarchies that will 798 need to be managed, and policies that will need to be specified for the 799 use of these trust relationships in retrieval. 801 There is specific work going on in defining various types of metadata 802 for applications such as rights management; ultimately this will imply 803 the development of middleware services. It will also impact the use of 804 directory, database, and similar services in the storage, access, and 805 retrieval of this information. Similarly, there will be a need for 806 services to connect descriptive metadata and identifiers (URNs). 808 (See also the NSF/ERCIM report on metadata research issues at 809 http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.html 810 http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.ps 811 http://www.ercim.org/publication/ws-proceedings/EU-NSF/metadata.pdf 813 Finally, there is a need for a set of middleware services which build 814 upon the research work already integrated into services such as Archie 815 and Harvest. These services permit the efficient extraction of metadata 816 about the contents of network information objects and services without 817 necessarily retrieving and inspecting those services. This includes the 818 ability to dispatch "indexing agents" or "knowbots" that can run at a 819 site to compute such indexing, under appropriate security and 820 authentication constraints. In addition, a set of "push-based" broker 821 services which aggregate, filter and collect metadata from multiple 822 sites and provide them to interested applications are also required. 823 Such services can provide a massive performance, quality, 824 comprehensiveness and timeliness improvement for today's webcrawler- 825 based indexing services. 827 11.0 Network QoS 829 As noted earlier, applications may need to explicitly request resources 830 available in the network to meet their requirements for certain types 831 of communication, or in order to provide service with an appropriate 832 guarantee of one or metrics, such as bandwidth, jitter, latency, and 833 loss. One type of request that has been the focus of much effort 834 recently is for services beyond best effort, particularly with respect 835 to services running over IP. This is particularly important for the 836 advanced applications noted previously (e.g., visualization and 837 teleimmersion) as well as the emerging importance of voice and video, 838 especially voice and video operating with lower bandwidth or voice and 839 video co-mingled with data. One perspective on this issue is to 840 consider the effect of multiple drops in a single RTT, which is 841 catastrophic for TCP applications but may be of no special significance 842 for real-time traffic. 843 Providing for improved services can be accomplished through a variety 844 of quality of service (QoS) and class of service (CoS) mechanisms. The 845 first IETF model was the Integrated Services (IntServ) model, which 846 used RSVP as the signaling mechanism. Since this model requires state 847 in every router for every session and to manage the traffic flows, it 848 is generally recognized to have scaling limits. However, it is very 849 appropriate for certain situations. 851 Differentiated Services, or DiffServ, grew out of a reaction against 852 the perceived scalability problems with the IETF IntServ model. 853 DiffServ is an architecture for implementing scalable service 854 differentiation in the Internet. Scalability is achieved by aggregating 855 traffic through the use of IP-layer packet marking. Packets are 856 classified and marked to receive a particular per-hop forwarding 857 behavior on nodes along their path. Sophisticated classification, 858 marking, policing, and shaping operations need only be implemented at 859 network boundaries or hosts. Network resources are allocated to 860 traffic streams by service provisioning policies which govern how 861 traffic is marked and conditioned upon entry to a differentiated 862 services-capable network, and how that traffic is forwarded within that 863 network. These simple PHBs are combined with a much larger number of 864 policing policies enforced at the network edge to provide a broad and 865 flexible range of services, without requiring state or complex 866 forwarding decisions to be performed in the core and distribution 867 layers. 869 Recently, the idea of "tunneling" RSVP over a DiffServ-capable network 870 has generated significant interest. This attempts to combine the best 871 features of both IntServ and DiffServ while mitigating the 872 disadvantages of each. This in turn has led the IETF to study ways to 873 ensure that Differv and Inteserv can not only coexist, but are also 874 interoperable. 876 The practical realization of either or both architectures depends on 877 many middleware components, some of which are described in this 878 document. The workshop discussion mainly focused on DiffServ mechanisms 879 and on what effect such mechanisms would have on middleware and its 880 ability to monitor and manage the network infrastructure for the 881 benefit of the applications. Both IntServ and DiffServ only fully make 882 sense if linked to a policy mechanism. This mechanism must be able to 883 make policy decisions, detect and resolve conflicts in policies, and 884 enforce and monitor policies. 886 Workshop participants almost unanimously agreed that they also required 887 a scalable inter-domain resource manager (e.g., a bandwidth broker). 888 Currently, if an RSVP session is run, each router along a path becomes 889 involved, with flow policing at each hop. Bandwidth Broker models 890 include the bandwidth broker, a policy decision point (which makes 891 admission control and policy decisions) and the policy enforcement 892 points (i.e., edge routers) which provide for policing at the first hop 893 and for remarking aggregate flows so that subsequent routers need only 894 deal with the aggregate flows. 896 IETF protocols that could be used to implement a Bandwidth Broker model 897 (e.g., COPS, Diameter, and others) were also discussed. The Diameter 898 protocol is interesting in this context, because it provides set up 899 mechanisms for basic network resource allocations and reallocations, as 900 well as optional allocations.- All of these can be used for various 901 types of bandwidth broker implementations, including those directed at 902 QoS, using RSVP type information. Diameter currently does not provide 903 path information, but instead relies on network pathway information 904 established at ingress and egress nodes. However, the status of 905 Diameter is still open in the IETF. 907 COPS was initially developed as a mechanism for establishing RSVP 908 policy within a domain and remains intra-domain centric. It is a useful 909 intra-domain mechanism for allocating bandwidth resources within a 910 policy context. Work is now being conducted to use COPS for 911 establishing policy associated with a DiffServ-capable network. COPS is 912 designed to facilitate communication between the PDP and the PEP, 913 carrying policy decisions and other information. 915 To implement any type of Bandwidth Broker model, it is necessary to 916 establish a mechanism for policy exchanges. The Internet2's Qbone 917 working group is currently working to define a prototype inter-domain 918 bandwidth broker signaling protocol. This work is being coordinated 919 with IETF efforts. 921 Another mechanism is required for traffic shaping and SLA policing and 922 enforcement. One mechanism is fair queuing in its various forms, which 923 has been described as TDM emulation without the time and space 924 components. Techniques have been used for several years for fair 925 queuing for low speed lines. For DS-3 with 40 byte packets and OC-3c 926 speeds with 200-byte packets, weighted fair queuing uses a deficit 927 round-robin algorithm that allows it to scale. It is capable of flow 928 discrimination based on stochastically hashing the flows. An additional 929 expansion of this technique is to preface this technique with class 930 indicators. Currently, classification techniques are based on IP 931 precedence. However, classification will soon be achieved in many 932 routers using Diffserv code points (DSCPs) to specify the type of 933 conditioning to be applied. The complete requirements of policing for 934 DiffServ implementations, e.g., via bandwidth brokers, have not yet 935 been fully explored or defined. 937 Network monitoring capabilities (i.e., querying the network for state 938 information on a micro and macro level) that support middleware and 939 application services were identified as a core requirement. In fact, a 940 network instrumentation and measurement infrastructure, upon which a 941 set of intelligent network management middleware services can be built, 942 is absolutely critical. 944 Current mechanisms (e.g. ICMP, SNMP) were not deemed robust enough for 945 middleware and applications developers to determine the state of the 946 network, or to verify that they were receiving the specific type of 947 treatment they had requested. This was judged especially true of a 948 network providing QoS or CoS. Indeed, it is not at all clear that SNMP, 949 for example, is even the right architectural model for middleware to 950 use to enable applications to determine the state of the network. Other 951 capabilities, such as OcxMon, RTFM, new MIBs, and active measurement 952 techniques (e.g., IPPM one-way delay metrics) need to be made available 953 to middleware services and applications. 955 The provisioning of differentiated services takes the Internet one step 956 away from its "dumb" best effort status. As the complexity of the 957 network increases (e.g. VPNs, QoS, CoS, VoIP, etc.), more attention 958 must be paid to providing the end-user/customer or network 959 administrator with the tools they require to securely and dynamically 960 manage an adaptable network infrastructure. Differentiated services 961 means that theoretically some traffic gets better service than other 962 traffic; subsequently, one can expect to pay for better service, which 963 means that accounting and billing services will be one of the important 964 middleware core components that others will rely upon. The model and 965 protocols necessary to accomplish this are not developed yet. 967 12.0 Authentication, Authorization, and Accounting 969 The IETF's AAA working group is focusing on the requirements for 970 supporting autghentication, authorization, accounting, and auditing of 971 access to and services provided bynetwork resource managers (e.g., 972 bandwidth brokers). These processes constitute an important security 973 infrastructure that will be relied upon by middleware and applications. 974 However, these components are only basic security components. A public 975 key infrastructure (PKI) was identified as a crucial security service 976 infrastructure component. For example, the PKI will be required to 977 support the transitivity of authentication, authorization, and access 978 control and, where appropriate, accounting and billing. It was noted 979 that, except for issues dealing with group security and possibly more 980 efficient and simple management, there are no real technical challenges 981 preventing the wide scale deployment of a PKI support structure at this 982 time. Instead, the main obstacles to overcome are mostly political and 983 economic in nature. However, additional middleware may be required to 984 better facilitate a PKI. That being said, some people believe that we 985 do have some large technical security challenges, revocation lists and 986 security with respect to changing group memberships being two examples. 988 Middleware and security support is also required for newer applications 989 (e.g., proxy agents that would act on a process or application's behalf 990 and gather the necessary certificates for access and using resources). 991 A particularly difficult example is remote collaboration. Accessing a 992 particular resource may require a user and/or application to gather 993 certificates from more than one policy-controlling agent. It is also 994 true that an entity may have various identities that are dependent on 995 the task they are performing (usage or role based) or the context of 996 the application. In order for the PKI to become truly functional on a 997 ubiquitous level, there needs to exist a set of independent signing 998 authorities that can vouch for the top-level certificate authorities. 1000 There are also higher-level middleware services which will build on 1001 public key infrastructure, notary services and provenance verification. 1002 As we move from a relatively dumb network (e.g. best effort IP) to an 1003 Internet with embedded intelligence (e.g., DiffServ, IntServ, bandwidth 1004 brokers, directory-enabled networks, etc.), the secure exchange of 1005 information will become even more important. In addition, as we start 1006 to provide differentiated services, accounting and statistics gathering 1007 will become much more important. We also need to provide for the 1008 integrity and security of collecting, analyzing, and transporting 1009 network management and monitoring information. And the issues of data 1010 privacy and integrity, along with addressing denial of service and non- 1011 repudiation, cannot be ignored. 1013 13.0 Network Management, Performance, and Operations 1015 Network management capabilities were identified as being paramount to 1016 the success of middleware deployment, and subsequently to the success 1017 of the application. Many of the issues addressed here are not part of 1018 standard NOC operations. In a more complex world of QoS, CoS, and micro 1019 prioritization, reactions to network failures must be handled 1020 differently than current procedures. Allocations are more dynamic, 1021 especially additions, deletions, and changes with additional sets of 1022 requirements, such as priorities and new types of inter-domain 1023 interactions. These will inevitably increase the complexity of network 1024 management. 1026 There are many microscopic and macroscopic network management projects 1027 focusing on making both active and passive network statistics and 1028 information available to end-users. Current visual debugging and 1029 analysis capabilities (e.g., those developed by NLANR/CAIDA) are 1030 crucial tools for network administrators and designers for 1031 understanding their networks. In addition, current network management 1032 techniques and mechanisms, which were designed for network designers 1033 and managers, need to be adapted to provide a dynamic and relevant set 1034 of information to the middleware or application service software. This 1035 will allow the programs to dynamically adapt to the changing state of 1036 the network infrastructure while ensuring the integrity and security of 1037 the network and other resources. 1039 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 1040 common framework for modeling the management of network elements and 1041 services as well as users, applications, and other resources of the 1042 network. Undoubtedly, middleware designers will place new requirements 1043 on CIM and DEN that will cause these approaches to evolve. 1045 14.0 Middleware to support multicast applications 1047 IP multicast - that is, the routing and forwarding of mutlicast packets 1048 in an IP-based network, is in the view of the workshop part of the 1049 basic network infrastructure. The Internet Group Multicast Protocol, 1050 which manages the joining and leaving of multicast groups, could also 1051 be considered a basic network service. However, there is a tremendous 1052 need for middleware services to make multicast useable for various 1053 applications, much like TCP played a key role in making IP applications 1054 useable. Specifically, one might reasonably want middleware services to 1055 provide authenticated control of multicast services. Examples of these 1056 services include the creation and joining of multicast groups, 1057 multicast address management, multicast channel directories (there has 1058 already been considerable work in this area), various forms of reliable 1059 multicast services (this has been an IRTF research area), and to secure 1060 multicast groups through various cryptographic strategies. In addition, 1061 because of the large impact that multicast can have on a network, 1062 multicast management middleware services, particularly in conjunction 1063 with QoS, will be needed, as will services to link together 1064 multicasting within various networks that do not directly interchange 1065 multicast routing information. It should be noted, however, that 1066 several security issues with multicast, especially groups with dynamic 1067 membership policies, still need to be resolved. 1069 15.0 Java and Jini 1071 Java was chosen as an example of a heterogeneous runtime support system 1072 for the sake of discussion as to whether it could be qualified as a 1073 development language particularly suitable for the development of 1074 middleware. The consensus was that the Java language and compilers are 1075 important in the current distributed model of the Internet and for the 1076 support of middleware (i.e., middleware written using Java). Also, a 1077 virtual Java machine located on a system can be considered middleware 1078 as much as any operating system or network operating systems would be 1079 considered middleware. Jini middleware technology not only defines a 1080 set of protocols for discovery, join, and lookup, but also a leasing 1081 and transaction mechanism to provide resilience in a dynamic networked 1082 environment. Java and Jini will be dependent on a functioning PKI, 1083 especially for signed applets. That being said, there are security 1084 concerns with both Java and Jini that need to be addressed, such as 1085 allowing the downloading of applets and servlets. 1087 16.0 Security Considerations 1089 This document is a report of a workshop in which security was a common 1090 theme, as can be seen by the references to security through out the 1091 document; but the workshop did not reach any specific recommendations 1092 for new security-related terminology. 1094 17.0 Summary 1096 Middleware may have components and services that only exist in the 1097 persistent infrastructure, but it will also have components that enable 1098 and support end-to-end (i.e. application to application or host to 1099 host) interaction across multiple autonomous administrative domains. A 1100 set of core persistent middleware services is required to support the 1101 development of a richer set of middleware services which can be 1102 aggregated or upon which applications will be based (e.g., an onion or 1103 layered model). This set of core middleware services will help 1104 applications leverage the services and capabilities of the underlying 1105 network infrastructure, along with enabling applications to adjust in 1106 changes to the network. The particular set of such services utilized by 1107 an application or process will be a function of the requirements of the 1108 application field or affinity group (e.g., network management or high 1109 energy physics applications) wishing to utilize the network or 1110 distributed data/computation infrastructure. This document discusses 1111 some of the basic and core middleware services, which include, but are 1112 not limited to: directories, name/address resolution services, security 1113 services (i.e., authentication, authorization, accounting, and access 1114 control), network management, network monitoring, time servers, and 1115 accounting. Network level capabilities, such as multicast and 1116 DiffServ, are not classified as middleware; rather, they are enabling 1117 infrastructure services upon which middleware will be built or which 1118 middleware may use and manage. A second level of important middleware 1119 services, which builds upon these core set of services, may include 1120 accounting/billing, resource managers, single sign-on services, 1121 globally unique names, metadata servers, and locators. 1123 A recognized goal is to provide a set of middleware services that 1124 enable access to and management of the underlying network 1125 infrastructure and support applications wishing to make use of that 1126 network-based infrastructure. It appears necessary to agree to a 1127 framework of services for the support, provisioning and operations, and 1128 management of the network. Today, we have piecemeal activities already 1129 being pursued in various standards organizations. These include efforts 1130 in the IETF and DMTF (e.g., AAA, Policy Framework, DiffServ, DEN, CIM, 1131 etc.), as well as in the advanced application environments (e.g., Grid 1132 Forum, the PACIs, NGI, Internet2, etc.). Both of these efforts require 1133 the integration and management of many infrastructure components, not 1134 just networks; however, we have no overall framework that pulls all of 1135 these together, or a mechanism to coordinate all of these activities. 1137 We are just embarking on the development of a rich plan of middleware 1138 services. Consequently, we have a lot of work yet to be done. For 1139 instance, as we move into an electronic persistent presence (EPP) 1140 environment where multiple instances of an identity or person (or even 1141 their proxy agents) are supported, we will require enhanced locator and 1142 brokering services. The directory (e.g., DNS or X.500) and locator 1143 services of today may not be appropriate for this task. 1145 One goal of the workshop was to identify research and development areas 1146 in middleware that federal agencies and industry may choose to support. 1147 The workshop highlighted a few areas that may benefit from additional 1148 R&D support. These areas include, but are not limited to: 1150 - inter-domain resource management architecture and protocols (e.g., 1151 inter-domain bandwidth brokers) 1152 - resource languages that describe and enable the management of a wide 1153 variety of resources (e.g., networks, data bases, storage, online 1154 facilities, etc. 1155 - avoiding deadlock and ensuring efficiency with resource managers 1156 - network management tools and APIs that provide macroscopic and 1157 microscopic real-time infrastructure 1158 - information to middleware services and applications (not just MIBs 1159 and SNMP access) 1160 - domain and inter-domain accounting and billing 1161 - monitoring and verification services of contracted infrastructure 1162 services 1163 - enhanced locators that can locate resources and resource managers 1164 - cross administrative policy negotiation and authentication 1165 - middleware bypass (i.e. access to raw system or network resources 1166 - metadata (i.e., data that is used to describe data found in 1167 directories or exchanged between services such as resource managers, 1168 PDPs, PEPs, directories, accounting and billing services, etc.) 1169 - middleware support for mobile or nomadic use 1170 - support for availability of resources (i.e. replication and load 1171 balancing 1173 This workshop was just one small step in identifying relevant 1174 middleware topics, technologies and players. Even though this workshop 1175 did not arrive at a consensual definition of middleware, it did 1176 identify the need for additional work. Specifically, further work is 1177 needed to identify and qualify middleware services for specific 1178 affinity groups (e.g. Internet2, Education, the PACIs, Grids, etc.) as 1179 well as to define a macroscopic framework that incorporates the 1180 middleware work of the IETF, DMTF and other relevant organizations such 1181 as the Grid Forum. 1183 18.0 Participants 1185 Deb Agarwal ,Bob Aiken ,Guy 1186 Almes ,Chase Bailey ,Fred Baker 1187 ,Pete Beckman ,Javad Boroumand 1188 ,Scott Bradner ,George Brett 1189 ,Rich Carlson , 1190 Brian Carpenter ,Charlie Catlett 1191 ,Bill Cheng ,Kim Claffy 1192 ,Bill Decker Wdecker@nsf.gov,Christine Falsetti 1193 ,Ian Foster ,Andrew 1194 Grimshaw ,Ed Grossman 1195 ,Ted Hanss ,Ron Hutchins 1196 , Larry Jackson , Bill 1197 Johnston , Juerg von Kaenel ,Miron 1198 Livny ,Cliff Lynch ,Joel Mambretti 1199 ,Reagan Moore , Klara Nahstedt 1200 ,Mike Nelson , Bill Nitzberg 1201 , Hilarie Orman , John Schnizlein 1202 , Rick Stevens ,John Strassner 1203 , Ben Teitelbaum ,George Vanecek 1204 ,Ken klingenstein , 1205 Arvind Krishna ,Dilip Kandlur