An Architectural Framework for Ad-Hoc QoS Interconnectivity with ...

PYLON:1 An Architectural Framework for Ad-hoc QoS Interconnectivity with Access Domains Yasser L. Morgan School of Computer Science Carleton University Ottawa, Ont., Canada K1S 5B6 [email protected]

Abstract The unique nature of mobile ad-hoc networks (MANETs) imposes several challenges when providing QoS. Traffic traveling on a MANET can be local traffic arriving from and targeting a node within the ad-hoc network. Traffic that is not local to the MANET is likely to travel over fixed networks that employ DiffServ, IntServ, or a combination of both. This paper investigates the interaction and the relation between a MANET network and a hosting access domain that provide QoS support potentially based on two distinct paradigms (namely IntServ, and DiffServ). The objective is to achieve a high level of autonomy. In this paper we propose a framework solution to the inter-domain agreements and the use of aggregate RSVP for collective resource reservations.

Thomas Kunz Systems and Computer Engineering Carleton University Ottawa, Ont., Canada K1S 5B6 [email protected] The proposed framework provides a comprehensive solution from a high-level view. It is beyond the purpose of this paper to cover the details of the solution. Some of the scenarios are illustrated as an example, and to increase the clarity of the paper. The second section of this paper provides a review of related models, which is essential to define where the model fits. The third section presents the motivation of the research. In Section 4 we define some of the basic terms that are necessary for understanding the proposed model. In the fifth section, we illustrate the rational behind this specific framework, and its main components. The high-level view is then described. Section 6 describes the mechanism of how this framework and its main components interact together. The last section provides concluding remarks and outlines possible future research extending this model.

1. Introduction Most of the current ad-hoc wireless network QoS research is geared towards the investigation of QoS routing. Very little efforts, if any, have been put to the problem of interacting with a fixed infrastructure (like access networks). Only recently, Iera and Molinaro [5] published an article that discusses a similar problem for the interaction between a satellite IP-based network, and a terrestrial access network. In this paper, however, we introduce a framework based on the view of an ad-hoc network as a parasite network that needs to cling to a fixed access network in order to gain access to the Internet. The hosting access network is expected to provide the parasite network with suitable Service Level Agreement (SLA), Traffic Conditioning Agreement (TCA), and service provisioning policies. This framework uses aggregate RSVP signaling [2] to perform inter-domain resource reservation.

1

2. Review of related models In recent years, some research work has addressed the issue of QoS in MANET networks. Three models attempt to establish comprehensive solutions, namely INSIGNIA [6], and SWAN [1] from Columbia University, and FQMM [8]. The three models provide some good insights into the unique characteristics of the ad-hoc environment. FQMM follows a hybrid approach combining the perclass granularity of DiffServ with the per-flow granularity of IntServ. FQMM adopts DiffServ, but improves the perclass granularity to per-flow granularity for certain classes of traffic. Since the traffic load within MANET is much less compared to the backbone, the treatment of a small number of individual flows should not harm the performance [8]. FQMM falls short in addressing the full demands of scalability issues; instead, it reaches a

In ancient Egyptian and Greek languages, PYLON is the gate, the major entrance to temples, and the sky.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

compromise solution for small to medium size MANET networks (roughly less than 50 nodes). FQMM is built over IntServ, and DiffServ models, hence can operate directly with extranet traffic. One concern here is the DSCP (Differentiated Service Code Point) set that the ad-hoc domain should use to serve the DiffServ traffic. This is discussed in Section 4 of this study. The basic tenet of SWAN is to maintain a stateless model with no need to process complex signaling, or to keep per-flow information. Adhering to this tenet provided SWAN with scalability, and robustness. SWAN promotes a rate control system that can be used at each node to treat traffic either as real-time, or best-effort traffic. Excessive real-time traffic is automatically demoted to best effort. The problem of SWAN becomes how to calculate the “threshold rate”, limiting any excessive delays that might be experienced. SWAN adopts engineering techniques that attempt to set the admission threshold rate at mobile nodes to operate under the saturation level of the wireless channel [1]. While SWAN falls short in addressing specific QoS needs, like policy-driven QoS, the SWAN model is unique in its distributed stateless framework. While SWAN provides a model that deals with traffic on a per-class basis, it uses merely two levels of service, best effort and real-time traffic. Both levels can be simply mapped to certain DSCPs with known PHB (based on bandwidth requirement) in order to facilitate extranet QoS. Using this concept, SWAN is no different from DiffServ when discussing services provided by access domains. SWAN may decide to demote part of the realtime traffic to best effort services due to lack of resources. However, this traffic remains a real-time traffic, and still needs higher service level at the access network. INSIGNIA is a lightweight QoS model with per flow granularity and reasonable treatment for mobility. It uses bandwidth as the only QoS parameter, and allows local path redirection to recover from mobility situations [6]. INSIGNIA uses three levels of service: best effort, minimum, and maximum. All three levels can be simply mapped to certain DSCPs with known PHB (based on bandwidth requirement) in order to facilitate extranet QoS. Using this concept, INSIGNIA can be mapped to DiffServ when extending over access domain. Dynamic QoS adopts the notion of dynamic reservations in an effort to simplify the MANET QoS challenges. The dynamic nature of MANET creates situations when bandwidth is decreased. In such cases, the dynamic approach suggests to keep the percentage of bandwidth allocation rather than searching for new paths or giving up QoS and fall back to best effort. This approach suggests some enhancements to the RSVP protocol that lead to the creation of dRSVP [7].

Both SWAN and INSIGNIA are lacking the mechanism and the means to deal with extranet policy-driven QoS traffic. Both models use bandwidth only to handle QoS requirements. Ad-hoc domains that employ either model will have to map services to classical DiffServ with DSCP of known PHB (probably based on required bandwidth). Another way is to employ IntServ for specific classes of extranet QoS traffic. INSIGNIA, SWAN, and FQMM are the main candidates, so far, for providing a MANET QoS model. Each can provide the basics for a more comprehensive model, and they are likely to keep evolving. Other efforts like dRSVP cannot be viewed as a model, but as a technology that could be adopted by any model. The three MANET QoS models do not provide any means to identify the interaction between the fixed access networks and a MANET based network. The problem gets bigger realizing that available models can not be extended to the fixed network. For instance, running INSIGNIA on the ad-hoc side will provide QoS guarantees for ad-hoc local traffic only. The INSIGNIA model provides no means to set up QoS interaction with the access network. INSIGNIA and SWAN are intranet QoS models and provide services that have to be mapped to either per-flow or per-class services. Per-flow sessions rely (usually) on the RSVP protocol to reserve resources on every node end-to-end. The ad-hoc domain may follow a policy to convert an RSVP request to an aRSVP request to solve scalability issues as described in Section 6 of this study. However, the ad-hoc domain may choose to follow the policy of allowing per-flow extranet QoS. The use of per-flow QoS granularity raises scalability concerns in addition, to being vulnerable to node mobility. This limits the use of per-flow QoS to fewer situations, while expanding the role of per-class granularity. FQMM is already built over per-flow and per-class granularity, and is able to classify the traffic into either granularity. SWAN and INSIGNIA on the other hand may follow a simple mapping to a predefined DSCP set as discussed in Section 4.

3. Motivation Since real-time traffic is more likely to travel across MANET to the Internet, the need for a QoS interaction model between MANET and fixed access networks becomes crucial and essential. Figure 1 illustrates the situation when a MANET network needs to connect to the Internet via access networks as envisioned by IEEE 802.11 and Bluetooth in the particular case of “Personal Area Networks”. The example is provided to show how essential it is to provide a model for (MANET/FIXED ACCESS) interaction. One

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

of the important points in this example is the fact that the ad-hoc network has a number of ways to connect to the Internet, using different access technologies. Only [5] covered this problem of QoS interconnectivity, however, in [5] the interaction is considered only between a terrestrial and a satellite wireless network. Hence, the research leads to a more specific rather than a general solution. The objective of the framework in this paper is to come up with a solution that can operate with different QoS models employed on either ad-hoc or access networks.

• QoS requirements are very critical when traffic travels across domains. Signaling, authentication, budgeting, and accounting make the problem more demanding and need a thorough study. In addition, the ad-hoc non-local traffic is likely to be more demanding in terms of resources.

4. Basic definitions This section establishes some of the basic terms that are required for the discussion of this framework. MANET local IP subset (MLS): A subset of IP addresses that fall in the range (169.254/16 IPv4, or prefix MANET_INITIAL_PREFIX IPv6) as defined in [11]. anIP ∈ MLS iff (anIP ∈ {169.254/16, and IPv4}, or anIP has MANET_INITIAL_PREFIX and IPv6).

Figure 1: Sample MANET Access Network The lack of central authority, and human administration in ad-hoc networks imposes some challenges when dealing with per-class granularity. Much of the work of this paper is geared towards solving those problems. The framework discussed in this paper defines a solution for interaction between ad-hoc and access networks. By reusing available IETF protocols, like aggregate RSVP (aRSVP for short), this framework is not affected by the specific QoS models implemented on either side. Ad-hoc domain may choose to implement INSIGNIA, SWAN, or FQMM, while the fixed access network may choose to implement DiffServ or IntServ. Any combination will not affect the basic elements of the framework presented in this paper. In addition, this framework can operate over any MAC technology, IEEE 802.11, or Bluetooth, without any changes. The framework presented here is particularly important because: • Ad-hoc networks by nature can access the Internet only through access network. (Hence, we need QoS interaction model)

Alien IP subset: An IP address that does not fall within MLS. In this sense, if AAS is the set of all alien IP addresses, then: {All IP Addresses} ≡ AAS ∪ MLS anIP ∈ AAS iff anIP ∉ MLS. Thus, a global alien address (GAA) is an alien IP address for a node located outside the ad-hoc domain. Also a local alien address (LAA) is an alien IP address for a node located inside the ad-hoc domain. anIP ∈ GAA iff anIP ∈ AAS, and anIP is located OUTSIDE ad-hoc domain. iff anIP ∈ AAS, and anIP ∈ LAA anIP is located INSIDE ad-hoc domain. Ad-hoc Intranet Traffic: The traffic that is initiated by a node on an ad-hoc domain (LAA ∪ MLS), and targets a node that also resides on the same ad-hoc domain. The trip of data packets from source to destination does not go through any nodes outside the ad-hoc domain. INSIGNIA [6], SWAN [1], and FQMM [8] are QoS models for ad-hoc intranet traffic only. Ad-hoc Extranet Traffic: The traffic traveling through access networks as well as ad-hoc networks. The challenge of this type of traffic is that it has to deal with two different QoS models running on different types of network, yet provide a consistent view of the QoS. It is possible to distinguish between intranet and extranet traffic using the destination address and locally available routing information. Traffic with a GAA destination address is extranet traffic. Broadcast traffic that requires QoS (like in voice conferencing) is considered as ad-hoc extranet traffic if at least part of the traffic travels through both ad-hoc and access networks.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

The ad-hoc extranet traffic requires some cooperation between the ad-hoc and the access network in order to maintain QoS requirements. Access networks are, typically, fixed infrastructure networks that can provide ad-hoc networks with accessibility to the Internet. In this sense, and to stay consistent with the definition of MANET networks as described in RFC 2501 [4] the notion of a Parasite network is introduced. Ad-hoc networks exhibit their parasite nature in the way they cling to an access network, relying on the access network resources and services in order for the ad-hoc network to be able to access the outside world (Internet). The access (hosting) network may be willing to provide different levels of services as defined in [9].

that is willing to host an ad-hoc parasite domain formed in a meeting room, or a Hotel that is willing to host an adhoc meeting or a conference. A private friendly domain provides more services, and illustrates different levels of trust. This trust is achieved by exchanging security parameters, and services may be associated with differentiated costs. Services could be guaranteed for a specified time span. The parasite domain has to renew its service request before it expires. In addition, a parasite domain may require a promotion or demotion of services. The private friendly domain is committed to provide the same level of services during the lifetime of the request placed by the ad-hoc domain. Authentication Node / User (AN): Authentication Nodes are nodes on the ad-hoc side that have the authority to make resource reservations with a friendly domain. We will express this, as “Node N is an authentication node for domain D“. "AN" nodes in Figure 2 are AN’ and AN”.

In this study, we deal with Private Friendly Domains as defined in [9]. Private friendly domains are domains willing to provide different levels of services to any adhoc domain. An example could be a corporate network Global Network

Web Host

I" I'

GW

D"

GW

Friendly DS Domain DS'

D'

A"

GW GW

A'

Access Network

Access Network

The Internet Friendly DS Domain DS"

Parasite Domain

N2

N1 AN'

AN"

Ad-hoc Network

A Typical Ad-hoc Network connected to the Internet Through Friendly Access Domains

Figure 2: Network Elements Major Components: Friendly domains are expected to provide support for the MANET parasite domain by providing access to specific domain services, and agreements. Domain services are classically expressed in terms of three major components:

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

Service Level Agreement (SLA): Fixed networks define SLA as a contract between a customer and a service provider that specifies, in measurable terms, what services the network service provider will furnish. Individual users in the ad-hoc domain may decide to use any protocol such as SLP (Service

Location Protocol [10]) to locate specific services, such as a mail server, based on individual needs. Adhoc parasite domain users may also decide to form a group with common access to specific services such as printer or fax services. Traffic Conditioning Agreement (TCA): An agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding, and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within an SLA along with all of the rules implicit from the relevant service requirements and/or from a domain's service provisioning policy. An example of a TCA is the DSCP mapping, and packet fragmentation. Service Provisioning Policy: A policy that defines how traffic conditioners are configured on domain boundary nodes and how traffic streams are mapped to behavior aggregates to achieve a range of services. The above-mentioned three major components could be extended to cover more detailed components. Service Level Contracts (SLC) and Service Assurance Agents (SAA) are examples of more detailed components that can be driven from an SLA. In this paper we remain focused on the high-level architecture in order to provide a full view of the solution. The ad-hoc nature of the parasite domain leads to the absence of the three major components, which, in turn, imposes a challenge in locating the right set of parameters to operate the parasite domain. An ad-hoc parasite domain needs to adopt a set of DSCP codes in order to be able to deal with DiffServ QoS traffic. Many approaches could be followed to find the right set of DSCP values. We propose the use of a Native DSCP set. Native DSCP set: A native DSCP set is a highly detailed DSCP set adopted by an ad-hoc domain. When the ad-hoc domain clings to a friendly access domain that adopts a less detailed (smaller) set of DSCP codes, it is rather easy to do the mapping by combining slightly similar native DSCP codes into one access domain DSCP code, and use the same PHB. The reverse is rather challenging.

5. Design rational Our proposed architecture deals directly with extranet traffic; however, the design affects intranet traffic as well. The architecture covers the inter-domain relationship, which provides a vehicle for automatic configuration as

soon as the ad-hoc domain discovers a friendly domain in its neighborhood. Private Friendly Domains: The limitations of the handheld devices composing ad-hoc domains impose great challenges in storing and proposing the best network configuration tables (SLA, TCA, and service provisioning policies). On fixed networks, network administrators can enforce specific SLAs and TCAs that utilize the network resources to the limit, and satisfy service agreements with attached networks, and users. Engineering the network is done with the help of tools that monitor traffic patterns in order to provision the best service policies. SLAs and TCAs are (usually) managed by human intervention, and are based on “educated” human expectation of how the network could be engineered, and what services are feasible given the network resources. Ad-hoc networks, by definition, lack two essential ingredients: I. The lack of processing power and memory that could be employed to monitor, track, and store information about traffic patterns, and node mobility. II. The lack of human intervention that is needed to set up “educated” service-provisioning policies based on experience and “educated,” guesses. We view the ad-hoc domain as a parasite domain since it has to cling to an access domain that is able to provide the ad-hoc domain with accessibility to the Internet. In this sense, access domains should be able to perform operations necessary to suggest customized SLA, TCA, and service provisioning. Nodes forming an ad-hoc parasite domain will need only to co-operate in collecting data about traffic patterns, and node mobility. In many cases, ad-hoc nodes may be able to provide enough processing power and storage to run the network monitoring tools. In such cases one might argue that it is better to allow the ad-hoc parasite domain to develop and manage its own customized configuration tables. We argue that even in this case, the parasite domain will not be able to make the right decisions necessarily. Providing customized configuration tables requires using some history about similar ad-hoc domains. Access domains could be equipped to generate and maintain historical information better than ad-hoc domains. This point is better illustrated by an example. Suppose a network is formed in a hotel conference room, where the hotel provides the access network for the formed ad-hoc network. In such case, the access domain (hotel network) may be able to use its history about other ad-hoc domains that were formed more or less in the same geographical area. For instance, the access domain may be in a better

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

position to guess a future real-time streaming for a videoconference. On the other hand, individual ad-hoc nodes are more likely to have less history, and the history they might be able to accumulate are more related to other ad-hoc networks that were formed elsewhere (probably a personal area network as in Figure 1) and have less relevance to current ad-hoc traffic patterns. In addition, nodes forming the ad-hoc domain are likely to provide widely different history since they have potentially quite different experiences. Parasite domains are not obliged in any way to follow the friendly domain proposal. Technologies required to reach the best-customized configuration tables are best left for industry. Vendors may use different technologies for data collection. Artificial Intelligence, Neural Networks, or other technology may be employed to develop an “educated” guess of service provisioning. One advantage of this framework is accommodating innovative vendor solutions without introducing changes to the framework. Friendly domains are typically fixed structure domains with some wireless access points. They can be engineered with the situation of attached parasite networks in mind. Vendors can apply various techniques to provide more accurate service provisioning to the parasite domains. This raises the need for smart traffic provisioning tools that may use comprehensive historic data about other parasite domains, combined with some measures for the new parasite domain in order to provision adequate policies for the new domain. Since a parasite ad-hoc domain may cling to different friendly domains, it receives different proposals for SLA, TCA, and service provisioning policies. This is true in cases where the same access technology provides service in overlapping geographical regions and/or where different access technologies provide connectivity in the same location (see also Figure 1). Those proposals arrive, generally, at different points of time. The gateway (GW for short) to the proposing friendly domain can use SLA and TCA proposed by its friendly domain only. For instance, in Figure 2, GW (A’) adopts SLA, and TCA proposed by domain DS’, while GW (A”) adopts SLA and TCA proposed by domain DS”. The GW has to achieve a compromise between the costs of using different services. The decision could be constructed based on the service provisioning policies proposed by the friendly domain. When a GW looses link connectivity during a per-class session, extranet packets have to be rerouted to an alternate GW only if this alternate GW uses the same SLA, TCA, and service policies. Otherwise it will return to the originating node with a proper error code. GWs have to create a table of the “in-service DSCP”. This table provides a way of finding an alternate GW. This table can

be updated in either a proactive or reactive way. In this paper, we introduce the reactive approach. On the other hand, when a GW looses link connectivity during a per-flow session, extranet packets have to be returned to the sender with an error report. The originating node performs re-routing of packets, usually by re-negotiating a new connection. The GWs will adopt different SLA and service provisioning policies. Since the ad-hoc domain could have many GWs, traffic could be routed to different GWs. The routing algorithm should make the decision based on available unused resources, and the cost of use. This issue introduces a new challenge to the routing problem being discussed in the IETF MANET working group. Aggregate RSVP: Aggregate RSVP is used to solve the scalability issues of RSVP protocol. It is particularly efficient for inter-domain reservations. A typical situation that benefits from aggregate RSVP (aRSVP for short) is shown in Figure 2. A terminal network like ad-hoc networks (as shown on Figure 2) is a good candidate to employ aggregate RSVP. Since all ad-hoc extranet traffic have to pass through an access network, we can use aggregate RSVP to configure an aggregate PHB between nodes A’, A”, on one hand and D’, D” on the other hand. Assuming one aggregate is associated with one DSCP class. All end-to-end (E2E for short) reservations that use RSVP will use the same aggregate if they belong to the same class. In other words, all same class reservations will share resources reserved by a single aRSVP. This raises the problem of dealing with bursty traffic, since it will simply eat up the resources of other flows. [3] proved that the performance degradation due to bursty flows comes with performance enhancement in the form of reductions of delay in the tail of the delay distribution (e.g. 99% percentile delay) for the flows. Size of Aggregate Reservation: A range of options exists for determining the size of the aggregate reservation, presenting a tradeoff between simplicity and scalability. Simplistically, the size of the aggregate reservation needs to be greater than or equal to the sum of the bandwidth of all micro flows it aggregates, and its burst capacity must be greater than or equal to the sum of their burst capacities. However, if followed religiously, this leads us to change the bandwidth of the aggregate reservation each time a new micro flow is admitted or changed, which loses one of the key benefits of aggregation, the reduction of message processing cost in the aggregation region [2]. If the aggregator has a significant amount of bandwidth reserved but has very little probability of using it, the policy may be to release the excess [2] resources.

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

0-7695-1874-5/03 $17.00 © 2002 IEEE

It is essential in this framework to push the policy decision point, and policy enforcement point, to operate at GWs in order to decrease traffic signaling overheads. Hence, it is critical that "AN" and GW co-operate in policing the traffic reports provided by GW. GW should monitor the actual traffic utilization of the friendly domain, then forward it to AN. "AN" will collect the same information from all GWs that are maintaining a connection authenticated by itself. Then "AN" will accumulate the actual resource utilization, which could be used later for accounting purposes. Generating a smart policy to support the definition of the aggregate reservation size could be left for industry. Vendors may develop different technologies to provide such a smart policy. An advantage of this framework is the fact that it accommodates innovative vendor solutions without introducing changes to the framework. Removal of Aggregate Reservation: Following RFC 3175, [2, sec 2.9], aggregate reservation should be removed upon expiration. An aggregator may receive a periodical “refresh” message from the upstream node to assure the existence of an "AN" within the parasite network. Another policy could be to force the aggregator GW to solicit a periodic request for renewal from the AN, otherwise, GW will presume that the "AN" is dead. It is also possible to make the reservation for the lifetime of the GW. In all cases, policies should be stated in the service-provisioning database. Policies: Much of the policies mentioned so far are likely to require tradeoff analysis, and require more in depth study. However, the need for smart policy provisioning seems inevitable. Following are guidelines for generating ideal policies: • Since provisioning policies depend on the history of a specific network, and the history of its users, we propose that ad-hoc domains rely on its friendly access domain(s) to generate and keep the history of the parasite domain. We assume that the forming of the same ad-hoc network for a second time implies more or less having the same pattern of traffic. In other words, the history of ad-hoc domains is useful in forming policies for new similar ad-hoc domains. • While the first point remains generally a reasonable assumption, it follows that due to the ad-hoc nature, it is quite possible to have sufficiently wide variation of number of nodes forming the network, and/or having different number of points of attachments. Therefore, access networks should be able to follow (probably a machine learning) methodology to provide a provisioning policy based on “somehow” similar networks. Expected methodologies should be able to use relevant statistics to provide reasonably good

policies. In other words, history is not enough to generate new policies, and has to be supported by intelligence. • The objective is to have aggregate RSVP that runs these policies to achieve best performance, responding to changes in performance or demand by increasing or decreasing defined aggregate RSVP. However, this response should be required in terms of minutes. The services of the access network should always converge into a better performance. In other words, the dynamic nature of ad-hoc domain requires a periodic change in policies to react, and maintain service levels. Authentication Issues: The nature of the ad-hoc domains dictates the absence of a central authority. This leads to the absence of SLA, TCA, and service provisioning policy. Nodes in the ad-hoc domain that need to send or receive extranet traffic will run the risk of having access denial replies from the access network. Most ad-hoc domain nodes will require authentication before they can gain access to services on the friendly domain. This can clearly raise scalability issues. Using aRSVP may help solving this problem. Authenticating one aRSVP request means all nodes that require the use of the same DSCP traffic can take advantage of the already configured service. New requests for the same DSCP can be served immediately. In a reactive framework, requests for new DSCP services will need a new aRSVP request, which may be done by either soliciting a new aRSVP request from the same or different authentication node (AN). Optimizing which "AN" should request new services, upgrade, or downgrade services is a trade-off issue. Generally, the more ANs are involved in reserving newer DSCP services, the more robust an ad-hoc domain becomes. More "ANs" means less impact when one "AN" loses connectivity. However, the decision of which "AN" should be used to reserve new DSCP services should be based on a cost of service vs. level of service. Usually it is very difficult to define cost of service. Assume that in figure 2 AN’ can authenticate DSCP services of some level for a cost c1, and AN” can do the same for cost c2. Even if c1