Jump to content

Bandwidth Broker: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
m Added further reading
re-arranged paras, added PDP and PEP
Line 1: Line 1:
RFC 2638 from the [[IETF]] defines the entity of the '''Bandwidth Broker''' (BB) in the framework of [[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 [[domain|domains]], the Bandwidth Broker managing a [[Domain name|domain]] will have to communicate with its adjacent [[peer-to-peer|peers]], which allows end-to-end services to be constructed out of purely bilateral agreements. DiffServ allows two carrier services apart from the default [[Best Effort]] service: Assured Forwarding (RFC 2597) and Expedited Forwarding (RFC 3246). Assured Forwarding (AF) provides a 'better than best effort' service, but is similar to best effort traffic in that bursts and [[jitter]] are to be expected. Expedited Forwarding (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 [[router|routers]], which together mean queues are kept small and there is no need for buffer management - resulting in low loss, low [[network delay|delay]] and low [[jitter]]. Hence although loosely a BB allocates bandwidth, really it allocates carrier services (i.e. QoS resources).
RFC 2638 from the [[IETF]] defines the entity of the '''Bandwidth Broker''' (BB) in the framework of [[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 [[domain|domains]], the Bandwidth Broker managing a [[Domain name|domain]] will have to communicate with its adjacent [[peer group|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 a 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 (RFC 2597) and Expedited Forwarding (RFC 3246). Assured Forwarding (AF) provides a 'better than best effort' service, but is similar to best effort traffic in that bursts and [[jitter]] are to be expected (out of profile packets are marked as best effort traffic). Expedited Forwarding (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 [[router|routers]], which together mean queues are kept small and there is no need for buffer management - resulting in low loss, low [[network delay|delay]] and low [[jitter]]. 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 [[router|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 leaf routers.


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 [[router|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.
[[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 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 a [[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.


A number of research projects have developed or are developing Bandwidth Broker architectures for [[DiffServ]] networks [http://www-staff.it.uts.edu.au/~simmonds/BB.htm].
A number of research projects have developed or are developing Bandwidth Broker architectures for [[DiffServ]] networks [http://www-staff.it.uts.edu.au/~simmonds/BB.htm].


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 a [[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.


==Further reading==
==Further reading==

Revision as of 17:54, 22 December 2007

RFC 2638 from the IETF defines the entity of the Bandwidth Broker (BB) in the framework of 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 a 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 (RFC 2597) and Expedited Forwarding (RFC 3246). Assured Forwarding (AF) provides a 'better than best effort' service, but is similar to best effort traffic in that bursts and jitter are to be expected (out of profile packets are marked as best effort traffic). Expedited Forwarding (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 mean queues are kept small and there is no need for buffer management - resulting in low loss, low delay and low jitter. 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 a 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.

A number of research projects have developed or are developing Bandwidth Broker architectures for DiffServ networks [1].


Further reading