rfc2638.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,223 行 · 第 1/5 页

   available at any time, for example paying for a telephone line. A
   customer might pay an additional flat fee to have the privilege of
   calling a wide local area for no additional charge or might pay by
   the call. Although a customer might pay on a "per call" basis for
   every call made anywhere, it generally turns out not to be the most
   economical option for most customers. It's possible similar pricing
   structures might arise in the internet.

   We use Allocation to refer to the process of making Marked traffic
   commitments anywhere along this continuum from strictly preallocated
   to dynamic call set-up and we require an Allocation architecture
   capable of encompassing this entire spectrum in any mix. We further
   observe that Allocation must follow organizational hierarchies, that
   is each organization must have complete responsibility for the
   Allocation of the Marked traffic resource within its domain. Finally,
   we observe that the only chance of success for incremental deployment
   lies in an Allocation architecture that is made up of bilateral
   agreements, as multilateral agreements are much too complex to
   administer. Thus, the Allocation architecture is made up of
   agreements across boundaries as to the amount of Marked traffic that
   will be allowed to pass. This is similar to "settlement" models used
   today.

4.1 Bandwidth Brokers: Allocating and Controlling Bandwidth Shares

   The goal of differentiated services is controlled sharing of some
   organization's Internet bandwidth. The control can be done
   independently by individuals, i.e., users set bit(s) in their packets
   to distinguish their most important traffic, or it can be done by
   agents that have some knowledge of the organization's priorities and
   policies and allocate bandwidth with respect to those policies.
   Independent labeling by individuals is simple to implement but
   unlikely to be sufficient since it's unreasonable to expect all
   individuals to know all their organization's priorities and current
   network use and always mark their traffic accordingly.  Thus this
   architecture is designed with agents called bandwidth brokers (BB)
   [2], that can be configured with organizational policies, keep track
   of the current allocation of marked traffic, and interpret new
   requests to mark traffic in light of the policies and current
   allocation.

   We note that such agents are inherent in any but the most trivial
   notions of sharing.  Neither individuals nor the routers their
   packets transit have the information necessary to decide which
   packets are most important to the organization.  Since these agents
   must exist, they can be used to allocate bandwidth for end-to-end
   connections with far less state and simpler trust relationships than



Nichols, et al.              Informational                     [Page 14]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   deploying per flow or per filter guarantees in all network elements
   on an end-to-end path. BBs make it possible for bandwidth allocation
   to follow organizational hierarchies and, in concert with the
   forwarding path mechanisms discussed in section 3, reduce the state
   required to set up and maintain a flow over architectures that
   require checking the full flow header at every network element.
   Organizationally, the BB architecture is motivated by the observation
   that multilateral agreements rarely work and this architecture allows
   end-to-end services to be constructed out of purely bilateral
   agreements. BBs only need to establish relationships of limited trust
   with their peers in adjacent domains, unlike schemes that require the
   setting of flow specifications in routers throughout an end-to-end
   path. In practical technical terms, the BB architecture makes it
   possible to keep state on an administrative domain basis, rather than
   at every router and the service definitions of Premium and Assured
   service make it possible to confine per flow state to just the leaf
   routers.

   BBs have two responsibilities. Their primary one is to parcel out
   their region's Marked traffic allocations and set up the leaf routers
   within the local domain. The other is to manage the messages that are
   sent across boundaries to adjacent regions' BBs. A BB is associated
   with a particular trust region, one per domain. A BB has a policy
   database that keeps the information on who can do what when and a
   method of using that database to authenticate requesters. Only a BB
   can configure the leaf routers to deliver a particular service to
   flows, crucial for deploying a secure system. If the deployment of
   Differentiated Services has advanced to the stage where dynamically
   allocated, marked flows are possible between two adjacent domains,
   BBs also provide the hook needed to implement this. Each domain's BB
   establishes a secure association with its peer in the adjacent domain
   to negotiate or configure a rate and a service class (Premium or
   Assured) across the shared boundary and through the peer's domain. As
   we shall see, it is possible for some types of service and
   particularly in early implementations, that this "secure association"
   is not automatic but accomplished through human negotiation and
   subsequent manual configuration of the adjacent BBs according to the
   negotiated agreement. This negotiated rate is a capability that a BB
   controls for all hosts in its region.

   When an allocation is desired for a particular flow, a request is
   sent to the BB. Requests include a service type, a target rate, a
   maximum burst, and the time period when service is required. The
   request can be made manually by a network administrator or a user or
   it might come from another region's BB. A BB first authenticates the
   credentials of the requester, then verifies there exists unallocated
   bandwidth sufficient to meet the request. If a request passes these
   tests, the available bandwidth is reduced by the requested amount and



Nichols, et al.              Informational                     [Page 15]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   the flow specification is recorded. In the case where the flow has a
   destination outside this trust region, the request must fall within
   the class allocation through the "next hop" trust region that was
   established through a bilateral agreement of the two trust regions.
   The requester's BB informs the adjacent region's BB that it will be
   using some of this rate allocation. The BB configures the appropriate
   leaf router with the information about the packet flow to be given a
   service at the time that the service is to commence. This
   configuration is "soft state" that the BB will periodically refresh.
   The BB in the adjacent region is responsible for configuring the
   border router to permit the allocated packet flow to pass and for any
   additional configurations and negotiations within and across its
   borders that will allow the flow to reach its final destination.

   At DMZs, there must be an unambiguous way to determine the local
   source of a packet. An interface's source could be determined from
   its MAC address which would then be used to classify packets as
   coming across a logical link directly from the source domain
   corresponding to that MAC address. Thus with this understanding we
   can continue to use figures illustrating a single pipe between two
   different domains.

   In this way, all agreements and negotiations are performed between
   two adjacent domains. An initial request might cause communication
   between BBs on several domains along a path, but each communication
   is only between two adjacent BBs. Initially, these agreements will be
   prenegotiated and fairly static. Some may become more dynamic as the
   service evolves.

4.2 Examples

   This section gives examples of BB transactions in a non-trivial,
   multi-transit-domain Internet. The BB framework allows operating
   points across a spectrum from "no signalling across boundaries" to
   "each flow set up dynamically". We might expect to move across this
   spectrum over time, as the necessary mechanisms are ubiquitously
   deployed and BBs become more sophisticated, but the statically
   allocated portions of the spectrum should always have uses. We
   believe the ability to support this wide spectrum of choices
   simultaneously will be important both in incremental deployment and
   in allowing ISPs to make a wide range of offerings and pricings to
   users. The examples of this section roughly follow the spectrum of
   increasing sophistication. Note that we assume that domains contract
   for some amount of Marked traffic which can be requested as either
   Assured or Premium in each individual flow setup transaction. The
   examples say "Marked" although actual transactions would have to
   specify either Assured or Premium.




Nichols, et al.              Informational                     [Page 16]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   A statically configured example with no BB messages exchanged: Here
   all allocations are statically preallocated through purely bilateral
   agreements between users (individual TCPs, individual hosts, campus
   networks, or whole ISPs) [6]. The allocations are in the form of
   usage profiles of rate, burst, and a time during which that profile
   is to be active. Users and providers negotiate these Profiles which
   are then installed in the user domain BB and in the provider domain
   BB. No BB messages cross the boundary; we assume this negotiation is
   done by human representatives of each domain. In this case, BBs only
   have to perform one of their two functions, that of allocating this
   Profile within their local domain. It is even possible to set all of
   this suballocations up in advance and then the BB only needs to set
   up and tear down the Profile at the proper time and to refresh the
   soft state in the leaf routers. From the user domain BB, the Profile
   is sent as soft state to the first hop router of the flow during the
   specified time. These Profiles might be set using RSVP, a variant of
   RSVP, SNMP, or some vendor-specific mechanism. Although this static
   approach can work for all Marked traffic, due to the strictly not
   oversubscribed requirement, it is only appropriate for Premium
   traffic as long as it is kept to a small percentage of the bottleneck
   path through a domain or is otherwise constrained to a well-known
   behavior. Similar restrictions might hold for Assured depending on
   the expectation associated with the service.

   In figure 6, we show an example of setting a Profile in a leaf
   router. A usage profile has been negotiated with the ISP for the
   entire domain and the BB parcels it out among individual flows as
   requested. The leaf router mechanism is that shown in figure 3, with
   the token bucket set to the parameters from the usage profile. The
   ISP's BB would configure its own Profile Meter at the ingress router
   from that customer to ensure the Profile was maintained. This
   mechanism was shown in figure 5. We assume that the time duration and
   start times for any Profile to be active are maintained in the BB.
   The Profile is sent to the ingress device or cleared from the ingress
   device by messages sent from the BB. In this example, we assume that
   van@lbl wants to talk to ddc@mit. The LBL-BB is sent a request from
   Van asking that premium service be assigned to a flow that is
   designated as having source address "V:4" and going to destination
   address "D:8". This flow should be configured for a rate of 128kb/sec
   and allocated from 1pm to 3pm. The request must be "signed" in a
   secure, verifiable manner. The request might be sent as data to the
   LBL-BB, an e-mail message to a network administrator, or in a phone
   call to a network administrator. The LBL-BB receives this message,
   verifies that there is 128kb/sec of unused Premium service for the
   domain from 1-3pm, then sends a message to Leaf1 that sets up an
   appropriate Profile Meter. The message to Leaf1 might be an RSVP
   message, or SNMP, or some proprietary method. All the domains passed
   must have sufficient reserve capacity to meet this request.



Nichols, et al.              Informational                     [Page 17]

RFC 2638      Two-bit Differentiated Services Architecture     July 1999


   Figure 6. Bandwidth Broker setting Profiles in leaf routers

   A statically configured example with BB messages exchanged: Next we
   present an example where all allocations are statically preallocated
   but BB messages are exchanged for greater flexibility. Figure 7 shows
   an end-to-end example for Marked traffic in a statically allocated
   internet. The numbers at the trust region boundaries indicate the
   total statically allocated Marked packet rates that will be accepted
   across those boundaries. For example, 100kbps of Marked traffic can
   be sent from LBL to ESNet; a Profile Meter at the ESNet egress
   boundary would have a token bucket set to rate 100kbps. (There MAY be
   a shaper set at LBL's egress to ensure that the Marked traffic
   conforms to the aggregate Profile.) The tables inside the transit
   network "bubbles" show their policy databases and reflect the values
   after the transaction is complete. In Figure 7, V wants to transmit a
   flow from LBL to D at MIT at 10 Kbps. As in figure 6, a request for
   this profile is made of LBL's BB. LBL's BB authenticates the request
   and checks to see if there is 10kbps left in its Marked allocation
   going in that direction. There is, so the LBL-BB passes a message to
   the ESNet-BB saying that it would like to use 10kbps of its Marked
   allocation for this flow. ESNet authenticates the message, checks its
   database and sees that it has a 10kbps Marked allocation to NEARNet