RFC 2638 from the IETF defines the entity of the Bandwidth Broker (BB) in the framework of differentiated services (DiffServ). According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an organization's priorities and policies and allocates quality of service (QoS) resources with respect to those policies. In order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth Broker managing a domain will have to communicate with its adjacent peers, which allows end-to-end services to be constructed out of purely bilateral agreements. Admission control is one of the main tasks that a Bandwidth Broker has to perform, in order to decide whether an incoming resource reservation request will be accepted or not. Most Bandwidth Brokers use simple admission control modules, although there are also proposals for more sophisticated admission control according to several metrics such as acceptance rate, network utilization, etc. The BB acts as a Policy Decision Point (PDP) in deciding whether to allow or reject a flow, whilst the edge routers acts as Policy Enforcement Points (PEPs) to police traffic (allowing and marking packets, or simply dropping them).

DiffServ allows two carrier services apart from the default best-effort service: Assured Forwarding (AF)[1] and Expedited Forwarding (EF).[2] AF provides a better-than-best-effort service, but is similar to best-effort traffic in that bursts and packet delay variation (PDV) are to be expected. Out of profile AF packets are given a lower priority by being marked as best effort traffic. EF provides a virtual wire service with traffic shaping to prevent bursts, strict admission control (out of profile packets are dropped) and a separate queue for EF traffic in the core routers, which together keep queues small and avoid the need for buffer management. The resulting EF service is low loss, low delay and low PDV. Hence although loosely a BB allocates bandwidth, really it allocates carrier services (i.e. QoS resources).

Bandwidth Brokers 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. Bandwidth Brokers 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 Bandwidth Broker architecture makes it possible to keep state on an administrative domain basis, rather than at every router, and the DiffServ architecture makes it possible to confine per flow state to just the edge or leaf routers.

The scope of BBs has expanded and they are now not restricted to DiffServ domains. As long as the underlying QoS mechanism can be mapped to DiffServ behaviour, then a BB can understand it and communicate with its adjacent peers, i.e. the 'lingua franca' of QoS in the Internet should be DiffServ. There may be more than one BB in a domain, though if there are, RFC 2638 envisages that only one BB will function as the top-level inter-domain BB.

  • Manages each cloud’s resources (Bandwidth Broker)
  • Packets are "coloured" to indicate forwarding "behavior"
  • Focus on aggregates and NOT on individual flows
  • Policing at network periphery to get services
  • Used together with Multiprotocol Label Switching (MPLS) and Traffic Engineering (TE)
  • "Aggregated" QoS guarantees only!
  • Poor on the guarantees for end-to-end applications

References

  1. ↑ Assured Forwarding PHB Group. June 1999. doi:10.17487/RFC2597. RFC 2597.
  2. ↑ An Expedited Forwarding PHB (Per-Hop Behavior). March 2002. doi:10.17487/RFC3246. RFC 3246.

Further reading

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.