rfc2768.txt

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

   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



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


   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



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


   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.




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


   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,



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


   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 networ