Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Dynamic Network Reconfiguration Support for Mobile Computers

Dynamic Network Reconfiguration Support for Mobile Computers



|Views: 69|Likes:
Published by talhakamran2006

More info:

Published by: talhakamran2006 on Mar 15, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Dynamic Network Reconfiguration Support for Mobile Computers
Jon Inouye
Jim Binkley
Oregon Graduate Institute Portland State UniversityBeaverton, OregonPortland, Oregon
Jonathan Wdpole
Oregon Graduate InstituteBeaverton, OregonAbstractHot swapping
echnology combined with pervasive heterogeneousnetworks empowers mobile laptop users to select the best networkdevice for their current environment. Unfortunately, the majority ofsystemsoftwareremains‘%ustomized”foraparticularnehvorkcon-figuration, and assumes that many characteristics associated withthe network environment remain invariant over the runtime of thesoftware. Mobility causes changes in the environment and nulli-fies many of these assumptions. This leads to severeloss in systemfunctionality when resources are lost, and failure to benefit whenresources are gained.This paper describes Physical Media Independence (PMI), anarchitecture for dynamically diverse network interface manage-ment. PMI addresses three issuesconcemingdynamicnehvork con-figuration. First, a model for device availability is proposed to ac-curately determine when a network device is operational. Second,a structured methodology is used to construct adapters that recon-figure the system when the set of available devices change. Themethodology breaks traditional layering using a meta-interface topass events and information among layers, allowing each layer toadapt in a manner best suited to it. Third, we examine the effect oftransparent and non-transparent reconfiguration operations on a va-riety of applications. We find that adaptive, resource intensive ap-plications behave more efficiently when informed of device avail-ability events. We compare the functionality of an adaptive appli-cation running on top of a adaptive operating system (OS) with and
without cross-layer notifications.1 Introduction
Large variations in both hardware configurations and network en-vironments are made possible by advances in interface technologyand rapid deployment of network infrastructure. “Hot swappable”interfaces such as PCMCIA [18] and IEEE 1394 [30] provide userswith the ability to dynamically attach or remove devices while thesystem is running. There is no need, other than software limitations,to power cycle the machine, reboot the operating system, or restartapplications while reconfiguring the system.Unfortunately, the richness of the environment poses an inter-esting network management question: “How can a mobile host bereconfigured transparently as it migrates across different network
&mission to make digital/bard copies of all
part oftbis material forwonal or classroom use is granted without fee provided that the copiesore not made or distributed for profit or commercial advantage, the
right notice, the title of the publication and its date appear, and notice isgiven that copyright is by permission oftbe ACM, Inc. To copy otherwise,to republish, to
on servers or to redistribute to lists, requires specificpermission and/or fee
MOBXOM 97 Budapest Hungary
Copyright I997 AChl O-S979I-9SS-U97/9..S3.50
environments and uses heterogeneous network interfaces?” Dueto the static nature of their environment, desktop systems typicallyhard-code network configuration information in files. Extendingthis approach to mobile computers implies a configuration file for
every possiblecombinationof interfaces and environments.While this
approach may suffice for a limited number of well-known net-works, e.g., home
and office, the complexity grows with the num-
ber of environments. Emerging dynamic configuration technologyis helping to address this issue but, as will be shown, tends to focuson hosts equipped with a single network interface.The goal of Physical Media Independence is desktop
equivu-lencefor networkmanagement.
By desktop equivalence, we implythat a mobile computer should not be significantly harder to config-ure than a stationary computer. To achieve this goal, the networkconfiguration must adapt itself as active interfaces become disabledand new interfaces become available. The methodology we use isbased on the concepts of
explicit assumptions
intelligent adap-tation.. .
Once a deviceis available,we assume
that it continues to remain available, rather than running a se-ries of checks on the device before sending each packet to it.Explicitly checking for device availability is expensive, so in-stead, we make the optimistic assumption that the device willremain available, and move the checks from the frequentlyused packet-processingpath to morerural devicemanagementpaths that are traversed rarely. We call these checks
since they monitor the validity of our assumptions. We de-scribe a device availability model that defines the set of char-acteristics that identify an available device. Each characteris-tic is guarded by the addition of code to detect changes in thatcharacteristic.
Intelligent adaptation.
Guards trigger adaptation policieswhen they detect changes in the environmental features theymonitor. Ideally, adaptationis intelligent with adaptationpoli-ties in different layers cooperating toward a common goal.A particular layer should not try to perform all the necessaryadaptation by itself because it may duplicate or interfere withadaptations better performed by other layers.The remainder of this paper is organized as follows. Section 2presents our model supporting device availability. The model an-swers the question, “What devices are available?” Section 3 de-scribes our approach to intelligent adaptation and describes how thesystemreconfigures itself when the set of available devices changes.Section 4 describes our implementation of the system and Section 5presents an evaluation of the implementation. Section 6 describesthe effects of our adaptation approach on various types of applica-tion programs and Section 7 discusses the implications. Section 8follows with a description of related research, and we summarizeour experiences in Section 9.
Table 1: Device CharacteristicsTable 2: Internal Events Generated by External EventsNameDescription‘piNetNamed Network name is bound to deviceAffordable Cost of use is within budgetExternal EventsCard removedInternal eventsInvalidate name
connectivity, powerdown.Card attachedPower suspendPower resumeConnectivitv loss
2 Device Availability Model
We designatenetwork interface availability as the primary assump-tion in providing Physical Media Independence. Interfaces can be
to higher level protocols. When an inter-face is available, packets sent to it by the network layer arepassed tothe link layer where they are encapsulated into frames and sent outvia the physical network device. Frames received by the physicalnetwork device are passed by the device driver up to the networklayer. Packets do not flow between the network stack and the de-vice driver when the driver’s network interface is unavailable. Wedefine six characteristics that determine when an interface
avail-able. These characteristics are shown in Table 1. We concede thelikely existenceof other useful characteristics, such as security, butbelieve they can be integrated into our model without changing theoverall architecture.Connectivity gainName acquisitionName invalidationAffordablePower up, check connectivity, beginname acquisition.Invalidate name and connectivity.Check connectivity, begin nameacquisition.None.None.None.Begin name acquisition.Power up, check connectivity, beginname acquisition.UnaffordableInvalidate name and connectivity, powerdown.User disableUser enableInvalidate name and connectivity, power
ower up check connectivity beg nAn interface is presentif both the hardware device and the soft-ware driver exists. This characteristic addressesthe issues emergingwith hot swapping technology.An interface is connecredif there exists a connection at the linklayer.’ This characteristic addresses the variable connectivity ofwireless networks. Fluctuations caused by distance, interference,and obstructions may prevent a wireless interface from communi-cating with its base station. While connectivity is not a booleanvalue, our model requires a simple event to be raised to mark the de-vice unavailable or available. The policy behind the event notifica-tion may be multi-valued. For example, a simple empirically deter-mined threshold value for signal strength might be used, or a morecomplex feedback loop involving higher level protocols. Wired in-terfaces also require link connectivity checks due to cabling. Usersmay disconnect cables and leave PCMCIA network cards attachedto their computers while mobile becauseit is more convenientthanremoving and storing the card.interactive users who don’t realize how long they are “surfing” theWorld Wide Web or how much data they are transferring, this char-acteristic
targets virtually connected
systems. Virtual connectivityis support by PPP clients that automatically establish a point-to-point connection when a packet is sent to the interface, and “wake-on-ring” technology that resumes a suspended computer when anincoming call is detected. When virtual connectivity is used by
this characteristic provides a “cutoff’ switch
prevent unexpectedly large bills.An interface is
unless it is specifically disabled by auser-level directive. This provides users with the ability to over-ride the system and disable a device without having to remove ordisconnect it. UNIX systems have supported this characteristic as aflag within an interface’s data structure representation,An interface is
if the conjunction of all these charac-teristics is true (Equation 1). Oncewe determine whetherndcvicoisavailable or unavailable, we can configure the system based on theset of available devices. This configuration is valid until the mem-bership of the set changes.An interface is
network named
when there exists a binding toa network address. This characteristic has been required for sup-porting network (and higher) level protocols. We concentrate on IPnetworks, so we require an IP address assignment to satisfy this con-dition.
Available(l) k&d A Ipouted A
Iconnected A
Inetnomed A Ioj fordable A Ienabled
An interfaceispoweredif thenetworkdevicehasenoughpowerto function properly. The interface does not have to be poweredfor this characteristic to be true. For example, power conserving“sleep”mode may remove power from sections of a network devicewhile not in use, and restore power when those sections are needed.The
characteristic concentrates on situations such as sus-pend/resume operation, detecting a failing external battery, orinter-acting with operating system power management policies.An interface is
if the monetary cost of using thedevice is within the budget. Because wide-area wireless serviceshave limited bandwidth, providers tend to charge on a per-usage ba-sis. Examples include both circuit cellular (GSM, AMPS), whichcharges users per unit time, and packet cellular (CDPD), wherecharges are basedon the volume of data traffic.While beneficial for‘So a twisted air
Ethernet nterface card connected to an isolated hub would beconsidered“connected”.
Given all these characteristics, each network interface mny berepresented by a state machine. Each state represents a combina-tion of the truth values of the six characteristics. Different state ma-chines are possible by varying the policies driving state transitions.For example, in our state machine all LAN devices start out with
the enabled
characteristic while point-to-point interfnces start with-out it. A state machine is affected by both external events (user at-taching a network card) and internal events genemted in responsato the external events. Table 2 describes one possible set of internalstate transitions caused by external events. There are many trade-offs. For example, our state machine invalidates the network namecharacteristic when suspending, disabling, or removing n networkdevice. This forces name acquisition to be performed before the de-vice can be made available again. Optimistically, one could assumethe previous network name would be valid until proven otherwise,The goal is faster reconfiguration performance and if the assump-tion is correct most of the time, then performance will improve, Ifthe assumption is incorrect, the system must first detect it and then
* 0”. _ _2’_--A____!
recover. Another tradeoff is power consumption. A more power-conservative state machine might power down an interface and dis-able it upon losing link connectivity rather that to continue to powerit and hope connectivity will be restored soon. This would force theuser to enable the device (or reboot the system) before the devicecould be operational again.
2.1 Detecting Invalidations
We place
to detect the validation and invalidation of devicecharacteristics. These guards are placed in modules that monitorthe validity of the characteristic and are not present within the con-trol path used to send or receive packets. When triggered, guardsforce transitions in the state machine and may create a different setof available devices. In this section, we focus on the mechanismsneeded to monitor our device characteristics.
Guarding Present.
We depend on the existence of hot swap-ping support within the operating system, such as Windows Plug-and-Play [IO], or hardware interfaces, such as those provided pro-vided by PCMCIA[ 181.
Guarding Connected.
The most logical place to guard thisproperty is the device driver. More advanced driver interfaces arebeginning to support this type of functionality. For example, thewireless NDIS* extensions proposed by the Personal Computerand Communications Association (PCCA) allow network stacks toreceive indications when channel quality falls below a specifiedthreshold [23]. Unfortunately, most driver interfaces for wired de-vices do not export link-layer connectivity to the operating systemeven though the hardware supports it. The IEEE 802.3 IOBASE-T standard defines a twisted-pair Ethernet link integrity test butdoes not require all devices to implement it. Those that do have nostandard programming interface to communicate this informationto higher layers and usually end up logging warnings to the systemconsole.
Guarding NetNamed.
Network names are invalidated whenmigrating to a new network. There are many mechanisms for dis-covering this including receiving ICMP router advertisements [8],Mobile IP beacons [22], querying DHCP [9] servers, or receivinguser input. These guards will most likely live within network-layerentities and must propagate their events down to the device man-ager. From an opposite viewpoint, the device manager must be ableto upcall network-layer entities to acquire a network name.
Guarding Powered.
Poweris becominganincreasinglyimpor-tant resource. Weassumetheexistenceof some form ofpowerman-agement module that is responsible for allocating and deallocatingpower resources in a system. While APM [12] provides a few basicmechanisms for power management, it does not provide any powermanagement policies or ability to monitor the power usage of net-work devices. Second-generation system like the Advanced Con-figuration and Power Interface (ACPI) 3 are designed to give theoperating system more control over power management responsi-bilities.
Determining whether or not an interfaceis within a budget depends on knowing both the budget and the costof using the interface. Our architecture places the burden of pro-viding this information on the user or some other higher-level en-tity. The user is responsible for setting a strict budget for network
‘Ne~orkDriver InterfaceStandard-the driverinterfaceforMicrosoft Windows.3See http~/~.teleport.~~~a~~formoreinformationonACPI.
AdaptersIIExisting Network StackI
Application Layer
Notifications :
Transport Layernormaldata flowNetwork LayerIFigure 1: Layered Design wl Cross-Layer Notificationcommunication and binding a “cost model” to all interfaces charg-ing usage fees. Given these two pieces of information, the systemis responsible for monitoring the interface and disabling it when thebudget is exceeded.
User directives can be guarded by addinga check to the application programming interface (API) used to en-able or disable the device. Most operating systems provide such anAPI, and guarding it should only require the addition of an eventmechanism that triggers when the API is used to toggle this charac-teristic.
3 Intelligent Adaptation
We say a system adapts intelligently if it avoids conflicts and du-plication of effort between layers. This goal is accomplished bycommunicating assumptions and adaptation operations across layerboundaries. Figure 1 illustrates the application of this approach to atypicalTCP/IP network stack. Adaptation modules attached to eachlayer of the network stack receive policy-related information (meta-data) from higher layers and event indications from lower layers.We call
types of messages
Changes in device availability are associated with the link layer,but cross-layer notifications are used to propagate this informationto higher layers. In our model, a layer delays propagating deviceavailability indications to higher layers until its own internal adap-tation has completed. While this is helpful in avoiding synchroniza-tion problems, it increases the latency in propagating notifications.
3.1 Network-Layer Adaptation
The IP network layer creates two forms of bindings to interfaces:multicast groups and route table entries.4 IP multicast groups arebound to interfaces, allowing interfaces to participate in group man-agement (IGMP) communication between host interfaces and mul-ticast routers [7]. If an interface is removed, the system must de-cide what to do with the groups attached to that interface. Shouldgroup membership be revoked, or should they be migrated to an-other available interface? Revoking group memberships prevents
‘In 4ABSD ARF’ ntries are route table entries.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->