1 / 17

Working Group on Ad-Hoc Networks

Working Group on Ad-Hoc Networks. Reliable Server Pooling for Ad-Hoc Networks M. Ümit Uyar, City College of CUNY Mariusz Fecko, Telcordia Technologies, Inc. Murray Hill, NJ February 5, 2003. Prepared through collaborative participation in the Communications and

balin
Télécharger la présentation

Working Group on Ad-Hoc Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Working Group on Ad-Hoc Networks Reliable Server Pooling for Ad-Hoc Networks M. Ümit Uyar, City College of CUNY Mariusz Fecko, Telcordia Technologies, Inc. Murray Hill, NJ February 5, 2003 Prepared through collaborative participation in the Communications and Networks Consortium sponsored by the U.S. Army Research Laboratory under the Collaborative Technology Alliance Program, Cooperative Agreement DAAD19-01-2-0011

  2. Reliable server pooling (RSP) pool elements (PEs) PE PE PE PE PE PE • Objective:Increase system availability by viewing a pool of redundant information sources as a single transport endpoint • Benefits: • clients can get service even if one or more servers fails • underutilized servers can provide relief to nearby overloaded servers • switchover when QoS drops; sustaining sessions through switchovers Client view: pool user (PU) (client) server pool ID: pool handle client’s RSP layer requests pool handle/pool elements mapping from its Home Name Server Actual system pool user (client)

  3. RSP architecture and protocol stack • Key components and issues • signaling protocols • server selection • transport and security state transfer (?) • load sharing and server fault management • transparent connection/session migration (?)

  4. RSP scope • Loosely-coupled, open architecture • high survivability: server pools may span several network domains • does not attempt to provide complete fault-tolerant computing • Defining properties • maps a single communication-destination name to multiple routable and reachable transport endpoints to increase the availability of distributed software-server entities registered under that name • reliability services, ranging from simple server selection to a fully automatic session-failover capability, can be designed and added using RSerPool as a distributed, open platform • Outside core scope, but work is ongoing • fully transparent session-failover capability • keeping data integrity among servers • data replication techniques in ad-hoc networks

  5. RSP in ad-hoc networks • IETF RSerPool WG is defining an architecture and protocols for RSP • Endpoint Name Resolution Protocol (ENRP) and Aggregate Server Access Protocol (ASAP) • management and maintenance of the entire (flat) server pool namespace provided by Name Servers (NSs) • lightweight, best-effort design • Is emerging IETF RSerPool applicable to ad-hoc networks? • IETF focuses on fixed, wired networks, and telephony applications • nodes are highly mobile, have limited processing power, are capable of rapid self-configurationandautoaddressing of nodes and interfaces • is best-effort, lightweight approach sufficient for server resources that are constrained and dynamic in MANETs? • mobility issues: network partitioning, local vs global name spaces, dynamic vs static home server • impact on lower layers (routing, MAC) needs to be considered

  6. Our approach • Evaluate IETF architecture and protocols through simulation • performance, scalability, resilience to stress conditions • Equip the architecture with mobility solutions • replace fixed elements with dynamic ones (e.g., home name server) • introduce local name spaces to tackle network partitioning • eliminate excessive signaling overhead by making the protocols mobility-aware • Introduce “enhanced” architecture • distributed server selection and session-admission control • membership of pools based on managing dynamic server resources • degree of readiness (DR): the number of associations that a server (from a pool) is willing to sustain at a certain level of QoS • server may belong to different server pools, which can be formed (or taken down or merge/split) dynamically, at varying DRs

  7. Simulation capabilities • Realistic evaluation must be performed in multi-layer wireless system • CCNY developed ns-2 simulation testbed that includes: • full implementation of IETF RSerPool protocols (ENRP + ASAP) • integration of MAODV for multicast • movement pattern selection (frequency, speed) • transmission pattern selection (antenna model, transmission range) • ongoing or planned • group mobility models (Reference Point Group Mobility, Mobility Vector) • integration with UD SCTP ns-2 model Wired/Wireless Scenarios Definition ENRP Agent ASAP Agent MAODV Routing Simplified SCTP RSP-aware CBR APP Deterministic/Statistical Error Model NS-2

  8. Results for the IETF RSerPool Successful transmissions among Name Servers Hunting for home name server Everything works fine for wired and stable networks; not so for mobile and dynamic ones Ratio of data packets to control messages

  9. Evaluation of IETF approach • Problems for wireless and mobile • namespace synchronization: name servers communicate successfully only 3-18% (90% for wired) due to network partitioning • huge signaling overhead: only 3-6 as many data packets as control messages (1,300 for wired) • hunting for home server accounts for 50% of control messages • exchange of info among NSs for 25% • false server deregistrations: temporary movement of operational server out of transmission range interpreted as failure • Alternative mechanisms designed and evaluated: • replace hunting for home name server with advertisements • overhead reduction ranges from 22% to 28% • make PE failure detection less aggressive (heartbeats, distinguishing between failed and temporarily out of range)

  10. Alternative mechanism: Server heartbeats (6) NS2 (PE2’s home) NS2 (PE2’s home) (3) (2) (5) PU1 (5) PU1 NS1 (PU1’s home) NS1 (PU1’s home) (1) (4) (2) (3) (1) (4) PE1 PE2 (7) PE1 PE2 (6) Pool Pool Original mechanism PE heartbeat mechanism 60-100% reduction in false server deregistrations

  11. Quantifying RSP benefits • Lost(a) vs (a,b)sustained sessions • Session Sustainability Gain (SSG): relative increase in the system's ability to admit and run a session until completion • SSG measurements for mobile networks: • assumption: at each switchover, we can migrate the session • "binary" sustained vs lost: 10-29% • "reclaimed" session lifetime: 23-42%

  12. Dynamic (re-)configuration • Management of pool resources based on • periodic exchanges of aggregated information and requirements of the pools • information about the network health from bandwidth brokers and mobility events from mobility agents • serverX advertises its capability set as <ST, SP, DR>, where ST is server type, SP is server priority, and DR is degree of readiness • Example • server X sends periodic advertisements {<SIP,1,1000><HTTP,2,500>} • DRSIP=1000 and DRHTTP=500 can change between advertisments, depending on changing server characteristics such as battery life, etc. • DRs are dynamically adjusted and used to perform admission control based on server resources • server resources (I.e., server membership in pools) readjusted dynamically to provide end-to-end quality for the service being requested by PU

  13. Server selection (distributed, QoS-based) • In resource-constrained environment, the best-effort policy to offer server pool resources may lead to • degradation of service to the already existing sessions • increase in the number of switchovers if individual servers become overloaded • impaired ability to perform successful switchovers or start new sessions if server pools become overloaded • best-effort policy (in other words, common sharing policy) results in a very high number of unsuccessful session attempts when the network resources are stressed [TON2001-Beard] • Four approaches to server selection are being investigated • pool guard channels • utility-based server-resources allocation • prioritized server-resources allocation • distributed fault localization techniques

  14. Example Network Router Name Server(Endpoint Name Resolution Protocol) R ENRP Pool Elements (each in different pools) Access Point AP PE PE PE PE PE PE PE PE Pool User (Host/Client) Hub PU hub R PE hub PE PU PE PU PU PU PU PU PE PU PU PE AP AP single node that is PE in two pools ENRP R R Backbone Network ENRP R ENRP R ENRP R AP PE MANET 1 MANET 2 MANET 3

  15. Experiment Scenario 1: PE movement PE PE PE PE ENRP R R R hub Backbone Network ENRP PE PU R ENRP PE R ENRP R PU PU PU PU PE PU PU PE PU PE PE AP AP RSerPool switchoverused for new sessions SCTP mobility used for in-progress session The PE for the “pink” pool moves from MANET 2 to 1 • PE is assigned a new IP address • PE must reregister with the ENRP server. • Sessions in progress at PUs rely on SCTP mobility to maintain session • PUs in pink pool may need to switchover to a new PE for new sessions AP MANET 1 MANET 2 MANET 3

  16. Experiment Scenario 2: PU movement PE PE PE PE PE PU PE PU PU PU PU PU PU PE PE AP AP A PU using both services moves from MANET 1 to 2 • PU is assigned a new IP address • Transactions in progress at PU rely on SCTP mobility to maintain session • PU may need to switchover to new PEs in green and pink pool,and may need to select a new primary ENRP server. ENRP R R R hub Backbone Network ENRP PE PU R ENRP R ENRP R AP MANET 3 MANET 1 MANET 2

  17. Exp Scenario 3: Failure of co-located Rtr/ENRP PE PE PE PE PE PU PE PU PU PU PU PU PE AP AP Router and ENRP server co-located on single asset Failure of that asset causes AP to failover to backup connection to router (e.g. on a lower bandwidth radio channel) PEs in MANET 1 must failover to backup ENRP server What is the effect on PUs, PEs in MANET 1? ENRP R R R hub Backbone Network ENRP PE PU R ENRP ENRP R R AP MANET 3 MANET 1 MANET 2

More Related