Service Mapping Element

There are different ways on how to map the Intserv services to Diffserv services as described in [BeYa00], [WrCh00], [AlSi00]. The service mapping element will perform the mapping of Intserv

Wireless Internet QoS RSVP/Intserv – Diffserv Border Router to Diffserv services that was chosen by the designer of the RID router in accordance with the design objectives and requirements of the Intserv/Diffserv architectural framework. As described in Section 2.4.2 service mapping in [BeYa00] is still an open issue. The default mapping, which is mentioned in [BeYa00], is already explained in Section 2.4.2. [WrCh00] describes service mapping of Intserv into Diffserv services and gives a detail description on how the Intserv services can be implemented using Diffserv network behaviours and mechanisms.

In this thesis the service mapping element will perform the functions that will be implemented using the [WrCh00] as the main reference. Thus, the service mapping element will perform mapping of Intserv services to Diffserv services on the RSVP RESV packets that already passed the policy and admission control and accordingly set the appropriate PHB. The result of the service mapping will be sent further to the classifier. Eventually this RESV message will arrive at the appropriate host, if it is not refused upstream. The data packets transmitted arriving at the RID border router will be identified by the classifier and marked with the proper DSCP byte based on the info received from the service mapping element. Further data packets will be processed in a standard Diffserv manner.

The implementation proposal of [WrCh00] of Intserv services to Diffserv services is summarised in

Intserv Services Diffserv PHB AF PHB Controlled Load (CL)

EF PHB Guaranteed Services (GS) EF PHB

Table 4.2.2-1 Service mapping as proposed in [WeCh00]

4.2.2.1.1 Implementation of Controlled Load Service

As it is shown above, the [WrCh00] proposes implementation of Controlled Load service to AF PHB but also to EF PHB. In this thesis the service element of RID Border Router will perform mapping of CL to AF PHB, that will be explained in the following paragraphs. The mapping of CL to AF PHB is also recommended by [WrCh00] that is the mapping of CL to EF PHB should be used only if AF PHB is not available. However, in the Intserv/Diffserv architectural framework, the availability of AF PHB is not questionable, that is both AF PHB and EF PHB must be available at all times.

The Controlled Load (CL) Service traffic can be sorted out in delay classes based on the token rate b/r given in the CL TSpec parameters (see Section 2.2.2). Flows with a higher burstiness, that is larger token rate will experience more queuing delay that the flows belonging to the less bursty flows. So a reasonably effective CL implementation method will group the flows with roughly the same queuing delays into sub-classes, which will be handled independently [WrCh00]. The TSpecs of flows belonging to the same sub-class will be aggregated into a single TSpec, based on which this traffic will be policed and marked accordingly with the appropriate DSCP indicating the selected AF instance and highest priority forwarding within that instance. The non-conformant packets will be marked with a DSCP indicating the selected AF instance and lowest priority forwarding within that instance.

Wireless Internet QoS RSVP/Intserv – Diffserv Border Router This will be explained by the following example: for each AF class and highest priority instance there is a TSpec aggregate defined say Ta1, Ta2, Ta3, Ta4. In order to associate single TSpec flows with an aggregate flow b/r ratio is checked:

if b/r < 2 than Ta1 else

if b/r <4 than Ta2 else

if b/r < 6 than Ta3 else

if b/r < 8 than Ta4

where Ta1 = Σ Tai for all TSpec that have b/r <2. It is the same for Ta2, Ta3 and Ta4 also. Flows belonging to the Ta1 will be marked with AF1.1 DSCP byte. Similarly flows belonging to Ta2, Ta3, Ta4 will be marked with AF2.1, Af3.1 and AF4.1 DSCP byte.

The Diffserv network as stated in [WrCh00] should be configured such that for each AF instance:

the queue size is set accordingly to the queuing delay of the class’s target

the dropping parameters for low priorities are set such that these packets are dropped as soon as they are not fitting into the queue size set for their class

service rate is set to a bandwidth sufficient to meet the delay and the loss behaviour requirements of the CL spec when only high priority class packets are present

the admission control mechanism should ensure that at each hop in the network the level of traffic offered to each AF instance shouldn’t exceed the level of the one provisioned in the previous requirements.

The relationship between different AF instances, between AF PHB and best effort and between AF and EF PHB should be more tightly constrained than is required in the AF specification itself [RFC2597], because of the requirements of the service mapping functions, which need to be precisely defined in relation to TSpec token bucket rate.

4.2.2.1.2 Implementation of Guaranteed Service

As explained in Section 2.2.3 the Guaranteed Service (GS) offers strict delay bounds, assuming only that the network is functioning correctly. The delay values C (rate dependent delay - packet serialisation delay) and D (not-rate – dependent delay – propagation delay) are provided by the network element to the customer such that it can calculate the necessary bandwidth to achieve specific queuing delay target. There are two important issues needed to be considered when implementing the Guaranteed Service:

providing traffic scheduling, policing and shaping mechanisms needed to provide hard bounds on performance

determining the delay values such that the customer can accurately determine the network path and deduce what level of resources must be requested.

The EF PHB is appropriate for implementing Guaranteed Service, but than still there is a need to set shaping and policing mechanisms in order to get the necessary delay bounds. The delays in the Diffserv domain can be classified into propagation and serialisation delay, shaping/reshaping delays at the boundaries and queuing delay inside the domain. While in Intserv C and D values are local to a single network element, in Diffserv domain C and D can be defined as the delay values

Wireless Internet QoS RSVP/Intserv – Diffserv Border Router for the whole domain including all types of delays mentioned above C_dc and D_dc [WrCh00].

These delay values depend not only on the topology but also on the characteristics of all EF traffic in the Diffserv domain. This means that the knowledge about topology and traffic characterisation should be centralised. Also the knowledge about the dependence of the delay bounds on traffic characteristics implies the existence of a policy which defines the traffic characterisation rules and implementation mechanisms in all ingress network elements. All these considerations imply that the delay bounds should be performed as part of e.g. traffic management algorithms, based on knowledge of the topology, traffic patterns, shaping policies and other relevant mechanisms.

In the Intserv/Diffserv architectural framework these bounds can be set as part of SLS between the Intserv and Diffserv domain, such that the Diffserv domain provides the appropriate implementations of the C_dc and D_dc values within its domain. Assuming that these values are set and appropriately implemented as suggested in [WrCh00], the Service Mapping element will perform the mapping of the RSVP RESV messages of GS to EF PHB in a straightforward manner and accordingly inform the classifier.

Wireless Internet QoS RSVP Tunnel

[5 [ 5] ] R R S S V V P P T T U U N N N N E E L L

5.5.11 InIntrtrooduductctiioonn

Usually RSVP messages are sent through the network as raw IP packets with the protocol ID 46 and router alert option set to indicate to the routers that these messages require special processing. When the RSVP messages traverse non-RSVP cloud they are just ignored by the routers. In the same manner RSVP messages can also traverse the Differentiated Services domains region transparently, where the Diffserv routers will ignore them.

But, the Diffserv architecture may use RSVP as a signalling mechanism for its intra–domain resource provisioning, in which case RSVP messages coming from outside the Diffserv domain will not be carried transparently any more. Instead they will be processed by each RSVP aware router within the Differentiated Service architecture, which will introduce undesirable behaviour at the core routers in the Diffserv domain. There will be an interference of the intra-domain Diffserv RSVP signalling flows with Intserv RSVP signalling flows and also the processing of Intserv RSVP per flow at the Diffserv core routers will introduce the same scalability problems as in Intserv.

The Intserv/Diffserv architectural framework is designed such as to provide Diffserv transparency to RSVP messages coming from Intserv independently of what sort of mechanisms (dynamic or static) Diffserv uses for its resource provisioning. This transparency is provided by tunnelling RSVP messages in IP tunnels through Diffserv and can be used whenever it will be necessary, independently of static or dynamic provisioning of resources in Diffserv domains.

This chapter proposes a mechanism for setting of RSVP tunnels, which is motivated strongly by IP tunnels [RFC1853], [RFC2003]] simplicity and functionality and partially by [RFC2746].

However, it is in its own right entirely independent of them. It proposes a relatively simple way of tunnelling RSVP messages within a single domain or through multiple Diffserv domains.

Additionally in this chapter an example of this RSVP tunnel functionality is given. Other ways of providing Diffserv transparency to RSVP messages are also described.

5.5.22 DiDiffffsserervv TTrraannssppaarreennccy y ttoo RRSSVVPP

There are several mechanisms either designed or suitable for providing Diffserv transparency to RSVP, such that RSVP messages will be carried invisibly through the Diffserv domains. These mechanisms are explained in the following sections:

5

5..22..11 RSRSVVPP OOppeerraattiioonn wwiitthhiinn IIPP ttuunnnneellss

RSVP operation within IP tunnels, is a mechanism for reserving resources in IP tunnels, in order to extend RSVP usage to fixed and wireless networks [RFC2746]. It enhances IP tunnels with

Wireless Internet QoS RSVP Tunnel RSVP capability, such that the end-points of the tunnel send RSVP PATH/RESV messages respectively in order to reserve resources for to-end sessions within the tunnel. Also the end-points of the tunnel have to map the per-flow end-to-end sessions to the tunnel session.

This RSVP over IP tunnels can also be used in the Intserv/Diffserv architectural framework such that the RSVP/Intserv packets traverse the Diffserv domains until they reach their destination domain, that is their exit point of the tunnel. In this case the Edge Routers (ER) (see Figure 3.4-1) will be the end-points of the tunnel.

However, even though this mechanism has its advantages in providing RSVP signalling in IP tunnels, it does not fit well with the design requirements of the Intserv/Diffserv architectural framework. Because, the intention is to only use the IP tunnels as pipes for carrying RSVP messages and not having RSVP aware IP tunnels.

5.5.22..22 RSRSVVPP AAggggrreeggaattiioonn^**

The RSVP aggregation [BaIt00] concept is used to reduce the Intserv scalability problems by extending the RSVP protocol with facilities for aggregation of individual reserved sessions into a common class and across transit domains. It describes mechanisms for dynamic creation of the aggregate reservation, classification of the traffic for which the aggregate reservation applies, determination of the bandwidth needed to achieve the requirement and recovery of the bandwidth when the sub-reservations are no longer required. A RSVP aggregated session is identified by the IP destination address, the protocol ID and the DSCP information.

Furthermore, for classification and scheduling of traffic supported by aggregate reservations Diffserv mechanisms are used. Diffserv DSCPs are used to identify traffic covered by aggregate reservations and one or more Diffserv PHB’s are used to offer the required forwarding treatment to this traffic.

The first router in the transit domain that handles the aggregated reservations is called Aggregator, while the last router in the transit domain that handles the reservations is called Deaggregator. An RSVP aggregation region is consisted by routers that are capable of managing the RSVP aggregated states.

The RSVP aggregation concept can be used either when RSVP is applied end to end or edge to edge. In the later case the Aggregator can use a policy that can be based on local configurations and local QoS management architectures, to set the DSCP packets that are passing into the aggregated region. For example, the Aggregator may be a PSTN (Public Switched Telephone Network) gateway that aggregates a set of incoming calls and makes an aggregate reservation across one or more Diffserv domains up to the Deaggregator that can be e.g., another PSTN gateway. In this situation the call signalling is used to establish the E2E reservations.

In the following paragraph the RSVP aggregation concept is used when RSVP is applied end to end.

Each end point can initiate a per-flow and end to end RSVP resource reservation procedure. The per-flow RSVP resource reservation messages are referred as E2E PATH/RESV and the aggregated resource reservations messages are referred as aggregated PATH/RESV. The E2E PATH/RESV messages are carried though the RSVP aggregation region transparently, since their RSVP protocol Id at the aggregator will be replaced with a new protocol number, i.e., RSVP-E2E-Ignore that is expected to be standardised. Each E2E RSVP resource reservation

* Sections 5.2.2, 5.2.3 on RSVP aggregation and MPLS are also part of [KaRe00]

Wireless Internet QoS RSVP Tunnel request that arrive at the ingress router, i.e., Aggregator, of an RSVP aggregated region can initiate or resize a RSVP aggregated reservation. In the RSVP aggregated region the aggregated RSVP messages are managing the reservation of the resources for a set of per-flow RSVP reservations. The E2E RSVP reservation states are temporary states, i.e. soft states that have to be updated regularly. This means that E2E PATH and E2E RESV messages will have to be periodically retransmitted. If these states are not refreshed then they will be removed. These states may also be removed by using the E2E PATHTear and E2E RESVTear messages. When these E2E states are removed then their FLOWSPEC information must be removed from the allocated portion of the aggregate reservation, such that this same bandwidth will be re-used for other traffic in the near future. Furthermore, their SENDER_TSPEC information must also be removed from the aggregated state.

It is important to note that in [BaIt00] it is suggested that a predefined policy should exist to maintain the amount of bandwidth required on a given RSVP aggregated reservation that is taking into account the sum of its underlying E2E reservations, but that will protect it from changing it frequently. This can be achieved by using some level of trend analysis.

From the above information it can be deduced that based on a certain policy the Aggregator and Deaggregator will decide when the RSVP Aggregated states will be refreshed or updated and therefore this triggering time is not completely defined by the E2E RSVP messages.

Within an aggregation region three possible scenarios can be distinguished:

• Signalling Flow for the first E2E flow

• Signalling Flow for subsequent E2E Flow without reservation resizing

• Signalling Flow for subsequent E2E Flow with reservation resizing

The RSVP aggregation mechanism can be used in the Intserv/Diffserv architectural framework by using the E2E ignore for the RSVP messages, or in case of extension of the Intserv/Diffserv architectural framework to support dynamic SLAs it can be used as a single mechanism for inter-domain resource provisioning

5.5.22..33 MMPPLLSS aass mmeeaannss ooff RRSSVVPP ttuunnnneell sseettuupp

The MultiProtocol Label Switching (MPLS) [RoVi00] is specified by the IETF to mainly be used in combination with the Diffserv concept and is an advanced forwarding scheme that extends routing with respect to packet forwarding and path controlling (see also [XiHa00], [Will99]).

The packet forwarding is used to create topology driven paths through the network. Each MPLS packet has a header that can contain a label. An MPLS-capable router, called also Label Switching Router (LSR), accomplishes the forwarding of the packets that it receives by examining the label and possibly another field in the header, called experimental field. At the ingress of an MPLS-capable domain the IP packets are classified and routed based on a combination of the local routing information maintained by the LSRs and of the information carried on the IP header. At this point an MPLS header is inserted for each packet. Each LSR within the MPLS-capable domain will use the label as the index to look up the forwarding table of the LSR. By using the packet forwarding procedure Label Switch Paths (LSPs) are established between pairs of nodes in the network.

The path controlling can be achieved by using traffic engineering. In this case the LSP establishment, maintenance and release is strictly controlled and managed by using signalling.

Wireless Internet QoS RSVP Tunnel This signalling carries information related to the required characteristics for each LSP. Each node must ensure that these requirements are satisfied. An LSP can include the following requirement characteristics:

• Path Selection (based on QoS constraints);

• Delay and delay variation;

• Bandwidth, including sustained peak data rates and maximum burst sizes.

MPLS is a very promising traffic engineering mechanism and as such Diffserv can use it also for setting RSVP tunnels. But, a disadvantage is that MPLS can be used to set RSVP tunnels only locally to a single Diffserv domain, due to limitation of MPLS for usage in inter-domain environment. Actually, the MPLS can be used inter-domain also, depending on geographical scope defined, but it is unlikely that different network administrators of Diffserv domains would agree to share their facilities in such a way.

5.5.33 RSRSVVPP--iinn--IIPP TTuunnnneell

Tunnelling RSVP messages in IP tunnels through Diffserv domain enables RSVP support with traffic aggregation independently of the intra-domain signalling mechanism that Diffserv uses, what is also the design goal and requirement of the Intserv/Diffserv architectural framework.

RSVP-in-IP tunnel is to be used only for carrying RSVP messages and after the proper service mapping (Intserv/Diffserv) is set the Intserv data packets are going to be treated as part of Diffserv behaviour aggregate. The RSVP-in-IP tunnel is a unidirectional tunnel, where the bi-directional functionality between the same endpoints is enabled by two unibi-directional tunnels carrying traffic in the opposite directions. The endpoints of the RSVP-in-IP tunnel are either an ingress or egress of RSVP traffic, that is either an entry point or an exit point of the tunnel. The RSVP-in-IP tunnel acts as a best-effort link for RSVP messages transferred between the end

RSVP-in-IP tunnel is to be used only for carrying RSVP messages and after the proper service mapping (Intserv/Diffserv) is set the Intserv data packets are going to be treated as part of Diffserv behaviour aggregate. The RSVP-in-IP tunnel is a unidirectional tunnel, where the bi-directional functionality between the same endpoints is enabled by two unibi-directional tunnels carrying traffic in the opposite directions. The endpoints of the RSVP-in-IP tunnel are either an ingress or egress of RSVP traffic, that is either an entry point or an exit point of the tunnel. The RSVP-in-IP tunnel acts as a best-effort link for RSVP messages transferred between the end