[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

INTERNET-DRAFT                G-S. Ahn, A. T. Cambell, S-B Lee, X. Zhang
                                                     Columbia University
                                                            October 1999

<draft-ietf-manet-insignia-01.txt>

Expires May 2000

                                INSIGNIA

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as ``work in progress.'' The list
   of current Internet-Drafts can be accessed at:
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:
   http://www.ietf.org/shadow.html. Distribution of this memo is
   unlimited.

Abstract

   This document specifies INSIGNIA, an in-band signaling system for
   supporting quality of service (QOS) in mobile ad hoc networks. The
   term `in-band signaling` refers to the fact that control information
   is carried along with data in IP packets. We argue that in-band
   signaling is more suitable than explicit out-of-band approaches
   (e.g., RSVP) when supporting end-to-end quality of service in highly
   dynamic environments such as mobile ad hoc networks where network
   topology, node connectivity and end-to-end quality of service are
   strongly time-varying. INSIGNIA is designed to support the delivery
   of adaptive real-time services and includes fast
   session/flow/microflow reservation, restoration and adaptation
   algorithms between source/destination pairs. In this memo we discuss
   how INSIGNIA fits into our broader vision of a wireless flow
   management model for mobile ad hoc networks and how it interfaces to
   the proposed MANET Working Group routing algorithm.











Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 1]


INTERNET-DRAFT                  INSIGNIA                    October 1999


Table of Contents

   0.  WHAT'S CHANGED ..............................................  2

   1.  INTRODUCTION ................................................  3
       1.1  TERMINOLOGY ............................................  4
       1.2  ASSUMPTIONS ............................................  6

   2.  A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING  6
       2.1  PACKET FORWARDING MODULE ...............................  7
       2.2  ROUTING MODULE .........................................  7
       2.3  INSIGNIA MODULE ........................................  7
       2.4  ADMISSION CONTROL MODULE ...............................  7
       2.5  PACKET SCHEDULING MODULE ...............................  8
       2.6  MEDIUM ACCESS CONTROLLER MODULE ........................  8

   3.  INSIGNIA PROTOCOL ...........................................  8
       3.1  INSIGNIA IP OPTIONS ....................................  8
       3.2  RESERVATION MODE .......................................  9
       3.3  SERVICE TYPE ........................................... 10
       3.4  PAYLOAD INDICATOR ...................................... 10
       3.5  BANDWIDTH INDICATOR .................................... 10
       3.6  BANDWIDTH REQUEST ...................................... 11

   4.  INSIGNIA OPERATIONS ......................................... 11
       4.1  FLOW SETUP ............................................. 12
       4.2  QOS REPORTING .......................................... 13
       4.3  SOFT-STATE MANAGEMENT .................................. 14
       4.4  FLOW RESTROATION ....................................... 15
       4.5  ADAPTATION ............................................. 16

   5.  SECURITY ISSUES ............................................. 20

   6.  APPLICATION ................................................. 20

   7.  ACKNOWLEDGMENT .............................................. 20

   8.  REFERENCE ................................................... 20

   9.  AUTHOR'S ADDRESSES .......................................... 22




0. WHAT'S CHANGED

   This memo has minor modifications from the previous draft, the
   operation of protocol remains the same. For full detail on the
   evaluation of INSIGNIA see [26].








Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 2]


INTERNET-DRAFT                  INSIGNIA                    October 1999


1. INTRODUCTION

   The introduction of real-time audio, video and data services into
   mobile ad hoc networks presents number of technical barriers that are
   due to the time-varying nature of the network topology, node
   connectivity and end-to-end quality of service (QOS). In such
   networks, mobile nodes function as hosts and routers. As hosts they
   represent source and destination nodes in the network while as
   routers they represent intermediate nodes between a source and
   destination providing store-and-forward services to neighboring
   nodes. The wireless topology that interconnects mobile hosts/routers
   can change rapidly in unpredictable ways or remain relatively static
   over long periods of time. Another technical issue that needs to be
   addressed is associated with the wireless link level performance.
   Mobile ad hoc networks are bandwidth constrained and time-varying due
   to radio link characteristics and impairments.

   The end-to-end communications abstraction between two communicating
   mobile hosts can be viewed as a complex channel. Due to node mobility
   and wireless link impairments, user-to-user sessions may need to be
   rerouted in the network while preserving the session connectivity and
   quality. Network algorithms need to be strongly adaptive and
   responsive to the time-varying and location dependent topological
   changes, resource availability, quality of service degradation and
   session connectivity.

   In order to provide adaptive quality of service support for real-time
   service in mobile ad hoc networks, 'flow-states' (i.e., reservation
   states at nodes associated with flows or microflows) need to be
   managed. A flow needs to be established, restored, adapted and
   removed over the course of a user-to-user session in response to
   time-varying topology, connectivity and end-to-end quality of service
   conditions.

   Since wireless and computational resources are limited in mobile ad
   hoc networks, any signaling overhead needed for wireless flow
   management must be kept to a bare minimum. Future signaling systems
   should be capable of restoring reservations and associated flow-
   states along a new path in response to topological changes with
   minimum noticeable degradation at the user session level.

   This memo provides an overview of wireless flow management model that
   supports the delivery of adaptive real-time services in dynamic
   mobile ad hoc networks. A key component of wireless flow management
   is INSIGNIA, an in-band signaling system that supports fast flow
   reservation, restoration and adaptation algorithms that are
   specifically designed to deliver adaptive real-time services in
   mobile ad hoc networking environments. INSIGNIA is designed to be
   lightweight and highly responsive to changes in network topology,
   node connectivity and end-to-end quality of service conditions. For
   full detail on the evaluation of INSIGNIA, see [26].






Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 3]


INTERNET-DRAFT                  INSIGNIA                    October 1999


1.1 TERMINOLOGY

     Mobile Ad Hoc Networks:
         Represent autonomous distributed systems that comprise a
         number of mobile nodes connected by wireless links forming
         arbitrary time-varying wireless network topologies [20].

      Adaptive real-time flows:
         This type of flow represents delay sensitive traffic,
         e.g., voice and video which can sustain some loss. Real time
         data flows are assumed to be somewhat loss tolerant and delay
         sensitive. These types of flows typically require flow setup
         procedures, resource reservation provided by INSIGNIA.

      Microflows:
         Micro flows represent short-lived flows, e.g. web style
         client/server interactions that comprises a limited train of
         data packets. These types of flows may require resource
         assurances in the network and, therefore, typically require
         some form of in-band support for fast resource allocation. We
         use the terms session/flow and microflow interchangeably.
         INSIGNIA has been designed to transparently support the
         requirements of both flowsand microflows in mobile ad hoc
         networks.

      Flow Setup:
         A Source initiates a flow set up by transmitting a request
         packet with its minimum and maximum bandwidth requirements.
         Intermediate mobiles receiving request packets, processes the
         requests and forward them to the next appropriate mobile host.
         A flow setup is complete when a source receives a QOS report
         from its peer destination.

      Restoration:
         When a reserved flow is rerouted and its associated states
         (e.g., reservation) are successfully created along the new
         route. Three types of restoration (viz. `max to max`,
         `max to min` and `min to max`) may be observed along the new
         path.

      Enhancement Layer (EL) Degradation:
         When a reserved flow is rerouted and its EL restoration fails,
         then a flow/sessions enhancement layer packets are degraded
         to best effort service. In a such case, only base layer (BL)
         packets are forwarded/received as reserved packets.

      Flow Degradation:
         When a reserved flow is rerouted and both EL and BL restoration
         fails. No resource allocation or associated states are created
         and all packets are treated as best effort after re-routing.

      Adaptation:
         When EL degradation persists for an unacceptable period, a
         destination mobile notifies its source to drop the EL packets



Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 4]


INTERNET-DRAFT                  INSIGNIA                    October 1999


         at the source host (scaling down). The destination can also
         initiates an EL resource recovery (scaling up) procedure when a
         monitored flow state at the destination indicate that
         sufficient resources exist along the path to support a better
         quality level.

      Adaptation Policy:
         Describes the bandwidth adaptation characteristics of a flow
         and the actions to be taken based on the observed network
         conditions experienced by a flow and its ability to adapt to
         those conditions. The decision to trigger adaptation mechanisms
         (i.e., scaling flows up/down)is based on application-specific
         adaptation policy.

      Adaptation Handler:
         A module that stores the adaptation policy that interacts with
         flow monitoring and QOS report modules.

      Monitoring Module:
         A module that keeps track of the incoming INSIGNIA flow state.
         Typically the packet type, resource availability and QOS
         are periodically monitored.

      QOS reports:
         These are periodic messages that are generated by destinations
         to inform peer sources of reception state/status of adaptive
         real-time flows. The periodicity depends on the sensitivity of
         a flow. Best effort flows do not, typically, generate QOS
         reports.

      Soft-state management:
         Each mobile host creates, stores and updates the state
         information for each adaptive real-time flow and its
         reservation status. This state information requires subsequent
         packets to refresh the flow state otherwise the flow state is
         considered old and automatically removed after a soft-state
         interval.

      Soft-state timer:
         The soft-state timer value defines the holding time for real-
         time reservation state for adaptive real-time flows/flows. If
         the mobile soft-state is not refreshed within the soft-state
         timer interval then the state is automatically removed. (Note
         that the treatment of flows and microflows may differ in terms
         of the setting of this state variable. Typically, flows would
         call for extremely fast reservation and release that may be
         more aggressive than the dynamics and timescales associated
         with longer lived flows. This issue is under experimentation
         and for further study.)








Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 5]


INTERNET-DRAFT                  INSIGNIA                    October 1999


1.2 ASSUMPTIONS

      INSIGNIA assumes that link status sensing and access schemes are
      provided by lower layer entities/protocols.


2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING

      The goal of wireless flow management is to support the delivery of
      adaptive real-time services in mobile ad hoc hosts under time-
      varying conditions. An adaptive service model allows packet audio,
      video and real-time data applications to specify their maximum and
      minimum bandwidth needs. INSIGNIA plays a central role in the
      resources allocation and management between source and destination
      mobiles. Based on availability of end-to-end resources, wireless
      flow management attempts to provide assurances for the minimum or
      maximum bandwidth needs depending of resource availability. In
      addition to supporting adaptive real-time services the service
      model also supports IP best-effort packet delivery.


                     adaptive mobile
                       applications
                            ^
       +--------------------------------------------------------------+
       |                    |                                         |
       |  +---------------+ | +-----------------+     +-----------+   |
       |  | MANET routing | | |    INSIGNIA     |<--->| admission |   |
       |  |   protocol    | | |                 |     | control   |   |
       |  +---------------+ | +-----------------+     +-----------+   |
       |      |    \        |   |      |       |            |         |
       |      |     \       |   |      |    control         |         |
       |  ---------  \      |   |  ---------   |        ---------     |
       |   routing    \     |   |   mobile     |         channel      |
       |    table      \    |   |  soft-state  |          state       |
       |  ---------     \   |   |  ---------   |        ---------     |
       |          \      \  | signal /  \      | packet  /   \        |
       |           \      \ v  -ing /    \     | drop   /     \       |
       |            \ +------------+       +-----------+       \      |
       |   +-----+   \|  packet    |       |  packet   |     +-----+  |
       ===>| MAC |===>| forwarding |======>| scheduling|====>| MAC |===>
       |   +-----+    +------------+       +-----------+     +-----+  |
       |IP packet in              data packets           IP packet out|
       +--------------------------------------------------------------+

        Figure 1. Wireless Flow Management Model at a Mobile Host/Router


   Realizing wireless flow management in mobile ad hoc networks presents
   a number of technical challenges. First, flows and microflows should
   be rapidly established without the penalty of a round trip delay and
   with minimal overhead due to signaling. Second, active flows should
   be maintained and restored in case of routing changes or link
   failure. Wireless flow management should be capable of rapidly



Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 6]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   responding to dynamic topology changes by adapting and re-
   establishing affected flows with minimal service disruption. Third,
   flow-state set up during flow establishment should be automatically
   removed when an application session terminates. Flow-state should
   also be automatically removed at routers no longer on the new path
   after re-routing has occurred due to topological changes.  The main
   modules of  the wireless flow management model are illustrated in
   Figure 1).

2.1 PACKET FORWARDING MODULE

   The packet forwarding module [15] classifies incoming packets and
   forwards them to the appropriate module (viz. MANET routing,
   INSIGNIA, local applications, wireless packet scheduling modules).
   Signaling messages are processed by INSIGNIA and data packets
   delivered locally or forwarded to the packet scheduling module.

2.2 ROUTING MODULE

   The routing module dynamically tracks changes in ad hoc network
   topology making the routing table visible (via APIs) to all
   intermediate packet forwarding module (e.g., INSIGNIA, packet
   forwarding). Wireless flow management assumes the availability of
   MANET routing protocol [2] (e.g. Temporally Ordered Routing Algorithm
   (TORA) [1], Dynamic Source Routing [7], Zone Routing Protocol [5], Ad
   Hoc On demand Distance Vector Routing Protocol [6]).

2.3 INSIGNIA MODULE

   The INSIGNIA module establishes, restores, adapts and tears down
   real-time flows. Flow restoration algorithms respond to dynamic route
   changes due to mobility. Adaptation algorithms respond to changes in
   available bandwidth. Based on an in-band signaling approach that
   explicitly carries control information in the IP packet header, flows
   can be rapidly established, restored, adapted and released in
   response wireless impairments and topology changes. Because of this
   dynamic environment, network state management is based on soft-state
   [3], which is well suited to managing reservation flow-state in
   mobile ad hoc networks.

2.4 ADMISSION CONTROL MODULE

   The admission control module is responsible for allocating bandwidth
   to flows based on the maximum/minimum bandwidth requested. Once
   resources have been allocated they are periodically refreshed by a
   mobile soft-state mechanism through the reception of data packets.
   Admission control testing is based on the measured channel
   capacity/utilization and requested bandwidth. To keep the protocol
   simple and lightweight, new reservation requests do not affect
   existing flow reservations. Rerouted or new flows may be degraded
   ifresources are unavailable.






Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 7]


INTERNET-DRAFT                  INSIGNIA                    October 1999


2.5 PACKET SCHEDULING MODULE

   The packet scheduling module responds to location dependent channel
   conditions experienced in wireless networks [22]. The scheduling
   mechanism is implementation and QOS model dependent. Currently, we
   have implemented a simple Weighted Round-Robin (WRR) service
   discipline which takes location dependent channel conditions into
   account. It should be noted that a wide variety of scheduling
   disciplines can be used to realize the packet scheduling module.

2.6 MEDIUM ACCESS CONTROLLER MODULE

   The medium access controller module (possibly) provides quality of
   service driven access to the shared wireless media for adaptive
   real-time services and best-effort services. The wireless flow
   management is designed to be transparent to any underlying media
   access control protocols. However, the performance of the MANET is
   strongly coupled to the provisioning of QOS support at the MAC layer.
   Nevertheless, our approach is to investigate the performance of
   INSIGNIA using both non QOS-capable and QOS-capable MACs.


3. INSIGNIA PROTOCOL

   Mobile ad hoc signaling systems should be lightweight in terms of the
   amount of bandwidth they consume and be capable of reacting to fast
   network dynamics close to call/session and packet transmission time
   scales. Future signaling systems should be highly responsive to flow
   re-routing and be capable of re-establishing active reservations
   along the new path with minimum disruption to on-going services.

   In-band signaling systems are capable of operating close to packet
   transmission time scales and are therefore well suited toward
   managing fast time-scale dynamics found in mobile ad hoc
   environments. In contrast, out-of-band signaling systems (e.g.
   Internet's RSVP, ATM's UNI, etc.) are incapable of responding to such
   fast time-scale dynamics. Based on an in-band approach, INSIGNIA is
   designed to restore 'flow-state' (i.e., a reservation) in response to
   topology changes within the interval of two consecutive IP packets
   under ideal conditions.

3.1 IP OPTIONS

   To establish an adaptive real-time flows, INSIGNIA uses a new IP
   option to setup, restore and adapt resources between source-
   destination pairs. When intermediate nodes receive packets with the
   these IP options set they attempt to reserve, restore or adapt
   resources forwarding date packets toward the destination.

   By coding control information in the INSIGNIA IP option (in each IP
   header), we support the notion of in-band control which we believe is
   called for to support QOS in ad-hoc mobile networks. The INSIGNIA IP
   option supports flow reservation, restoration and adaptation control.
   Best effort and adaptive real-time services are supported by INSIGNIA



Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 8]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   and are indicated by the reservation mode and service type fields in
   the IP options as illustrated in Figure 2. Flows are represented as
   having a discrete base layer (BL) with a minimum bandwidth and an
   enhancement layer, which requires the maximum bandwidth. This
   characterization is commonly used for multi-resolution traffic (e.g.,
   MPEG audio and video) and more generally for real-time data that has
   discrete max-min requirements.

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version| IHL |Type of Service|        Total Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Identification        |Flags|     Fragment Offset       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Time to Live  |   Protocol  |        Header Checksum          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Source Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Destination Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Options (Used for INSIGNIA IP Options)    |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         Figure 2a.  IP Header



     reservation   payload                bandwidth request
     mode          indicator
         0      1     2      3    4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-------+-----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |REQ/RES|AS/BE|BL/EL|max/min| max_bandwidth | min_bandwidth |
     +-------+-----+-----+-------+---------------+---------------+
             service     bandwidth
             type        indicator
     |<----->|<--->|<--->|<----->|<----------------------------->|
      1 bit  1 bit 1 bit  1 bit              16 bits

                      Figure 2b. INSIGNIA IP Options


3.2 RERSERVATION MODE

   To establish an adaptive real-time flow, a source node sets the
   request (REQ) bit in the IP option of a data packet to initiate a
   reservation request. On reception of a REQ packet, the intermediate
   nodes execute admission control and accept or deny the request. If
   the request is accepted, resources are committed and subsequent
   packets are scheduled accordingly. Otherwise, packets are treated as
   best effort packets if resources are unavailable.

   Packets that are received by nodes with their reservation mode set to
   reserved (RES) indicate that the session has previously passed
   admission control and resources have been reserved. In the case where
   a RES packet is received and no resources have been allocated the



Ahn, Campbell, Lee, Zhang       Expires May 2000                [Page 9]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   admission controller immediately attempts to make a reservation. This
   condition commonly occurs when reserved flows are rerouted during the
   lifetime of an active session due to mobility of sources,
   intermediate router nodes or destinations.

3.3 SERVICE TYPE

   The interpretation of the service type, which indicates either a
   adaptice service (AS) or best-effort (BE) packet, is dependent on the
   reservation mode. A packet with the reservation mode set to REQ and
   service type to AS is attempting to setup a real-time flow with the
   bandwidth requirements of the flow specified in the bandwidth request
   field. A packet with RES/AS set indicates that an end-to-end
   reservation has previously been established. A RES/AS packet service
   may be degraded to RES/BE service if the flow is rerouted along a new
   path when insufficient resources were available on the new path.

   A best effort packet sets the reservation mode to REQ as default and
   the service type to BE requiring no resource reservation to be made
   in the network. Reception of a RES/BE by a destination node indicates
   an active adaptive real-time flow was degraded to BE due to
   insufficient resource availability after rerouting to a new path.

3.4 PAYLOAD INDICATOR

   The payload field indicates the type of packet being transported.
   INSIGNIA supports two types of payload, i.e., base (BL) and
   enhancement layers (EL). The semantics of the adaptive real-time
   services are related to the payload type and resource availability.
   Base and enhancement layers can be assured via distributed end-to-end
   admission control and resource reservation. Maximum bandwidth
   reservation is required to support both base and enhancement layers
   of a flow whereas only minimum bandwidth reservation is required to
   support the base layer. When a flow with minimum reservation receives
   a EL packet in reserved mode (RES/AS) set, it indicates either the
   reservations for EL has been restored at the bottleneck node or an
   adaptation (scale-up) has been occurred.

3.5 BANDWIDTH INDICATOR

   The bandwidth indicator represents the potential resource
   availability for a flow/session along its current path between a
   source and destination pair. In this respect the bandwidth indicator
   represents the prospective resource availability to an application
   which will change over time. This does not, however, represent an
   actual resource reservation but the potential for one to succeed give
   the current indication. The bandwidth indicator is carried in each
   packet and can be therefore viewed as a dynamic state variable that
   can be updated by any mobile host on the current path. Based on its
   value it represents a good bandwidth hint that resources are
   available along the current path to meet the flows minimum or maximum
   needs. In this capacity the bandwidth indicator plays an important
   role during the flow setup phase and, more importantly, during the
   adaptation phase.



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 10]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   During flow setup the bandwidth indicator represents the resource
   availability along the chosen setup route. Reception of setup request
   packets with the bandwidth indicator bit set to MAX indicates that
   all nodes en-route have sufficient resources to support the maximum
   bandwidth requested. In contrast, a packet with the bandwidth
   indicator set to MIN implies that at least one of the intermediate
   nodes (known as the bottlenecked mobile host) between the source and
   destination has insufficient bandwidth resources to meet the maximum
   needs (if specified); however, reception of a packet with the
   bandwidth indicator set to MIN does indicate that all nodes can
   support the minimum bandwidth requirement. In this case, only the
   base layer reservation is  acknowledged as having been successful
   established via QOS reporting (see Section 4.2). QOS reporting
   between the destination and source can be used to force the source to
   'drop' enhancement layers. In this case the source would only forward
   the BL packets toward the destination in reserved mode. Any
   enhancement layer packets would be forwarded as best-effort packets.
   This action has the benefit of releasing an 'partial reservations'
   for the enhancement layer that may exist between a bottlenecked
   mobile host and the destination. We will discuss the issue of
   'partial reservations' (which may occur in all phases of INSIGNIA
   operation)in the sections of flow setup, restoration and adaptation.


   The bandwidth indicator is also utilized for restoring the
   reservation for EL if previously degraded to best effort service. In
   order to accomplish scaling up adaptation, the adaptation handler
   resident at destination should monitors a flow's resource
   availability (by monitoring the bandwidth indicator) and, based on
   the adaptation policy, initiate a 'scale up' operation using a QOS
   report.

3.6 BANDWIDTH REQUEST

   The bandwidth request allows a source to specify its maximum (MAX)
   and minimum (MIN) bandwidth requirements for adaptive real-time
   service support. This assumes that the source has selected the AS
   service type. A source may also simply specify a minimum or a maximum
   bandwidth requirement. For adaptive real-time services the base layer
   is supported by the MIN bandwidth whereas the MAX bandwidth supports
   the delivery of the base and enhancement layers between a source and
   destination pair.


4. INSIGNIA OPERATIONS

   The IP option and operations support the delivery of adaptive real-
   time services to mobile hosts. These operations collectively define
   the foundation of the INSIGNIA system and include flow setup, flow
   restoration, soft-state management, adaptation and QOS reporting.

   Once a flow has been established between a source-destination pair,
   QOS reports are used to inform the source of the progress of the
   delivered packet quality at the destination. Node mobility may



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 11]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   trigger topology changes. In this case the MANET routing protocol may
   provide alternative or new path information to  destination, in which
   case, INSIGNIA would attempt to restore reservations at all nodes on
   the new path through the restoration operation. Moreover, adaptation
   may be triggered to adjust a flow to match resources availability
   found on the new path. Managing the network state,while responding to
   these network dynamics, is handleby a soft-state management mechanism
   in INSIGNIA. In the following sections,each of the INSIGNIA
   operations are outlined.

4.1 FLOW SETUP

   To establish adaptive real-time flows, source nodes set the
   appropriate fields in the IP option before forwarding 'reservation
   request' packets toward destination mobile hosts. A reservation
   request packet is characterized as having its reservation mode set to
   REQ, service type set to AS, a valid payload (viz. BL or EL) and a
   MAX/MIN bandwidth requirement.

   Reservation packets traverse intermediate nodes executing admission
   control modules, allocating resources and establishing flow-state at
   all nodes between source-destination pairs. If any intermediate
   mobile node lacks resources to support the requested flow setup, the
   appropriate IP option field is changed to indicate this condition (or
   state).


         0   1     2      3    4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
       +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |REQ| AS |BL/EL|max/min| max_bandwidth | min_bandwidth |
       +---+----+-----+-------+---------------+---------------+

      Figure 3. INSIGNIA Packet Requesting MAX/MIN reservation


   If an intermediate mobile receives a request packet and can only
   support the minimum requirement then the flow request is degraded to
   the minimum request at the bottleneck mobile node by resetting the
   bandwidth indicator to MIN. Meanwhile the source continues to send
   reservation requests packets until the destination informs it of the
   status of flow establishment phase via QOS report (discussed in
   Section 4.2). Subsequent reservation request packets do not execute
   admission control but simply refresh existing soft-state reservation.

   The establishment of an adaptive real-time flow is illustrated in
   Figure 4. A source mobile host (M1) issues a flow setup by requesting
   resource reservation. M2 performs admission control upon reception of
   the request packet. Resources are allocated if available and the
   request packet is forwarded to the next mobile (M3). This process is
   repeated hop by hop until the request packet reaches the destination
   mobile host (M6). The destination mobile node determines the resource
   allocation status by checking the service type and current level of
   service.




Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 12]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   When a reservation request is received at the destination node, the
   INSIGNIA module checks the reservation status. The status of the flow
   setup is determined by inspecting the bandwidth indication field. If
   the bandwidth indicator is set to MAX then this implies that all
   mobile hosts between the source destination have successfully
   allocated resources to meet the base and enhancement layers bandwidth
   requirements. On the other hand, a bandwidth indication set to MIN
   indicates that only the base layer can be currently supported. In
   this case, all reserved packets with a payload of EL received at the
   destination have their service level flipped from AS to BE by the
   bottleneck node. In such case, a partial reservation may exist
   between the source and bottleneck mobile node. This partial
   reservation can be viewed as a waste of resources between the source
   and bottlenecked node (since they go unused) or, as a 'near
   reservation' where all but the remaining nodes (between the
   bottlenecked node and the destination) hold reservations. Holding on
   to these reservations - in effect locking them in - is a 'hedge'
   against completing  the setup phase in the near future. The treatment
   of 'partial reservations' is still under consideration. Currently,
   the adaptation process allows the mobile host to clear partial
   reservations using the adaptation process or leave them in place.


                            +----+   +----+
               QOS_REPORT(2)| M9 |---| M8 |\QOS_REPORT(2)
                    +----+ /+----+   +----+ \ +----+
                    | M2 |/          /       \| M7 |\QOS_REPORT(2)
             REQ(1)/+----+\         /         +----+ \+----+
            +----+/        \ +----+/  +----+          | M6 |
            | M1 |    REQ(1)\| M3 |---| M4 |REQ(1)   /+----+
            +----+           +----+   +----+\ +----+/
                                REQ(1)       \| M5 | REQ(1)
                                              +----+
            Figure 4. INSIGNIA Request Packet and QOS report


4.2 QOS REPORTING

   QOS reports are used to inform the source of the status of received adaptive
   real-time flows. Destination nodes actively monitor on-going flows inspecting
   status information (e.g., bandwidth indication) and calculating QOS statistics
   (viz. packet loss, delay, out-of-sequence delivery and throughput). QOS
   reports are periodically sent to source host for the purpose of completing
   flow establishment and managing adaptations. QOS reporting is application
   dependent where the periodicity of reports is determined by the application's
   sensitivity to the delivered QOS.  Note that QOS reports do not have to travel
   on the reverse path toward the source. Typically they will take an alternate
   route through the ad hoc network as illustrated in Figure 4.

   In the case of flow establishment, reception of a reservation request packet
   with the bandwidth indicator set to MAX (or MIN) indicates that the source's
   maximum (minimum) reservation has been successfully made en-route. The
   destination informs the source of this reservation status by setting the
   bandwidth indicator field with MAX (MIN) in the QOS report, accordingly. The



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 13]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   QOS report is a best effort data packet with a payload that comprises of a
   adaptation commands and measured QOS information.

   QOS reports are also used as part of on-going adaptation process that responds
   to mobility and resources changes in the mobile ad hoc network. Periodic QOS
   reports can be used to inform the source to 'drop' (e.g., drop all EL packets)
   or 'scale-up' (i.e., transmit EL packets) based on available resources and the
   adaptation policy of the application. These are the 'adaptation commands'.

4.2.1 QOS REPORT INTERVAL

   Since each flow has different sensitivity to QOS, the periodicity of QOS
   report for each flow should reflect this sensitivity. A flow that is sensitive
   to service quality requires more frequent QOS report than one that is less
   sensitive (i.e., more QOS control). A source relates the sensitivity of a flow
   via setting the TTL value with relatively small value. The destination
   utilizes the TTL value, requested bandwidth and the adaptation policy to
   determine the flow's sensitivity to service quality. We are currently
   investigating the migration of this function to the INSIGNIA IP options field.

4.2.2 QOS PACKET FORMAT

   The role of the QOS report is to serve as a simple notification of the
   satisfaction level perceived by the destination. The QOS report includes a
   QOS. In fact, the QOS report of INSIGNIA has the same format as a best effort
   INSIGNIA data packet. A QOS report has the reservation mode set to RES and
   service type set to BE. The minimum bandwidth field is set to zeros and
   maximum bandwidth is set to ones. By doing so, the QOS report can be
   distinguished from the degraded RES packet. The various packet formats are
   illustrated in Figure 8.

4.2.3 QOS REPORT DELIVERY

   QOS reports should be delivered in a timely fashion. We propose to schedule
   QOS reports before the transmission of best effort packets but without
   affecting the performance of reserved flows. The IP option codepoint for QOS
   reports, even though  best effort in service type, set it a side from all
   other best effort traffic for a  'better than best effort treatment' at
   intermediate nodes.

4.3 SOFT-STATE MANAGEMENT

   Maintaining the quality of service of real time flows in mobile ad hoc network
   is one of the most challenging aspects that INSIGNIA addresses. Typically,
   wireline networks requires little QOS or state management where the routes and
   the reservations remain fixed for the duration of the session/flows. This
   style of 'hard-state' connection oriented communications guarantees quality of
   service for the duration of the holding time. However, these techniques are
   not applicable/valid in mobile ad hoc networks where paths and reservations
   need to dynamically respond to topology changes in a timely manner over
   multiple time scales and network dynamics.

   Based on the work by Clark [3], 'mobile soft-state' relies on the fact that
   sources periodically send data messages along the existing path. If a data



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 14]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   packet arrives at a mobile router and no reservation exists then admission
   control and resource reservations are needed to establish soft-state
   reservations. Subsequent reception of a data packet at a router is used to
   refresh the soft-state reservation. Thus a mobile host receiving a data packet
   for an existing reservation reconfirms the reservation over  the next time
   interval. The holding-time for a reservation is based on a soft-state timer
   interval and not, as in the case of call setup, based on the session duration
   holding time. If a new packet is not received within a soft-state timer
   interval, resources are released and flow-states removed automatically without
   any explicit tear-down messaging.


   The soft-state approach is well suited for management of resources in dynamic
   environment where the path and reservation associated with a flow may change
   rapidly. The transmission of data packets is strongly coupled to maintenance
   of flow-states, i.e., reservations. As the route changes in the network, new
   reservations will be automatically restored by the restoration mechanism
   provided that resources are available along the new path.

   Another benefit of mobile soft-state is that resources allocated during flow
   establishment are automatically removed when the path changes without any
   explicit signaling interactions. In-band approaches are flexible and scalable
   in dealing with a number of difficult mobile ad hoc network issues whereas
   out-of-band signaling systems need to maintain source route information and
   respond to topology changes by directly signaling 'affected mobiles' to
   allocate or free radio resources. In some case, this is impossible to do when
   using out-of-band signaling techniques if the 'affected router' is out of
   radio contact from the signaling entity that is attempting to de-allocate
   resources over the old path.

4.4 FLOW RESTORATION

   Flows are often rerouted during the lifetime of sessions due to    mobility in
   mobile ad hoc networks. The goal of flow restoration is to re-establish
   reservation as fast and efficiently as possible. Rerouting of an active flow
   involves new admission control and resource reservations for nodes on the new
   path. Restoration  procedures also call for the removal of flow-state at nodes
   along the old path. In an ideal case, the restoration of flows can be
   accomplished within the duration of a few consecutive packets because of the
   in-band nature of INSIGNIA's control.

   When a mobile moves out of radio contact and loses connectivity, the
   forwarding router mobile interacts with the routing module and forwards
   subsequent packets via the new route. (Note that if the routing table does not
   have an alternative route toward the destination then the performance of the
   restoration process is tightly coupled to the performance of the
   proactive/reactive MANET routing protocol that is operational. This issue is
   for further study. In [25], however, we implemented INSIGNIA in a mid size ad
   hoc network using TORA [1] as the routing protocol and discuss performance
   issues there).

   The mobile hosts on a new path receive rerouted packets and inspect their flow
   state tables. If a reservation does not exist for the rerouted flow then the
   INSIGNIA module invokes admission control and tries to allocate



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 15]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   resources. Note that, if the reserved packets are routed back on to the
   existing path then the old states are likely to be still valid; hence, the
   states and reservations are simply refreshed, minimizing any service
   disruption due to re-rerouting.

   Network dynamics may also trigger rerouting with service degradation. When a
   reserved flow is rerouted to a node where resources are unavailable, the flow
   is degraded to best effort service. Subsequent downstream nodes receiving
   these degraded packets make no attempt to attempt to allocate resources or
   refresh existing soft-state associated with the flow. This results in the
   automatic removal of any reservation state. In time the reservation may be
   restored if resources free up at the bottleneck mobile node or because of the
   subsequent rerouting allowing the complete restoration of the flow
   quality. The worst case scenario is that the flow will remain degraded for the
   duration of the session holding time.

   The enhancement layer of a reserved flow with maximum reservation may get
   degraded during flow restoration if the nodes along the new path can only
   support the minimum bandwidth requirement. If the degradation of enhancement
   layer packets persist, it may cause service disruptions and may trigger the
   destination mobile to invoke an adaptation procedure that force the source
   node to drop the EL packets. Adaptation details are provided in the following
   section.

4.5  ADAPTATION

   Reception quality of a flow is monitored and based on an application-specific
   adaptation policy, actions may be taken to adapt the flow to observed network
   conditions. Actions taken are conditional on the adaptation-policy resident at
   the destination node, e.g., adaptation policy may chose to maintain the
   service level under degraded conditions or scale-down flows to their base
   layers in respond to degraded conditions. Other policy could scale-up flows
   whenever resources become available. The application is free to program its
   own adaptation policy that is executed by INSIGNIA through interaction between
   the destination and source nodes. Details about the adaptation policy API are
   described in [19].

   The adaptation process includes the following adaptation actions:

      (1)   'EL degradation' is a network driven action that forwards the
            EL packets as best effort packets due to lack of resources;
      (2)   'Drop enhancement layer' is a destination mobile driven action
            which requests a source to drop its enhancement layers. This
            happens when the EL degradation persists beyond an acceptable
            period; and
      (3)   'Scale-up', which requests a source to send its base and/or
            enhancement layers in reserved mode. This event occurs when
            a flow has only minimum reservation and the destination
            learns (through the bandwidth indicator) that the route
            can accommodate the maximum resource requirement.

   The EL degradation is a network driven action whereas the others two actions
   are driven by an adaptation handler resident at the destination mobile
   host. Typically, the EL degradation can be observed after rerouting of an



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 16]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   adaptive real-time flow. In such an event the EL packets are degraded and
   forwarded as best effort packets whereas BL packets are forwarded in reserved
   mode. Note that preference is given to base layers over enhancement layers in
   the event that reserved packets have to be degraded to best effort. If the EL
   degradation persists, a `drop` command may be issued by the adaptation handler
   at the destination mobile host according to the adaptation policy. The
   decision to drop the EL packets is facilitated by monitoring the incoming
   packets. The destination mobile can readily detect the degraded RES packets by
   reading the IP option fields (where the degraded packets have the format of
   Figure 5d). Figure 5 illustrates the different modes of INSIGNIA packets.

         0   1     2     3   4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
       +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |REQ| BE |BL/EL| max | max_bandwidth | min_bandwidth |
       +---+----+-----+-----+---------------+---------------+
                Figure 5a. A Best Effort Packet

             0   1     2     3   4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
       +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |REQ| AS |BL/EL| max | max_bandwidth | min_bandwidth |
       +---+----+-----+-----+---------------+---------------+
                Figure 5b. A Request Packet (EL or BL)

       +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |RES| AS |BL/EL|max/min| max_bandwidth | min_bandwidth |
       +---+----+-----+-------+---------------+---------------+
                Figure 5c. Typical Reserved (RES) Packet (EL or BL)

       +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |RES| BE |BL/EL| max | max_bandwidth | min_bandwidth |
       +---+----+-----+-----+---------------+---------------+
            Figure 5d. A Degraded RES Packet (EL or BL)

       +---+----+----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |RES| BE | BL |max/min|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0|
       +---+----+----+-------+---------------+---------------+
       |<----------->|       |<----- unique format --------->|
                                     a QOS report
             * max/min indicates the accepted service level
                Figure 5e. Format of a QOS report


   exist between a source and bottleneck mobile freeing up resources for other
   adaptive real-time flows to utilize.  It also removes degraded enhancement
   layer packets from the network which in turn benefits the normal best effort
   service flows.

   INSIGNIA is also equipped with capability to restore the reservation needed
   for enhancement layers.This process takes advantage of network and session
   dynamics allowing existing sessions to take advantages of resources released
   due to re-routing (e.g., resources released along an old path) or session
   termination. These events may allow other mobile nodes to take advantage of
   released resources by scaling up. The bandwidth indicator plays a key role in
   bandwidth needs of the particular session/flow.



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 17]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   Typically, the scale-up process is invoked when the destination observes
   sufficient resource have become available along the existing path restore the
   reservation of an enhancement layer. The decision to scale up is determined by
   the adaptation policy.

   The following example scenario shows an example of a set of  states (marked
   [1] through [7]) observed at the destination illustrating a flow adaptation
   scenario:

   Adaptation Procedures :

      [1] Incoming Packets at time t1 with maximum resource allocation
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | max | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | EL | max | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
                        .
                        .
                        .

      [2] EL packets are degraded due to lack of resources at an
      intermediate mobile node at time t2 and now packet formats become
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | min | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| BE | EL | min | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
       * Note that EL packet is degraded to a best effort packet
                        .
                        .
                        .

      [3] If the degraded EL packets are determined to be not useful for
      destination mobile host, an EL drop command is issued via QOS
      report. Upon reception of the QOS report the source transmits only
      BL packets in reserved mode and do not transmit any EL packets.
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | min | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
       * EL packets are not transmitted/received
                        .
                        .
                        .











Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 18]


INTERNET-DRAFT                  INSIGNIA                    October 1999


      [4] Constant resource availability is detected through the bandwidth
      indicator at t4 where the received packets indicating the resource
      availability have the following format.
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | max | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
       * Currently no EL packets are received.
       * Destination learns from the bandwidth indicator bit (set to max)
         that the current route has the resources available to restore the
         EL packet flow.
                        .
                        .
                        .

      [5] Through the next QOS report destination informs the source to
      reinitiate the transmission on EL in RES mode. If the recovery
      (scale up) is successful, destination receives the following
      packets.
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | max | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| BE | EL | max | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
                                            .
                                            .
                                            .

      [6] If scale up attempt fails at any mobile node on the route,
      destination receives degraded EL packets.
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| AS | BL | min | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+
      +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |RES| BE | EL | min | max_bandwidth | min_bandwidth |
      +---+----+----+-----+---------------+---------------+

      [7] If the EL degradation persist after step [6], another drop EL
      command is issued via following QOS report.


   The decision to drop/scale up is entirely up to the application-specific
   adaptation policy residing at destination mobile. For example a video flow may
   be sensitive to delays and delivery of constantly changing bandwidth so once
   enhancement layer packets are dropped, it requires stable resource
   availability of resources before a scale up decision is made. In the case of
   real-time data, there may not be any drop command and the application may want
   to closely follow the dynamics of resource availability. In such case the
   adaptation policy is quite different from that of a video flow example.








Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 19]


INTERNET-DRAFT                  INSIGNIA                    October 1999


5. SECURITY ISSUES

   The MANET computing environment is very different from the ordinary computing
   environment. In many cases, mobile computers will be connected to the network
   via wireless links.  Such links are particularly vulnerable to passive
   eavesdropping, active replay attacks, and other active attacks. A stringent
   authentication and registration processes are required to avoid any malicious
   users. Currently, INSIGNIA does not specify any special security measures.


6. APPLICATIONS

   INSIGNIA can be used as signaling support for small (pico-cell) and large
   scale mobile networks. Flows and microflows can be supported. Voice, video and
   real-time data applications can be supported using the INSIGNIA adaptive
   real-time service. In addition, INSIGNIA networks support traditional best
   effort services.


7. ACKNOWLEDGMENT

   The work is supported in part by the Army Research Office (ARO) under award
   DAAD19-99-1-0287 and with support from COMET Group industrial sponsors.


8. REFERENCE

   [1]   V. Park, and S. Corson, "Temporally Ordered Routing Algorithm
         (TORA) Version 1 Functional Specification", draft-ietf-manet-
         tora-spec-00.txt, November 1997.
   [2]   J. Macker, and M. S. Corson, "Mobile Ad hoc Networking (MANET):
         Routing Protocol Performance Issues and Evaluation
         Considerations", draft-ietf-manet-issues-01.txt, April 1998.
   [3]   D. D. Clark and D.L. Tennenhouse, "Architectural Consideration
         for a New Generation of Protocols", Proc. ACM SIGCOMM'90, August
         1990.
   [4]   M. Gerla and J.T-C Tsai, "Multicluster, mobile. Multimedia Radio
         Network", Wireless Networks 1(3), 1995
   [5]   Z. Haas and M. Pearlman, "The Zone Routing Protocol (ZRP) for Ad
         Hoc Networks", draft-ietf-manet-zone-zrp-00.txt
   [6]   C. Perkins, "Ad hoc On demand Distance Vector Routing",
         draft-ieft-manet-aodv-01.txt
   [7]   D. B. Johnson and D. A. Maltz, "Dynamic Source Routing in Ad Hoc
         Wireless Network", In Mobile Computing, Chapter 5, pp. 153-181.
   [8]   M. S. Corson, "Issues in Supporting Quality of Service in Mobile
         Ad Hoc Networks", Proc. IFIP Fifth International Workshop on
         Quality of Service (IWQOS '97), Columbia University.
   [9]   C. R. Lin and M. Gerla, "A Distributed Architecture for
         Multimedia in a Multihop Dynamic Packet Radio Network,"
         Proceedings of IEEE Globecom'95, Nov., pp. 1468-1472.

   [10]  V. Park and M. S. Corson, "A Highly Adaptive Distributed Routing
         Algorithm for Mobile Wireless Networks", Proceedings of IEEE
         INFOCOM'97, April 1997



Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 20]


INTERNET-DRAFT                  INSIGNIA                    October 1999


   [11]  V. Park and M.S. Corson, "A Performance Comparison of the
         Temporally-Ordered-Routing Algorithm and Ideal Link-State
         Routing", Proceedings of IEEE Symposium on Computers and
         Communication '98, June 1998, Athens, Greece.
   [12]  W. Almesberger, T. Ferrari and J. Le Boudec, "SRP: a Scalable
         Resource Reservation Protocol for the Internet",
         http://lrcwww.epfl.ch/srp/
   [13]  R. Ramanathan and M. Streenstrup, "Hierarchically-organized,
         multihop mobile wireless networks for quality-of-service
         support", ftp://ftp.bbn.com /pub/ramanath/mmwn-paper.ps
   [14]  C. R. Lin and M. Gerla, "Asynchronous Multimedia Multihop
         Wireless Networks," Proceedings of IEEE INFOCOM'97, April 1997.
   [15]  R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
         ReSerVation Protocol (RSVP)", RFC 2205, September 1997.
   [16]  P. Sharma, D. Estrin, S. Floyd, and V. Jacobson, "Scalable Timers
         for Soft-State Protocols", IEEE INFOCOM 1997, April 1997.
   [17]  P. Ferguson, "Simple Differential Services: IP TOS and
         Precedence, Delay Indication and Drop Preferences",
         draft-ferguson-delay-drop-00.txt
   [18]  M. S. Corson and V. Park, "An Internet MANET Encapsulation
         Protocol (IMEP) Specification. Internet Draft,
         draft-ietf-manet-imep-spec-01.txt, November 1997.
   [19]  R. R-F. Liao and A.T. Campbell, "On Programmable Universal Mobile
         Channels in a Cellular Internet", 4th ACM/IEEE International
         Conference on Mobile Computing and Networking
         (MOBICOM'98), Dallas, October, 1998.
   [20]  M.S. Corson and A.T Campbell, "Toward Supporting Quality of
         Service in Mobile Ad Hoc Networks", First Conference on Open
         Architecture and Network Programming, San Franscisco, April 3-4,
         1998.
   [21]  J. Broch, D. A. Maltz, D. B. Johnson, Y-C Hu, and J. Jetcheva, "A
         Performance Comparison of Multi-Hop Wireless Ad Hoc Network
         Routing Protocols", to appear in Proc. of the 4th Annual ACM/IEEE
         International Conference on Mobile Computing and Networking, ACM,
         Dallas, TX, October 1998.
   [22]  S. Lu, V. Bharghavan, and R. Srikant. "Fair scheduling in
         wireless packet networks".  In Proceedings of ACM SIGCOMM, San
         Francisco, California, 1997
   [23]  OPNET, http://www.mil3.com
   [24]  A. S. Acampora and M. Naghshineh, "QOS provisioning in micro-
         cellular networks supporting multiple classes of traffic",
         Wireless Networks, 2(3), 1996.
   [25]  Lee, S-B. and A.T. Campbell, "INSIGNIA: In-band Signaling
         Support for QOS in Mobile Ad Hoc Networks" Proc of 5th
         International Workshop on Mobile Multimedia Communications
         (MoMuC,98), Berlin, Germany, October 1998.
   [26]  S-B. Lee, G-S. Ahn, X. Zhang and Andrew T. Campbell,
         "INSIGNIA: A QoS Framework for Mobile Ad Hoc Networks", Journal of
         Parallel and Distributed Computing - Special Issues on Wireless and
         Mobile Computing, Jan 2000 (to be published).







Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 21]


INTERNET-DRAFT                  INSIGNIA                    October 1999


9. AUTHORS' ADDRESSES

      Seoung-Bum Lee (Managing Author), Gahng-Seop Ahn, Andrew T. Campbell,
      Xiawei Zhang


      Department of Electrical Engineering, Columbia University
      Rm. 801 Schapiro Research Building
      530 W. 120th Street, New York, N.Y. 10027
      phone: (212) 854 3109
      fax  : (212) 316 9068 (COMET Group)
      email: [sbl, ahngang, campbell, xzhang]@comet.columbia.edu













































Ahn, Campbell, Lee, Zhang       Expires May 2000               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/