Download PYLON: An Architectural Framework for Ad-Hoc QoS

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<c2, that does not say
anything about how willing AN’ is to pay c1 vs. the
willingness of AN” to pay c2. Hence, human intervention
should be allowed as well.
Assuming all costs are the same, one solution could be to
use a proactive approach by allowing the first (or best)
"AN" to place an aRSVP request to reserve all classes of
traffic (i.e. all DSCP). Then other users will use preconfigured services, and only solicit a request for upgrade
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
when needed. The problem with this approach is the
reservation of unused resources in anticipation of future
need. However, unused resources can be released until
needed. When needed, they can simply be activated.
Another solution we can envision is to follow a reactive
approach by reserving services only when needed. When
services for a new DSCP are needed, the GW will
broadcast a solicit message requiring all ANs to reply
with the level of service and the cost they can obtain from
a specific friendly domain. GW then will apply a selection
criteria to choose which "AN" should provide the aRSVP
connection. The reactive approach does not reserve
unused resources like the proactive one, however, a
certain delay is expected to find the right AN, and to
perform the actual aRSVP. The policy of defining
proactive versus reactive aRSVP reservation can be
determined from the service policy-provisioning
repository.
6. Mechanism
The model for QoS ad-hoc interaction with an access
domain is illustrated in Figure 3. The ad-hoc parasite
domain is represented by the left rectangle. The ad-hoc
domain may employ FQMM [8], SWAN [1], or
INSIGNIA [6], and may be using dRSVP [7]. Ad-hoc
domains will have a traffic-forwarding algorithm, which
will use the service policies in order to perform QoS
routing. SLA, TCA, and service provisioning policies, are
all imported components. The fact that they are displayed
within the ad-hoc domain does not necessarily mean they
exist within the domain, rather, it means the domain has
access to those components.
The friendly access domain is presented on the right side,
with its main components. GW has a common access to
the ad-hoc SLA, TCA, and service provisioning.
Figure 3 illustrates a general idea about the main
components of the proposed model. Each component
appears in a block, and components are either physical, or
logical. Lines between boxes represent a relation. Figure 3
is meant to be descriptive and illustrative. AN, and GW
are nodes that exist within the ad-hoc network; GW is a
node that exist on the access network as well. The rest of
the blocks are components that represent functionalities
that reside on either ad-hoc or access network. The
proposed mechanism for resource reservation could be
divided into two distinct operations: gateway discovery
and DSCP negotiation.
A. Gateway Discovery
1- GW
• Recognizes the existence of an ad-hoc domain.
• Verifies whether access domain requires
authentication (basic vs. private domain).
• Compiles a message containing (domain name, GW
address, authentication required). Broadcasts this
message to all ad-hoc nodes.
• Builds a table for “in-service” DSCP. The table
must include {DSCP, cost, etc}.
2- Ad-hoc Node
• Receives the GW announcement. Registers the GW
address with expiry time and metric. This metric
could be a hop count, a cost of reaching this GW,
or any other factor or combination of factors.
B. DSCP Negotiation
3- Ad-hoc Node
• Selects best GW to use for its extranet traffic. The
selection algorithm will simply use the metric
available, in addition to expiry time. The selection
could be biased towards the most recent GW, or to
rely more on the cost / hop count.
• If application decides to use IntServ, and full E2E
reservation, it can send the E2E reservation via the
selected GW. In this case reserving resources all
the way to the other end is the responsibility of the
ad-hoc source node.
• If application decides to use native DSCP, then it
needs to mark and submit the packets to the
network. Packets will reach the GW.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
FQMM
Imported TCA
TCA
Imported SLA
SLA
DiffServ
SWAN
IntServ
INSIGNIA
Authentic
Node
aRSVP
IntServ
DiffServ
Imported Policy Decision
Policy Decision
Resource Reservation &
Policy Enforcement (INSIGNIA, dRSVP)
Resource Reservation &
Policy Enforcement
Traffic Forwarding
Gateway
Ad-Hoc Network (Parasite Domain)
Traffic Forwarding
Access Network (Friendly Domain)
Figure 3: Architectural Elements
4- GW
• If a GW has lost its status as a gateway, return
packets to sender with error. In this case, sender
will update its gateway table, and re-route packets
to the next GW found in the gateway table.
• If DSCP is found in “in service” table, forward the
packets, else
• Broadcasts (or send to a specific node) a solicit
aRSVP request.
• Receives acknowledgement from AN, and starts
packet marking, and forwarding to access domain.
5- AN
• Conducts aRSVP negotiation with GW on behalf of
the network for the new DSCP.
• Acknowledges GW with the newly established
connection.
Handling of E2E RSVP and aRSVP messages: E2E
RSVP messages do not require any special handling. An
ad-hoc node will submit the message to the network;
routers will do the reservation and forward the message to
GW. The GW will then forward the message to the access
domain.
However, aRSVP messages require some work. "AN"
will submit an RSVP message to GW with protocol type
field set to RSVP-E2E-IGNORE (currently 134). GW
receives the message, switches the protocol type field to
RSVP and forwards the message to the access domain.
Session parameters such as DSCP, or PHB can be
forwarded using the session object as outlined in [2].
Policies provisioning bandwidth requirements are
employed at the aggregator (GW). This is very consistent
with our proposal for the parasite network view where the
access network takes over policy provisioning. Defining
the de-aggregation point is a decision that has to be
delegated to the access network since it is a part of its
engineering.
Security Issues: The triangular relation between AN, and
GW imposes some security issues. "AN" has to
authentication its aRSVP request to the GW. GW will
change message protocol type without changing the
message content. GW has to be able to validate the
aRSVP request and process it. This exchange of trust can
be secured by using valid key combinations, or digital
signatures.
7. Conclusions
This paper illustrated the high level view of a model for
QoS interaction between an ad-hoc parasite domain and a
friendly access domain. The model accommodates
different implementation models of QoS on either the adhoc domain or the friendly domain. The model as
presented is isolated from the specifics of the routing
algorithms, but assumes that routing algorithms for
MANET networks understand basic QoS. The main
contribution of this paper is the layout of the model itself;
the main advantage of this model is identifying areas
where researchers or vendors can make contributions
without affecting the overall view of the model. This
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE
paper identified areas that require more research.
Following is a summery of those areas:
1. Defining a methodology to calculate the aggregate size
of aRSVP reservation request.
2. Defining policies for removal of aggregate reservation.
3. Defining a secure relation between sending node, GW,
and "AN" while doing resource reservation.
4. Defining an algorithm that "AN" can use to co-operate
with GW in policing extranet traffic.
5. Establishing accounting policies for the charges
between ad-hoc nodes, and AN.
6. Establishing an IP addressing scheme for autoconfiguration of ad-hoc domains.
7. Defining a mechanism for mapping SWAN, and
INSIGNIA levels of services into native DSCP set
based on expected BHP.
8. Finding solution for the problem of selecting the
“best” GW to use for extranet traffic.
9. Defining a selection algorithm to detect “best” AN to
perform aRSVP on behalf of the ad-hoc domain.
10. Researching the trade off when using reactive resource
reservation compared to proactive resource
reservation.
11. Defining lightweight technology for collecting data
about node mobility, and traffic patterns. This
technology has to consider the privacy of the ad-hoc
domain.
12. Defining a way to create and maintain the history of
ad-hoc traffic patterns.
13. Defining a technology that uses traffic pattern history
to drive “educated” guesses for service provisioning.
This paper also defines some terms and components that
are believed to be necessary for identifying QoS
interoperability issues.
The model has to rely on negotiation between source
node, AN, and GW. This negotiation requires that routers
in the access domain understand the RSVP protocol, and
that "AN" and GW also understand RSVP. This
assumption seems reasonable. Within any network, if an
application is trying to set up a per-flow connection with a
node on the Internet, all nodes (up to the gateways)
between the user and the host have to understand RSVP.
This means that both AN and GW have to understand
RSVP.
Some might argue that due to the dynamic nature of
MANET, any node may adopt the role of AN, which
means that ideally, all ad-hoc nodes should be able to
understand RSVP. The answer here is simple, RSVP is
essential for per-flow granularity, hence, is likely to be
available on most (all) ad-hoc nodes. Even if "AN" cannot
find a path with RSVP aware routers to GW, the model
will switch to best effort. However, the likelihood of
having ad-hoc nodes that are not aware of RSVP is pretty
slim.
References:
[1] G. Ahn, A. T. Campbell, A. Veres, and L.-H. Sun, “SWAN:
Service Differentiation in Stateless Wireless Ad-hoc
Networks”, Proc. IEEE Infocom, pp. 457-466, June 2002.
[2] F. Baker, C. Iturralde, F. Le Faucheur, and B. Davie, IETF
RFC 3175 “Aggregation of RSVP for IPv4 and IPv6
Reservation”, September 2001.
[3] D. D. Clark, S. Shenker, and Lixia Zhang, "Supporting RealTime Applications in an Integrated Services Packet
Network: Architecture and Mechanism," in Annual
Technical Conference, Proc. SIGCOMM, pp. 14-26,
September 1992.
[4] S. Corson and J. Macker, IETF RFC 2501 “Mobile Ad-hoc
Networks: Routing Protocol Performance Issues and
Evaluation Considerations”, January 1999.
[5] A. Iera and A. Molinaro “Designing The Internetworking of
Terrestrial and Satellite IP-Based Networks”, IEEE
Communication Magazine, pp 136-144, February 2002.
[6] S. Lee, G. Ahn, X. Zhang, and A. T. Campbell, “INSIGNIA:
An IP-Based QoS framework for Mobile Ad-hoc Networks”,
Journal of Parallel & Distributed Computing, Vol. 60, No.
4, pp 374-406, April 2000.
[7] M. Mirhakkak, N. Schult, and D. Thomson, “Dynamic QoS
and Adoptive Applications for variable Bandwidth
Environment”,
MITRE-DoD
project
paper,
<http://www.mitre.org/support/papers/archive99_00.shtml>
April 2000.
[8] H. Xiao, W. K.G. Seah, A. Lo, and K. Chaing “Flexible QoS
Model for Mobile Ad-hoc Networks”, IEEE Vehicular
Technology Conference, Vol. 1, pp 445-449, Tokyo, Japan,
May 2000.
[9] Y. Morgan and T. Kunz, “An Architecture Framework for
MANET QoS Interaction with Access Domains”, to appear
in the Proceedings of the Workshop on Ad-Hoc Networks
and Wireless, Toronto, Canada, September 2002.
[10] E. Guttman, C. Perkins, J. Veizades, and M. Day, IETF
RFC 2608 “Service Location Protocol, Version 2", June
1999.
[11] C. Perkins, J. Malinen, R. Wakikawa, E. M. Belding-Royer,
and Y. Sun, “IP Address Autoconfiguration for Ad Hoc
Networks”, IETF draft, MANET working group,
URL:<http://moment.cs.ucsb.edu/publications.html>,
November 2001.
Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)
0-7695-1874-5/03 $17.00 © 2002 IEEE