[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
INTERNET-DRAFT                    Seoung-Bum Lee and Andrew T. Campbell
                                                    Columbia University
<draft-ietf-manet-insignia-00.txt>                        November 1998
Expires May 1999

                                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 algorithms and IMEP
   specification.









Lee and Campbell            Expires May 1999                   [Page 1]


INTERNET DRAFT                  INSIGNIA                 November, 1998


Table of Contents

1.  INTRODUCTION ..................................................  2
    1.1  TERMINOLOGY ..............................................  3
    1.2  ASSUMPTIONS ..............................................  5

2.  A WIRELESS FOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING ..  5
    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 ........................................... 12
    4.1  FLOW SETUP ............................................... 12
    4.2  QOS REPORTING ............................................ 14
    4.3  SOFT-STATE MANAGEMENT .................................... 15
    4.4  FLOW RESTROATION ......................................... 16
    4.5  ADAPTATION ............................................... 17

5.  INTEROPERABILITY WITH IMEP .................................... 21

6.  SECURITY ISSUES ............................................... 21

7.  APPLICATION ................................................... 22

8.  ACKNOWLEDGMENT ................................................ 22

9.  REFERENCE ..................................................... 22

10. AUTHOR'S ADDRESSES ............................................ 24


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


Lee and Campbell            Expires May 1999                   [Page 2]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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.

 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].





Lee and Campbell            Expires May 1999                   [Page 3]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 flows
      and 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
      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.




Lee and Campbell            Expires May 1999                   [Page 4]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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.)

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-


Lee and Campbell            Expires May 1999                   [Page 5]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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



Lee and Campbell            Expires May 1999                   [Page 6]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 if
   resources are unavailable.




Lee and Campbell            Expires May 1999                   [Page 7]


INTERNET DRAFT                  INSIGNIA                 November, 1998


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


Lee and Campbell            Expires May 1999                   [Page 8]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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|RT/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


Lee and Campbell            Expires May 1999                   [Page 9]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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
   real-time (RT) or best-effort (BE) packet, is dependent on the
   reservation mode. A packet with the reservation mode set to REQ and
   service type to RT 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/RT set indicates that an end-to-end
   reservation has previously been established. A RES/RT 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/RT) 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


Lee and Campbell            Expires May 1999                  [Page 10]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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.

   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 RT
   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


Lee and Campbell            Expires May 1999                  [Page 11]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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
   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 handled by 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 RT, 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| RT |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


Lee and Campbell            Expires May 1999                  [Page 12]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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.

   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 RT 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


Lee and Campbell            Expires May 1999                  [Page 13]


INTERNET DRAFT                  INSIGNIA                 November, 1998


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 QOS report is a
   best effort data packet with a payload that comprises of a 'mirror
   copy' of the INSIGNIA IP option received by the destination,
   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 'mirror copy' of the INSIGNIA IP option, adaptation
   commands and measured QOS. In fact, the QOS report of INSIGNIA has


Lee and Campbell            Expires May 1999                  [Page 14]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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.



Lee and Campbell            Expires May 1999                  [Page 15]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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


Lee and Campbell            Expires May 1999                  [Page 16]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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 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.



Lee and Campbell            Expires May 1999                  [Page 17]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   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| RT |BL/EL| max | max_bandwidth | min_bandwidth |
    +---+----+-----+-----+---------------+---------------+
             Figure 5b. A Request Packet (EL or BL)

    +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |RES| RT |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


   'Dropping' the EL packet at the source removes partial reservations
   that may 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


Lee and Campbell            Expires May 1999                  [Page 18]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   allow other mobile nodes to take advantage of released resources by
   scaling up. The bandwidth indicator plays a key role in 'reading'
   the channels  resource availability state in relation to the
   bandwidth needs of the particular session/flow.

   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| RT | BL | max | max_bandwidth | min_bandwidth |
   +---+----+----+-----+---------------+---------------+
   +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |RES| RT | 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| RT | 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| RT | BL | min | max_bandwidth | min_bandwidth |
   +---+----+----+-----+---------------+---------------+
    * EL packets are not transmitted/received
                     .
                     .
                     .


Lee and Campbell            Expires May 1999                  [Page 19]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   [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| RT | 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| RT | 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| RT | 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.



Lee and Campbell            Expires May 1999                  [Page 20]


INTERNET DRAFT                  INSIGNIA                 November, 1998


5. NETWORK LAYER FUNCTIONALITY - INTEROPERABILITY WITH IMEP

   Since Internet MANET Encapsulation Protocol is a network layer
   protocol designed to support the operation of many routing
   algorithms and any other higher layer protocols intended for use in
   mobile ad hoc networks, INSIGNIA can be fully incorporated with IMEP
   mechanisms. IMEP will provide mechanisms for supporting link status
   and neighbor connectivity sensing, lower layer control packet
   aggregation and encapsulation, one-hop neighbor broadcast (or
   multicast) reliability, multi-point relaying, network-layer address
   resolution and provides hooks for inter-router authentication
   procedures.

   IMEP [18] improves overall network performance by reducing the
   number of network control message broadcasts through encapsulation
   and aggregation of multiple MANET control messages (e.g. routing
   protocol packets, acknowledgements, link status sensing messages,
   network-level address resolution, etc.) into larger IMEP messages.

   Usage of the IMEP is desirable because per-message, multiple access
   delay in contention-based schemes such as CSMA/CA, IEEE 802.11, FAMA
   etc. is significant, and thus favors the use of fewer, larger
   messages. It would also be useful in reservation-based, time-slotted
   access schemes where smaller packets must be aggregated into
   appropriately-sized IP packets for transmission in a given time
   slot. Upper layer protocols other than routing may make use of this
   encapsulation functionality for the same purpose.

   Moreover, IMEP will provide the commonality among many network-level
   routing algorithms. Many algorithms intended for use in a MANET will
   require common functionality such as link status sensing, security
   authentication with adjacent mobiles, broadcast reliability of
   network control messages, etc. This common functionality can be
   extracted from various protocols and can become generic protocol
   useful to all. The routing algorithms would also benefit from the
   common approach to mobile and interface identification and
   addressing. The IMEP will run at the network layer and will be an
   adjunct to whichever network routing protocol is using it. Routing
   control packets will be encapsulated in IMEP messages, which will be
   further encapsulated into IP packets.


6. 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.



Lee and Campbell            Expires May 1999                  [Page 21]


INTERNET DRAFT                  INSIGNIA                 November, 1998


   Authentication :
        The IMEP Authentication object [18] is used to authenticate all
        IMEP objects. The types of authentication to be supported and
        specified in a proposed MANET Authentication Architecture under
        development.

   Registration :
        Upper layer protocols, i.e., INSIGNIA must register with IMEP
        prior to use.


7. 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.

8. ACKNOWLEDGMENT

   We would like to thank Mischa Schwartz and Javier Gomez Castellanos
   for comments on this work.

9. 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.




Lee and Campbell            Expires May 1999                  [Page 22]


INTERNET DRAFT                  INSIGNIA                 November, 1998


[10]  V. Park and M. S. Corson, "A Highly Adaptive Distributed Routing
      Algorithm for Mobile Wireless Networks", Proceedings of IEEE
      INFOCOM'97, April 1997
[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.




Lee and Campbell            Expires May 1999                  [Page 23]


INTERNET DRAFT                  INSIGNIA                 November, 1998


10. AUTHORS' ADDRESSES


    Seoung-Bum Lee, Andrew T. Campbell

    COMET Group
    Columbia University
    530 w 120th street
    Schapiro Research Building
    New York, NY 10027
    phone (212) 854 - 0871
    [sbl,campbell]@comet.columbia.edu

See comet.columbia.edu/insignia for more information







































Lee and Campbell            Expires May 1999                  [Page 24]