Tài liệu Thực hiện chất lượng dịch vụ trong các mạng IP (P8) pptx

bandwidth brokers is implementing a transport transit service,which performs admission control in the access domain solelybased on inter-domain bandwidth availability information.. Using

net-Admission control or service quality instantiation control is notpart of the basic DiffServ framework [RFC2475] Subsequently,the need for IP service quality support mechanisms forDiffServ networks other than edge provisioning and per-hopprioritization mechanisms in core networks has been widelyacknowledged [RFC2638, Sch98, THD+ 99, TAP + 01, JC01, SAF +

01, TIPHON-3] The basic reason for the need of dynamic domain service quality control mechanism is the following: up to

per-a limit, service quper-ality for criticper-al service types cper-an be provided

by mapping them to a proper service quality support aggregatesuch as EF This works because of the prioritization mechanism ofDiffServ Alas, when there is too much traffic within the EF PSC,the flows sharing the PHB begin to suffer The effect of EF PHB

to other PSCs within the router can be controlled by using ratelimiters, but basic DiffServ framework does not provide tools for

Implementing Service Quality in IP Networks Vilho R¨ais¨anen

 2003 John Wiley & Sons, Ltd ISBN: 0-470-84793-X

dynamic control within the aggregate Similarly, the quality in AFPSCs suffers from too many service instances trying to share them.The end-user SLAs at the edge of the network are imposed bypolicing of traffic at the edge of the DiffServ domain As we saw

in Chapter 3, policing requires that adequate DiffServ classifier

be placed at the edge of the network With statically configuredDiffServ classifiers only, it is not possible to perform dynamicalresource control Basically, two techniques can be used to improve

on this:

• Admission control to existing classifiers In this case, the

classi-fier can be per endpoint IP address, per prefix, or per trafficaggregate This requires that there is an extra-DiffServ means ofblocking flows

• Installment of Diffserv classifiers on demand.

For the latter alternative, using of outsourced policy model is anenabling technology from the control architecture point of view[LV02] Obviously, in addition to the machinery to distribute theclassifiers, there has to be a policy existing as to when to limitservice quality instantiation and intelligence to create the actualDiffServ classifiers Per-domain Bandwidth Broker (BB) is a poten-tial tool for taking care of the former task, and for providing thedata for the second task Recent examples of application of band-width broker to manage the network resources in multi-service IPnetwork domain can be found in [Lak02] and [MNV02] In theformer, the emphasis is on the algorithms used for controllingresources, whereas in the latter, also an architecture for manage-ment is needed

Between the domains, being limited solely to static SLAs limitsthe level of efficiency of network use that can be reached This

is basically due to statistical multiplexing of flows in trafficaggregates If the SLA between two operator specifies that thedelays and packet losses have to be within certain range, it may

be beneficial for a transit network operator to make dimensioningbased slightly on conservative multiplexing calculation If theoperator could indicate to the business parties of momentarilyavailable extra capacity, this capacity could be utilized Thiscan be viewed as an enabling technology for the broker-type market models discussed shortly in Chapter 5 Anotherpotential use of automated inter-domain communication between

bandwidth brokers is implementing a transport transit service,which performs admission control in the access domain solelybased on inter-domain bandwidth availability information This

is one of the models discussed in end-to-end ETSI EP TIPHONservice quality support model [TIPHON-3], and has been analysed

in detail by Schel´en [Sch98] A bandwidth broker controlledDiffServ domain can also interface to a 3GPP domain with suitableinterworking arrangements, as discussed in [MNV02]

The basic DiffServ framework is based on the edge provisioningprinciple, where policing and marking of traffic at the networkedge are the determining components for per-flow quality sup-port Using bandwidth brokers, per-flow service quality in Diff-Serv can be made more closely integrated with the resource avail-ability situation in the network domains relevant for the transport

of individual service instances The means that can be used tomaintain up-to-date information about service quality support arediscussed in Section 8.2.2 Policy-based management is one way ofimplementing control of service quality instantiation, others beingdiscussed further below

On an architectural level, at least the following schemes are sible to implement end-to-end support for service quality whenmultiple transport domains (ADs) are involved:

pos-• One or more service providers take care of providing port resources for their own services, where transport resourcesmay be under control of separate transport operators The trans-port operators may obviously be used by other parties as well.The provision can be SLA-based This is one of the scenariosanalysed in the ETSI EP TIPHON QoS control reference model[TIPHON-3]

trans-• Separate per-element entities handle dynamic service quality trol based on transport service quality support resource availabil-ity This is the bandwidth broker model analysed in [RFC2638,Sch98, THD99], to name but a few sources

con-• Hybrid model In this approach, bandwidth brokers are used byproviding up-to-date service quality support resource availabil-ity information to service providers

The two first models are illustrated in Figure 8.1 and Figure 8.2.Note that in the first case, the correspondence between serviceproviders and transport domain does not need to be one-to-many

Transport domain 1

Transport domain 2 Service domain

Figure 8.1 An example of end-to-end provisioning on service layer Note: The media stream requiring service quality support is drawn in the thick line, signalling of end systems with service domain in the thin solid line, and interaction of service provider with transport domains in the dotted thin line

Transport domain 1

Transport domain 2

Regarding the two basic scenarios, the present chapter is ily concerned with service-independent resource management Aswas mentioned in the previous chapter, it is also possible to make alink between bandwidth broker-type entity and service admissioncontrol We shall discuss this topic further in Section 8.2.4

primar-Let us next have a look at existing studies on bandwidth kers, and then formulate a generic framework for application ofbandwidth broker in the context of multi-service DiffServ networkdomains The present chapter will be concluded with a summary

bro-8.1 PREVIOUS STUDIES

Other bandwidth broker architecture models have been studied inthe TEQUILA project [TAP+ 01], the AQUILA project [MNV02],

the GARA Application Programming Interface (API) model[SAF+ 01] and other sources [JC01], to give examples Thetechnology repertoire analysed in these studies includes SLSnegotiation, DiffServ, and MPLS For the purposes of the presentbook, we will concentrate on intra-domain and inter-domainresource management in DiffServ specifically MPLS is considered

to be a traffic engineering technique that is used by the policymanagement to optimize the resource usage within a networkdomain, and as such is not directly related to bandwidth brokers.The information supplied by the bandwidth broker, of course, can

be used by the policy management system as input in optimizingthe domain resources

In what follows, the IETF two-bit DiffServ architecture, theQBone bandwidth broker architecture, and Schel´en’s funnelconcept are discussed

8.1.1 Two-bit DiffServ architecture

The “two-bit” DiffServ architecture described in [RFC2638] hasbeen designed to support two service models, namely the “assuredservice” and “premium service” The two-bit architecture basicallyaccommodates both EF PHB and AF PHB groups within the sameDiffServ network domain The assured service, akin to the AFPHB group, provides statistical guarantees for in-profile traffic.The second service model, EF-like, is based on prioritization of

“premium” flows with respect to other traffic in the network Inaccord with the DiffServ framework, both service models make use

of traffic conditioning at the edge of the domain Thus, the twoservices are not in contrast with the AF and EF PHBs reviewed inearlier chapters

Implementing both services requires configuration of ate filters at the edge of the network to correspond to the requiredservices Referring to a case of a company with multiple users,the authors of [RFC2638] propose a bandwidth broker as an entityinto which organizational policies can be configured, and whichcan use these – together with the knowledge of existing connec-tions – to make classification decisions for service instantiations.The reference model is based on requesting the decision for newflows from the bandwidth broker

appropri-The function of a bandwidth broker – as defined in [RFC2638] – istwofold:

• Keep track of traffic allocations in the domain the resources

of which it is responsible for; and configure edge routers cordingly

ac-• Manage resource allocation messages sent to other domains.Related to the first of these tasks, a bandwidth broker is responsi-ble for receiving and authenticating resource allocation requests,each consisting of service type, target rate, maximum burst size,and of time period for the service For admitted requests, networkelements may need to be configured in the domain the bandwidthbroker is responsible for, or a bandwidth broker in another domainmay need to be contacted In [RFC2638], it is suggested that per-flow configurations in edge routers be of soft-state type – that

is, they need to be refreshed periodically in order to stay valid.The bandwidth broker concept of [RFC2638] has been used in theQBone bandwidth broker architecture, which is our next topic

8.1.2 Bandwidth broker in QBone architecture

The QBone architecture [THD99, QBA02], aimed at being a basisfor bringing service quality support to the Internet, has been dis-cussed several times in the previous chapters The architecture

is based on DiffServ, and subsequently the following goals andconstraints for intra- and inter inter-domain QBone resource man-agement solution have been put forth:

• Aggregation of flows into aggregates (basic DiffServ principle)

• The minimum requirement for interoperation between operators

is capability of making bilateral SLAs

• The flexibility for per-domain resource management should bemaximized

The target has been to make the inter-domain resource ment scheme of QBone consistent with the DiffServ approach TheQBone bandwidth broker, in general, can interface to differenttypes of network elements, including other bandwidth brokers,routers, application servers, end systems, and network operators[QBB02] The interfaces are illustrated in Figure 8.3

manage-The second boundary condition for the QBone inter-domain tion is the set of services provided The flagship service is the QBonePremium Service (QPS) An instantiation of QPS requires a number

Adjacent BB Adjacent BB

Data

NMS iface

PM iface

‘‘Simple’’

policy services

Figure 8.3 The interfaces and internal structure of a QBone bandwidth broker  Internet2 QBone

Source: From [QBB02]

of parameters to be specified between the service providers and thecustomers The parameters are:

• start and end times;

• source and destination;

In the QBone parlance, a bandwidth broker is a recommendedentity (“oracle”), responding to admission requests for network

resources in a QBone domain These requests, called ResourceAllocation Requests (RARs), may be made by an element fromthe domain under the control of the bandwidth broker in question,

or by a peer bandwidth broker The bandwidth broker responds

to RARs with a Resource Allocation Answer (RAA), constitutingeither a confirmation or denial of the request

Specifically, it is the task of a QBone bandwidth broker to makesure that the SLSs with peering QBone domains are fulfilled Track-ing the admitted connections and SLSs established with peeringdomains are identified as means of accomplishing this task Thepossibility of involving policy decision and enforcing points in theprocess is mentioned

An admitted service instance may lead to a need to reconfigurepolicing rules in boundary routers of neighbouring domains Anexample of allowing temporarily 10 Mbit/s of traffic instead of

1 Mbit/s is given Further, the possibility of making traffic ditioning dependent on routing is mentioned Presumably band-width broker is a seen of a technology enabler for dynamic polic-ing in this context

con-Three protocol interface classes are discussed:

• User/application protocol This interface carries the RAR and RAA

messages Requests can be performed by humans, or are carriedbetween automatic systems using a protocol such as RSVP

• Intra-domain protocol This is used for element configuration.

COPS, Diameter, SNMP, and vendor-proprietary interfaces arelisted as examples of protocols for this interface

• Inter-domain protocol Bandwidth broker peering makes use of

this interface

Relevant data interfaces include:

• Interface to routing tables The bandwidth broker needs to know

the up-to-date routing topology of the DiffServ domain to beable to handle resource management Routing may change forthe reasons discussed in Chapter 4 and Chapter 5

• Interface to data repository Data stored in the repository

include SLS information, reservations, router configurations,service/service quality support aggregate mappings, NMSinformation, monitoring information, and other policy interface

In the draft QBone bandwidth broker architecture outline [QBB02],two implementation phases of bandwidth broker have been

described: phase 0 and phase 1 These will be described inthe following.

8.1.2.1 Phase 0 bandwidth broker

End-to-end service level assurance in the architecture ing to Phase 0 is based on static SLSs between neighbouring QBonedomains A phase 0 bandwidth broker does not perform signalling

correspond-to peer brokers in other QBone domains Between the networkelements and the bandwidth brokers of the source and destina-tion domain, a protocol for performing RAR/RAA signalling isassumed This protocol can also be of non-automated form, forexample, a telephone call to a human responsible for resourceallocation of the domain

The end-to-end resource management is proposed to be handled

by a Bandwidth Czar, to which/whom traffic demand matrix iscommunicated by per-domain bandwidth brokers – by their oper-ating system running on carbon or silicon hardware The Czarmakes appropriate requests for resources in transit domains

At minimum, phase 0 bandwidth broker does not differ verymuch from “statically” provisioned network domain with SLAstowards the end users and peer domains Resource managementcan be taken care of with the basic assumption of static SLAs, andhandling momentary bandwidth needs as special requests.There may be a direct protocol such as RSVP used betweenthe communication endpoints, but it is not assumed to affect thetransit domain along the path of the service instance

8.1.2.2 Phase 1 bandwidth broker

Phase 1 bandwidth broker addresses two new questions: that

of automated communication between peer bandwidth brokers

on the one hand, and that of performing automated end-to-endreservation set-up The latter also includes the task of setting upadequate service quality support in access networks

In Phase 1, SLSs are assumed to be already established – wise – between DiffServ domains that are participating in thephase 1 bandwidth broker scheme Dynamic SLS negotiation wasdefined to be outside of the description of the functions of basicbandwidth broker Bandwidth brokers are assumed to be able to

pair-signal directly also to peer brokers in non-neighbouring domains.Further, globally known service types are assumed The mapping

of services to DSCP markings is defined separately for eachdomain DiffServ interworking on DSCP marking level is not part

of the QBone phase 1 scheme

Three different cases are analysed:

1 An end system requests service to a fully specified address

2 End system or bandwidth broker requests service to a tion prefix (domain)

3 Bandwidth broker receives a request for fully specified tion and uses an aggregate for satisfying the request

destina-In the first case, end-to-end signalling is implemented by wise exchange of messages between logically adjacent entities Theactions taken by the bandwidth broker in the originating, transit,and destination domains is analysed in the QBone bandwidth bro-ker document The full details are not reproduced here, and can

pair-be found in [QBB02]

The second case is essentially a request to establish a one-waytunnel between the originating and destination domains Such

an aggregate is called a core tunnel Tunnels can be requested

by end systems capable of aggregating their requests, or by abandwidth broker In both cases, intelligent aggregation policycan reduce resource reservation signalling considerably This kind

of aggregation is especially useful when there are many flows

to a non-adjacent domain By aggregating the flows in the sit domain, the need to perform per-flow resource reservation intransit domains is avoided (see Figure 8.4) Only the bandwidthbrokers at the end of the tunnels need to be concerned with theactual aggregation of flows The bandwidth brokers of the interme-diate transit domains only deal with aggregated service requests.The mechanism for triggering the establishment of a tunnel isexcluded from the discussion in the QBone document

tran-The third case is actually a special use case of scenario 2 Inthis case, the bandwidth broker handles a fully specified endpointrequest internally by performing admission control to an estab-lished core tunnel The difference between doing admission to coretunnel and to an inter-domain SLS is that core tunnels can be set upaccording to need The reason for a bandwidth broker setting up

Domain A Domain B Domain C

Domain D

Figure 8.4 The use of aggregated reservations

Note: Between domains A and D, there is a single flow Between A and

C, there are three flows which are aggregated into a joint reservation in domain B

a core tunnel could be simplification of reservation-related keeping both in the originating domain, and in transit domains

book-8.1.3 QoS Agents

A specific instantiation of bandwidth brokers called QoS agents

have been discussed in O Schel´en’s PhD thesis [Sch98] Schel´en’s

scheme uses marking of packets admitted by elements called QoS agents, but DiffServ as such is not required Ingress policing is part

of Schel´en’s reference model A QoS agent is aware of resourceavailability in the domain under its control, as well towards otherdomains For the domain under its own control, the QoS agent isaware of IP topology A QoS agent can also delegate requests toother QoS agents as necessary

A QoS agent learns the topology for its domain of control byquerying the routing table from the routers within that domain.The task is earlier when link-state routing protocols such as OSPFare in use, as querying a single router is then sufficient – naturallyassuming that the routing topology is in a stable state The QoSagent also learns the properties of individual links, such as band-widths, by querying routers [SP98] For example, a SNMP interfacecan be used for this purpose

End systems communicate with QoS agents, requesting eitheropen (undefined duration) or closed (starting and ending timedefined) resource reservations All requests include the bandwidthrequested, as well as source and destination address The requestscan be made in a scheduled or immediate manner Immediate

reservations correspond to the normal operation of cellularnetwork, for example, where resources are requested when theconnection is initiated Scheduled, or advance, reservations on theother hand, are akin to reserving Virtual Leased Lines (VLLs)for the communication, where a part of network resources inthe domains through which the service instance is routed, is putaside for communications between communicating parties (hosts

or network prefixes) Advance resource reservations in Schel´en’sthesis are more dynamic than leased lines, however, allowing forreservations to be requested – in advance – for a period of timedefined by starting and ending time

QoS agents can aggregate reservations between destinations tominimize signalling The destinations of the aggregations are net-work domains, each controlled by a QoS agent Aggregated reser-

vations between adjacent domains are called funnels in Schel´en’s

terminology An end-to-end capacity request consists of a series offunnels All traffic controlled by a QoS agent destined to the end-point of the reservation is routed to the funnel, irrespective of thetype of the traffic Admission control is necessary to ensure thatthe volume of traffic entering the funnel does not exceed its capac-ity The traffic from multiple “incoming” funnels can be mergedinto an outgoing funnel An example of end-to-end path consisting

of funnels is shown in Figure 8.5

Traffic is assumed to be policed at least in the ingress of the work domains Per-flow policing can be performed in the accessdomain, and egress policing, when used, can be based on networkdestination