rfc2768.txt

中、英文RFC文档大全打包下载完全版 .

   "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 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
   netwo