draft-ietf-manet-insignia-00.txt | draft-ietf-manet-insignia-01.txt | |||
---|---|---|---|---|
INTERNET-DRAFT G-S. Ahn, A. T. Cambell, S-B Lee, X. Zhang | ||||
INTERNET-DRAFT Seoung-Bum Lee and Andrew T. Campbell | ||||
Columbia University | Columbia University | |||
<draft-ietf-manet-insignia-00.txt> November 1998 | October 1999 | |||
Expires May 1999 | ||||
<draft-ietf-manet-insignia-01.txt> | ||||
Expires May 2000 | ||||
INSIGNIA | INSIGNIA | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with | |||
all provisions of Section 10 of RFC2026. Internet-Drafts are working | all provisions of Section 10 of RFC2026. Internet-Drafts are working | |||
documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six months | |||
months and may be updated, replaced, or obsoleted by other documents | and may be updated, replaced, or obsoleted by other documents at any | |||
at any time. It is inappropriate to use Internet- Drafts as | time. It is inappropriate to use Internet- Drafts as reference | |||
reference material or to cite them other than as ``work in | material or to cite them other than as ``work in progress.'' The list | |||
progress.'' | of current Internet-Drafts can be accessed at: | |||
The list of current Internet-Drafts can be accessed at: | ||||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at: | The list of Internet-Draft Shadow Directories can be accessed at: | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. Distribution of this memo is | |||
unlimited. | ||||
Distribution of this memo is unlimited. | ||||
Abstract | Abstract | |||
This document specifies INSIGNIA, an in-band signaling system for | This document specifies INSIGNIA, an in-band signaling system for | |||
supporting quality of service (QOS) in mobile ad hoc networks. The | supporting quality of service (QOS) in mobile ad hoc networks. The | |||
term `in-band signaling` refers to the fact that control information | term `in-band signaling` refers to the fact that control information | |||
is carried along with data in IP packets. We argue that in-band | is carried along with data in IP packets. We argue that in-band | |||
signaling is more suitable than explicit out-of-band approaches | signaling is more suitable than explicit out-of-band approaches | |||
(e.g., RSVP) when supporting end-to-end quality of service in highly | (e.g., RSVP) when supporting end-to-end quality of service in highly | |||
dynamic environments such as mobile ad hoc networks where network | dynamic environments such as mobile ad hoc networks where network | |||
topology, node connectivity and end-to-end quality of service are | topology, node connectivity and end-to-end quality of service are | |||
strongly time-varying. INSIGNIA is designed to support the delivery | strongly time-varying. INSIGNIA is designed to support the delivery | |||
of adaptive real-time services and includes fast session/flow/ | of adaptive real-time services and includes fast | |||
microflow reservation, restoration and adaptation algorithms | session/flow/microflow reservation, restoration and adaptation | |||
between source/destination pairs. In this memo we discuss how | algorithms between source/destination pairs. In this memo we discuss | |||
INSIGNIA fits into our broader vision of a wireless flow management | how INSIGNIA fits into our broader vision of a wireless flow | |||
model for mobile ad hoc networks and how it interfaces to the | management model for mobile ad hoc networks and how it interfaces to | |||
proposed MANET Working Group routing algorithms and IMEP | the proposed MANET Working Group routing algorithm. | |||
specification. | ||||
Table of Contents | Table of Contents | |||
1. INTRODUCTION .................................................. 2 | 0. WHAT'S CHANGED .............................................. 2 | |||
1.1 TERMINOLOGY .............................................. 3 | ||||
1.2 ASSUMPTIONS .............................................. 5 | ||||
2. A WIRELESS FOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING .. 5 | 1. INTRODUCTION ................................................ 3 | |||
2.1 PACKET FORWARDING MODULE ................................. 7 | 1.1 TERMINOLOGY ............................................ 4 | |||
2.2 ROUTING MODULE ........................................... 7 | 1.2 ASSUMPTIONS ............................................ 6 | |||
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 | 2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING 6 | |||
3.1 INSIGNIA IP OPTIONS ...................................... 8 | 2.1 PACKET FORWARDING MODULE ............................... 7 | |||
3.2 RESERVATION MODE ......................................... 9 | 2.2 ROUTING MODULE ......................................... 7 | |||
3.3 SERVICE TYPE ............................................. 10 | 2.3 INSIGNIA MODULE ........................................ 7 | |||
3.4 PAYLOAD INDICATOR ........................................ 10 | 2.4 ADMISSION CONTROL MODULE ............................... 7 | |||
3.5 BANDWIDTH INDICATOR ...................................... 10 | 2.5 PACKET SCHEDULING MODULE ............................... 8 | |||
3.6 BANDWIDTH REQUEST ........................................ 11 | 2.6 MEDIUM ACCESS CONTROLLER MODULE ........................ 8 | |||
4. INSIGNIA OPERATIONS ........................................... 12 | 3. INSIGNIA PROTOCOL ........................................... 8 | |||
4.1 FLOW SETUP ............................................... 12 | 3.1 INSIGNIA IP OPTIONS .................................... 8 | |||
4.2 QOS REPORTING ............................................ 14 | 3.2 RESERVATION MODE ....................................... 9 | |||
4.3 SOFT-STATE MANAGEMENT .................................... 15 | 3.3 SERVICE TYPE ........................................... 10 | |||
4.4 FLOW RESTROATION ......................................... 16 | 3.4 PAYLOAD INDICATOR ...................................... 10 | |||
4.5 ADAPTATION ............................................... 17 | 3.5 BANDWIDTH INDICATOR .................................... 10 | |||
3.6 BANDWIDTH REQUEST ...................................... 11 | ||||
5. INTEROPERABILITY WITH IMEP .................................... 21 | 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 | ||||
6. SECURITY ISSUES ............................................... 21 | 5. SECURITY ISSUES ............................................. 20 | |||
7. APPLICATION ................................................... 22 | 6. APPLICATION ................................................. 20 | |||
8. ACKNOWLEDGMENT ................................................ 22 | 7. ACKNOWLEDGMENT .............................................. 20 | |||
9. REFERENCE ..................................................... 22 | 8. REFERENCE ................................................... 20 | |||
10. AUTHOR'S ADDRESSES ............................................ 24 | 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]. | ||||
1. INTRODUCTION | 1. INTRODUCTION | |||
The introduction of real-time audio, video and data services into | The introduction of real-time audio, video and data services into | |||
mobile ad hoc networks presents number of technical barriers that | mobile ad hoc networks presents number of technical barriers that are | |||
are due to the time-varying nature of the network topology, node | due to the time-varying nature of the network topology, node | |||
connectivity and end-to-end quality of service (QOS). In such | connectivity and end-to-end quality of service (QOS). In such | |||
networks, mobile nodes function as hosts and routers. As hosts they | networks, mobile nodes function as hosts and routers. As hosts they | |||
represent source and destination nodes in the network while as | represent source and destination nodes in the network while as | |||
routers they represent intermediate nodes between a source and | routers they represent intermediate nodes between a source and | |||
destination providing store-and-forward services to neighboring | destination providing store-and-forward services to neighboring | |||
nodes. The wireless topology that interconnects mobile hosts/routers | nodes. The wireless topology that interconnects mobile hosts/routers | |||
can change rapidly in unpredictable ways or remain relatively static | can change rapidly in unpredictable ways or remain relatively static | |||
over long periods of time. Another technical issue that needs to be | over long periods of time. Another technical issue that needs to be | |||
addressed is associated with the wireless link level performance. | addressed is associated with the wireless link level performance. | |||
Mobile ad hoc networks are bandwidth constrained and time-varying | Mobile ad hoc networks are bandwidth constrained and time-varying due | |||
due to radio link characteristics and impairments. | to radio link characteristics and impairments. | |||
The end-to-end communications abstraction between two communicating | The end-to-end communications abstraction between two communicating | |||
mobile hosts can be viewed as a complex channel. Due to node | mobile hosts can be viewed as a complex channel. Due to node mobility | |||
mobility and wireless link impairments, user-to-user sessions may | and wireless link impairments, user-to-user sessions may need to be | |||
need to be rerouted in the network while preserving the session | rerouted in the network while preserving the session connectivity and | |||
connectivity and quality. Network algorithms need to be strongly | quality. Network algorithms need to be strongly adaptive and | |||
adaptive and responsive to the time-varying and location dependent | responsive to the time-varying and location dependent topological | |||
topological changes, resource availability, quality of service | changes, resource availability, quality of service degradation and | |||
degradation and session connectivity. | session connectivity. | |||
In order to provide adaptive quality of service support for real- | In order to provide adaptive quality of service support for real-time | |||
time service in mobile ad hoc networks, 'flow-states' (i.e., | service in mobile ad hoc networks, 'flow-states' (i.e., reservation | |||
reservation states at nodes associated with flows or microflows) | states at nodes associated with flows or microflows) need to be | |||
need to be managed. A flow needs to be established, restored, | managed. A flow needs to be established, restored, adapted and | |||
adapted and removed over the course of a user-to-user session in | removed over the course of a user-to-user session in response to | |||
response to time-varying topology, connectivity and end-to-end | time-varying topology, connectivity and end-to-end quality of service | |||
quality of service conditions. | conditions. | |||
Since wireless and computational resources are limited in mobile ad | Since wireless and computational resources are limited in mobile ad | |||
hoc networks, any signaling overhead needed for wireless flow | hoc networks, any signaling overhead needed for wireless flow | |||
management must be kept to a bare minimum. Future signaling systems | management must be kept to a bare minimum. Future signaling systems | |||
should be capable of restoring reservations and associated flow- | should be capable of restoring reservations and associated flow- | |||
states along a new path in response to topological changes with | states along a new path in response to topological changes with | |||
minimum noticeable degradation at the user session level. | minimum noticeable degradation at the user session level. | |||
This memo provides an overview of wireless flow management model | This memo provides an overview of wireless flow management model that | |||
that supports the delivery of adaptive real-time services in dynamic | supports the delivery of adaptive real-time services in dynamic | |||
mobile ad hoc networks. A key component of wireless flow management | mobile ad hoc networks. A key component of wireless flow management | |||
is INSIGNIA, an in-band signaling system that supports fast flow | is INSIGNIA, an in-band signaling system that supports fast flow | |||
reservation, restoration and adaptation algorithms that are | reservation, restoration and adaptation algorithms that are | |||
specifically designed to deliver adaptive real-time services in | specifically designed to deliver adaptive real-time services in | |||
mobile ad hoc networking environments. INSIGNIA is designed to be | mobile ad hoc networking environments. INSIGNIA is designed to be | |||
lightweight and highly responsive to changes in network topology, | lightweight and highly responsive to changes in network topology, | |||
node connectivity and end-to-end quality of service conditions. | node connectivity and end-to-end quality of service conditions. For | |||
full detail on the evaluation of INSIGNIA, see [26]. | ||||
1.1 TERMINOLOGY | 1.1 TERMINOLOGY | |||
Mobile Ad Hoc Networks: | Mobile Ad Hoc Networks: | |||
Represent autonomous distributed systems that comprise a | Represent autonomous distributed systems that comprise a | |||
number of mobile nodes connected by wireless links forming | number of mobile nodes connected by wireless links forming | |||
arbitrary time-varying wireless network topologies [20]. | arbitrary time-varying wireless network topologies [20]. | |||
Adaptive real-time flows: | Adaptive real-time flows: | |||
This type of flow represents delay sensitive traffic, e.g., voice | This type of flow represents delay sensitive traffic, | |||
and video which can sustain some loss. Real time data flows are | e.g., voice and video which can sustain some loss. Real time | |||
assumed to be somewhat loss tolerant and delay sensitive. | data flows are assumed to be somewhat loss tolerant and delay | |||
These types of flows typically require flow setup procedures, | sensitive. These types of flows typically require flow setup | |||
resource reservation provided by INSIGNIA. | procedures, resource reservation provided by INSIGNIA. | |||
Microflows: | Microflows: | |||
Micro flows represent short-lived flows, e.g. web style | Micro flows represent short-lived flows, e.g. web style | |||
client/server interactions that comprises a limited train of data | client/server interactions that comprises a limited train of | |||
packets. These types of flows may require resource assurances in | data packets. These types of flows may require resource | |||
the network and, therefore, typically require some form of in- | assurances in the network and, therefore, typically require | |||
band support for fast resource allocation. We use the terms | some form of in-band support for fast resource allocation. We | |||
session/flow and microflow interchangeably. INSIGNIA has been | use the terms session/flow and microflow interchangeably. | |||
designed to transparently support the requirements of both flows | INSIGNIA has been designed to transparently support the | |||
and microflows in mobile ad hoc networks. | requirements of both flowsand microflows in mobile ad hoc | |||
networks. | ||||
Flow Setup: | Flow Setup: | |||
A Source initiates a flow set up by transmitting a request packet | A Source initiates a flow set up by transmitting a request | |||
with its minimum and maximum bandwidth requirements. Intermediate | packet with its minimum and maximum bandwidth requirements. | |||
mobiles receiving request packets, processes the requests and | Intermediate mobiles receiving request packets, processes the | |||
forward them to the next appropriate mobile host. A flow setup is | requests and forward them to the next appropriate mobile host. | |||
complete when a source receives a QOS report from its peer | A flow setup is complete when a source receives a QOS report | |||
destination. | from its peer destination. | |||
Restoration: | Restoration: | |||
When a reserved flow is rerouted and its associated states | When a reserved flow is rerouted and its associated states | |||
(e.g., reservation) are successfully created along the new route. | (e.g., reservation) are successfully created along the new | |||
Three types of restoration (viz. `max to max`, `max to min` and | route. Three types of restoration (viz. `max to max`, | |||
`min to max`) may be observed along the new path. | `max to min` and `min to max`) may be observed along the new | |||
path. | ||||
Enhancement Layer (EL) Degradation: | Enhancement Layer (EL) Degradation: | |||
When a reserved flow is rerouted and its EL restoration fails, | When a reserved flow is rerouted and its EL restoration fails, | |||
then a flow/sessions enhancement layer packets are degraded | then a flow/sessions enhancement layer packets are degraded | |||
to best effort service. In a such case, only base layer (BL) | to best effort service. In a such case, only base layer (BL) | |||
packets are forwarded/received as reserved packets. | packets are forwarded/received as reserved packets. | |||
Flow Degradation: | Flow Degradation: | |||
When a reserved flow is rerouted and both EL and BL restoration | When a reserved flow is rerouted and both EL and BL restoration | |||
fails. No resource allocation or associated states are created | fails. No resource allocation or associated states are created | |||
and all packets are treated as best effort after re-routing. | and all packets are treated as best effort after re-routing. | |||
Adaptation: | Adaptation: | |||
When EL degradation persists for an unacceptable period, a | When EL degradation persists for an unacceptable period, a | |||
destination mobile notifies its source to drop the EL packets | destination mobile notifies its source to drop the EL packets | |||
at the source host (scaling down). The destination can also | at the source host (scaling down). The destination can also | |||
initiates an EL resource recovery (scaling up) procedure when a | initiates an EL resource recovery (scaling up) procedure when a | |||
monitored flow state at the destination indicate that sufficient | monitored flow state at the destination indicate that | |||
resources exist along the path to support a better quality level. | sufficient resources exist along the path to support a better | |||
quality level. | ||||
Adaptation Policy: | Adaptation Policy: | |||
Describes the bandwidth adaptation characteristics of a flow and | Describes the bandwidth adaptation characteristics of a flow | |||
the actions to be taken based on the observed network conditions | and the actions to be taken based on the observed network | |||
experienced by a flow and its ability to adapt to those | conditions experienced by a flow and its ability to adapt to | |||
conditions. The decision to trigger adaptation mechanisms (i.e., | those conditions. The decision to trigger adaptation mechanisms | |||
scaling flows up/down)is based on application-specific adaptation | (i.e., scaling flows up/down)is based on application-specific | |||
policy. | adaptation policy. | |||
Adaptation Handler: | Adaptation Handler: | |||
A module that stores the adaptation policy that interacts with | A module that stores the adaptation policy that interacts with | |||
flow monitoring and QOS report modules. | flow monitoring and QOS report modules. | |||
Monitoring Module: | Monitoring Module: | |||
A module that keeps track of the incoming INSIGNIA flow state. | A module that keeps track of the incoming INSIGNIA flow state. | |||
Typically the packet type, resource availability and QOS | Typically the packet type, resource availability and QOS | |||
are periodically monitored. | are periodically monitored. | |||
QOS reports: | QOS reports: | |||
These are periodic messages that are generated by destinations | These are periodic messages that are generated by destinations | |||
to inform peer sources of reception state/status of adaptive | to inform peer sources of reception state/status of adaptive | |||
real-time flows. The periodicity depends on the sensitivity of a | real-time flows. The periodicity depends on the sensitivity of | |||
flow. Best effort flows do not, typically, generate QOS reports. | a flow. Best effort flows do not, typically, generate QOS | |||
reports. | ||||
Soft-state management: | Soft-state management: | |||
Each mobile host creates, stores and updates the state | Each mobile host creates, stores and updates the state | |||
information for each adaptive real-time flow and its reservation | information for each adaptive real-time flow and its | |||
status. This state information requires subsequent packets to | reservation status. This state information requires subsequent | |||
refresh the flow state otherwise the flow state is considered old | packets to refresh the flow state otherwise the flow state is | |||
and automatically removed after a soft-state interval. | considered old and automatically removed after a soft-state | |||
interval. | ||||
Soft-state timer: | Soft-state timer: | |||
The soft-state timer value defines the holding time for real-time | The soft-state timer value defines the holding time for real- | |||
reservation state for adaptive real-time flows/flows. If the | time reservation state for adaptive real-time flows/flows. If | |||
mobile soft-state is not refreshed within the soft-state timer | the mobile soft-state is not refreshed within the soft-state | |||
interval then the state is automatically removed. (Note that the | timer interval then the state is automatically removed. (Note | |||
treatment of flows and microflows may differ in terms of the | that the treatment of flows and microflows may differ in terms | |||
setting of this state variable. Typically, flows would call for | of the setting of this state variable. Typically, flows would | |||
extremely fast reservation and release that may be more aggressive | call for extremely fast reservation and release that may be | |||
than the dynamics and timescales associated with longer lived | more aggressive than the dynamics and timescales associated | |||
flows. This issue is under experimentation and for further study.) | with longer lived flows. This issue is under experimentation | |||
and for further study.) | ||||
1.2 ASSUMPTIONS | 1.2 ASSUMPTIONS | |||
INSIGNIA assumes that link status sensing and access schemes are | INSIGNIA assumes that link status sensing and access schemes are | |||
provided by lower layer entities/protocols. | provided by lower layer entities/protocols. | |||
2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING | 2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING | |||
The goal of wireless flow management is to support the delivery of | The goal of wireless flow management is to support the delivery of | |||
adaptive real-time services in mobile ad hoc hosts under time- | adaptive real-time services in mobile ad hoc hosts under time- | |||
varying conditions. An adaptive service model allows packet audio, | varying conditions. An adaptive service model allows packet audio, | |||
video and real-time data applications to specify their maximum and | video and real-time data applications to specify their maximum and | |||
minimum bandwidth needs. INSIGNIA plays a central role in the | minimum bandwidth needs. INSIGNIA plays a central role in the | |||
resources allocation and management between source and destination | resources allocation and management between source and destination | |||
mobiles. Based on availability of end-to-end resources, wireless | mobiles. Based on availability of end-to-end resources, wireless | |||
flow management attempts to provide assurances for the minimum or | flow management attempts to provide assurances for the minimum or | |||
maximum bandwidth needs depending of resource availability. In | maximum bandwidth needs depending of resource availability. In | |||
addition to supporting adaptive real-time services the service model | addition to supporting adaptive real-time services the service | |||
also supports IP best-effort packet delivery. | model also supports IP best-effort packet delivery. | |||
adaptive mobile | adaptive mobile | |||
applications | applications | |||
^ | ^ | |||
+--------------------------------------------------------------+ | +--------------------------------------------------------------+ | |||
| | | | | | | | |||
| +---------------+ | +-----------------+ +-----------+ | | | +---------------+ | +-----------------+ +-----------+ | | |||
| | MANET routing | | | INSIGNIA |<---> | admission | | | | | MANET routing | | | INSIGNIA |<---> | admission | | | |||
| | protocol | | | | | control | | | | | protocol | | | | | control | | | |||
| +---------------+ | +-----------------+ +-----------+ | | | +---------------+ | +-----------------+ +-----------+ | | |||
skipping to change at page 6, line 40 | skipping to change at page 6, line 50 | |||
| \ \ v -ing / \ | drop / \ | | | \ \ v -ing / \ | drop / \ | | |||
| \ +------------+ +-----------+ \ | | | \ +------------+ +-----------+ \ | | |||
| +-----+ \| packet | | packet | +-----+ | | | +-----+ \| packet | | packet | +-----+ | | |||
===>| MAC |===>| forwarding |======>| scheduling|====>| MAC |===> | ===>| MAC |===>| forwarding |======>| scheduling|====>| MAC |===> | |||
| +-----+ +------------+ +-----------+ +-----+ | | | +-----+ +------------+ +-----------+ +-----+ | | |||
|IP packet in data packets IP packet out| | |IP packet in data packets IP packet out| | |||
+--------------------------------------------------------------+ | +--------------------------------------------------------------+ | |||
Figure 1. Wireless Flow Management Model at a Mobile Host/Router | Figure 1. Wireless Flow Management Model at a Mobile Host/Router | |||
Realizing wireless flow management in mobile ad hoc networks | Realizing wireless flow management in mobile ad hoc networks presents | |||
presents a number of technical challenges. First, flows and | a number of technical challenges. First, flows and microflows should | |||
microflows should be rapidly established without the penalty of a | be rapidly established without the penalty of a round trip delay and | |||
round trip delay and with minimal overhead due to signaling. Second, | with minimal overhead due to signaling. Second, active flows should | |||
active flows should be maintained and restored in case of routing | be maintained and restored in case of routing changes or link | |||
changes or link failure. Wireless flow management should be capable | failure. Wireless flow management should be capable of rapidly | |||
of rapidly responding to dynamic topology changes by adapting and | responding to dynamic topology changes by adapting and re- | |||
re-establishing affected flows with minimal service disruption. | establishing affected flows with minimal service disruption. Third, | |||
Third, flow-state set up during flow establishment should be | flow-state set up during flow establishment should be automatically | |||
automatically removed when an application session terminates. Flow- | removed when an application session terminates. Flow-state should | |||
state should also be automatically removed at routers no longer on | also be automatically removed at routers no longer on the new path | |||
the new path after re-routing has occurred due to topological | after re-routing has occurred due to topological changes. The main | |||
changes. | modules of the wireless flow management model are illustrated in | |||
Figure 1). | ||||
The main modules of the wireless flow management model are | ||||
illustrated in Figure 1). | ||||
2.1 PACKET FORWARDING MODULE | 2.1 PACKET FORWARDING MODULE | |||
The packet forwarding module [15] classifies incoming packets | The packet forwarding module [15] classifies incoming packets and | |||
and forwards them to the appropriate module (viz. MANET routing, | forwards them to the appropriate module (viz. MANET routing, | |||
INSIGNIA, local applications, wireless packet scheduling modules). | INSIGNIA, local applications, wireless packet scheduling modules). | |||
Signaling messages are processed by INSIGNIA and data packets | Signaling messages are processed by INSIGNIA and data packets | |||
delivered locally or forwarded to the packet scheduling module. | delivered locally or forwarded to the packet scheduling module. | |||
2.2 ROUTING MODULE | 2.2 ROUTING MODULE | |||
The routing module dynamically tracks changes in ad hoc network | The routing module dynamically tracks changes in ad hoc network | |||
topology making the routing table visible (via APIs) to all | topology making the routing table visible (via APIs) to all | |||
intermediate packet forwarding module (e.g., INSIGNIA, packet | intermediate packet forwarding module (e.g., INSIGNIA, packet | |||
forwarding). Wireless flow management assumes the availability of | forwarding). Wireless flow management assumes the availability of | |||
MANET routing protocol [2] (e.g. Temporally Ordered Routing | MANET routing protocol [2] (e.g. Temporally Ordered Routing Algorithm | |||
Algorithm (TORA) [1], Dynamic Source Routing [7], Zone Routing | (TORA) [1], Dynamic Source Routing [7], Zone Routing Protocol [5], Ad | |||
Protocol [5], Ad Hoc On demand Distance Vector Routing Protocol | Hoc On demand Distance Vector Routing Protocol [6]). | |||
[6]). | ||||
2.3 INSIGNIA MODULE | 2.3 INSIGNIA MODULE | |||
The INSIGNIA module establishes, restores, adapts and tears down | The INSIGNIA module establishes, restores, adapts and tears down | |||
real-time flows. Flow restoration algorithms respond to dynamic | real-time flows. Flow restoration algorithms respond to dynamic route | |||
route changes due to mobility. Adaptation algorithms respond to | changes due to mobility. Adaptation algorithms respond to changes in | |||
changes in available bandwidth. Based on an in-band signaling | available bandwidth. Based on an in-band signaling approach that | |||
approach that explicitly carries control information in the IP | explicitly carries control information in the IP packet header, flows | |||
packet header, flows can be rapidly established, restored, adapted | can be rapidly established, restored, adapted and released in | |||
and released in response wireless impairments and topology changes. | response wireless impairments and topology changes. Because of this | |||
Because of this dynamic environment, network state management is | dynamic environment, network state management is based on soft-state | |||
based on soft-state [3], which is well suited to managing | [3], which is well suited to managing reservation flow-state in | |||
reservation flow-state in mobile ad hoc networks. | mobile ad hoc networks. | |||
2.4 ADMISSION CONTROL MODULE | 2.4 ADMISSION CONTROL MODULE | |||
The admission control module is responsible for allocating bandwidth | The admission control module is responsible for allocating bandwidth | |||
to flows based on the maximum/minimum bandwidth requested. Once | to flows based on the maximum/minimum bandwidth requested. Once | |||
resources have been allocated they are periodically refreshed by a | resources have been allocated they are periodically refreshed by a | |||
mobile soft-state mechanism through the reception of data packets. | mobile soft-state mechanism through the reception of data packets. | |||
Admission control testing is based on the measured channel | Admission control testing is based on the measured channel | |||
capacity/utilization and requested bandwidth. To keep the protocol | capacity/utilization and requested bandwidth. To keep the protocol | |||
simple and lightweight, new reservation requests do not affect | simple and lightweight, new reservation requests do not affect | |||
existing flow reservations. Rerouted or new flows may be degraded if | existing flow reservations. Rerouted or new flows may be degraded | |||
resources are unavailable. | ifresources are unavailable. | |||
2.5 PACKET SCHEDULING MODULE | 2.5 PACKET SCHEDULING MODULE | |||
The packet scheduling module responds to location dependent channel | The packet scheduling module responds to location dependent channel | |||
conditions experienced in wireless networks [22]. The scheduling | conditions experienced in wireless networks [22]. The scheduling | |||
mechanism is implementation and QOS model dependent. Currently, we | mechanism is implementation and QOS model dependent. Currently, we | |||
have implemented a simple Weighted Round-Robin (WRR) service | have implemented a simple Weighted Round-Robin (WRR) service | |||
discipline which takes location dependent channel conditions into | discipline which takes location dependent channel conditions into | |||
account. It should be noted that a wide variety of scheduling | account. It should be noted that a wide variety of scheduling | |||
disciplines can be used to realize the packet scheduling module. | disciplines can be used to realize the packet scheduling module. | |||
2.6 MEDIUM ACCESS CONTROLLER MODULE | 2.6 MEDIUM ACCESS CONTROLLER MODULE | |||
The medium access controller module (possibly) provides quality of | The medium access controller module (possibly) provides quality of | |||
service driven access to the shared wireless media for adaptive | service driven access to the shared wireless media for adaptive | |||
real-time services and best-effort services. The wireless flow | real-time services and best-effort services. The wireless flow | |||
management is designed to be transparent to any underlying media | management is designed to be transparent to any underlying media | |||
access control protocols. However, the performance of the MANET is | access control protocols. However, the performance of the MANET is | |||
strongly coupled to the provisioning of QOS support at the MAC | strongly coupled to the provisioning of QOS support at the MAC layer. | |||
layer. Nevertheless, our approach is to investigate the performance | Nevertheless, our approach is to investigate the performance of | |||
of INSIGNIA using both non QOS-capable and QOS-capable MACs. | INSIGNIA using both non QOS-capable and QOS-capable MACs. | |||
3. INSIGNIA PROTOCOL | 3. INSIGNIA PROTOCOL | |||
Mobile ad hoc signaling systems should be lightweight in terms of | Mobile ad hoc signaling systems should be lightweight in terms of the | |||
the amount of bandwidth they consume and be capable of reacting to | amount of bandwidth they consume and be capable of reacting to fast | |||
fast network dynamics close to call/session and packet transmission | network dynamics close to call/session and packet transmission time | |||
time scales. Future signaling systems should be highly responsive to | scales. Future signaling systems should be highly responsive to flow | |||
flow re-routing and be capable of re-establishing active | re-routing and be capable of re-establishing active reservations | |||
reservations along the new path with minimum disruption to on-going | along the new path with minimum disruption to on-going services. | |||
services. | ||||
In-band signaling systems are capable of operating close to packet | In-band signaling systems are capable of operating close to packet | |||
transmission time scales and are therefore well suited toward | transmission time scales and are therefore well suited toward | |||
managing fast time-scale dynamics found in mobile ad hoc | managing fast time-scale dynamics found in mobile ad hoc | |||
environments. In contrast, out-of-band signaling systems (e.g. | environments. In contrast, out-of-band signaling systems (e.g. | |||
Internet's RSVP, ATM's UNI, etc.) are incapable of responding to | Internet's RSVP, ATM's UNI, etc.) are incapable of responding to such | |||
such fast time-scale dynamics. Based on an in-band approach, | fast time-scale dynamics. Based on an in-band approach, INSIGNIA is | |||
INSIGNIA is designed to restore 'flow-state' (i.e., a reservation) | designed to restore 'flow-state' (i.e., a reservation) in response to | |||
in response to topology changes within the interval of two | topology changes within the interval of two consecutive IP packets | |||
consecutive IP packets under ideal conditions. | under ideal conditions. | |||
3.1 IP OPTIONS | 3.1 IP OPTIONS | |||
To establish an adaptive real-time flows, INSIGNIA uses a new IP | To establish an adaptive real-time flows, INSIGNIA uses a new IP | |||
option to setup, restore and adapt resources between source- | option to setup, restore and adapt resources between source- | |||
destination pairs. When intermediate nodes receive packets with the | destination pairs. When intermediate nodes receive packets with the | |||
these IP options set they attempt to reserve, restore or adapt | these IP options set they attempt to reserve, restore or adapt | |||
resources forwarding date packets toward the destination. | resources forwarding date packets toward the destination. | |||
By coding control information in the INSIGNIA IP option (in each IP | By coding control information in the INSIGNIA IP option (in each IP | |||
header), we support the notion of in-band control which we believe | header), we support the notion of in-band control which we believe is | |||
is called for to support QOS in ad-hoc mobile networks. The INSIGNIA | called for to support QOS in ad-hoc mobile networks. The INSIGNIA IP | |||
IP option supports flow reservation, restoration and adaptation | option supports flow reservation, restoration and adaptation control. | |||
control. Best effort and adaptive real-time services are supported | Best effort and adaptive real-time services are supported by INSIGNIA | |||
by INSIGNIA and are indicated by the reservation mode and service | and are indicated by the reservation mode and service type fields in | |||
type fields in the IP options as illustrated in Figure 2. Flows are | the IP options as illustrated in Figure 2. Flows are represented as | |||
represented as having a discrete base layer (BL) with a minimum | having a discrete base layer (BL) with a minimum bandwidth and an | |||
bandwidth and an enhancement layer, which requires the maximum | enhancement layer, which requires the maximum bandwidth. This | |||
bandwidth. This characterization is commonly used for multi- | characterization is commonly used for multi-resolution traffic (e.g., | |||
resolution traffic (e.g., MPEG audio and video) and more generally | MPEG audio and video) and more generally for real-time data that has | |||
for real-time data that has discrete max-min requirements. | 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 | 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 | | |Version| IHL |Type of Service| Total Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Time to Live | Protocol | Header Checksum | | | Time to Live | Protocol | Header Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Source Address | | | Source Address | | |||
skipping to change at page 9, line 36 | skipping to change at page 9, line 32 | |||
| Destination Address | | | Destination Address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Options (Used for INSIGNIA IP Options) | Padding | | | Options (Used for INSIGNIA IP Options) | Padding | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2a. IP Header | Figure 2a. IP Header | |||
reservation payload bandwidth request | reservation payload bandwidth request | |||
mode indicator | mode indicator | |||
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 2 3 4 5 6 7 8 9 | |||
+-------+-----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-------+-----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|REQ/RES|RT/BE|BL/EL|max/min| max_bandwidth | min_bandwidth | | |REQ/RES|AS/BE|BL/EL|max/min| max_bandwidth | min_bandwidth | | |||
+-------+-----+-----+-------+---------------+---------------+ | +-------+-----+-----+-------+---------------+---------------+ | |||
service bandwidth | service bandwidth | |||
type indicator | type indicator | |||
|<----->|<--->|<--->|<----->|<----------------------------->| | |<----->|<--->|<--->|<----->|<----------------------------->| | |||
1 bit 1 bit 1 bit 1 bit 16 bits | 1 bit 1 bit 1 bit 1 bit 16 bits | |||
Figure 2b. INSIGNIA IP Options | Figure 2b. INSIGNIA IP Options | |||
3.2 RERSERVATION MODE | 3.2 RERSERVATION MODE | |||
To establish an adaptive real-time flow, a source node sets the | 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 | request (REQ) bit in the IP option of a data packet to initiate a | |||
reservation request. On reception of a REQ packet, the intermediate | reservation request. On reception of a REQ packet, the intermediate | |||
nodes execute admission control and accept or deny the request. If | nodes execute admission control and accept or deny the request. If | |||
the request is accepted, resources are committed and subsequent | the request is accepted, resources are committed and subsequent | |||
packets are scheduled accordingly. Otherwise, packets are treated as | packets are scheduled accordingly. Otherwise, packets are treated as | |||
best effort packets if resources are unavailable. | best effort packets if resources are unavailable. | |||
Packets that are received by nodes with their reservation mode set | Packets that are received by nodes with their reservation mode set to | |||
to reserved (RES) indicate that the session has previously passed | reserved (RES) indicate that the session has previously passed | |||
admission control and resources have been reserved. In the case | admission control and resources have been reserved. In the case where | |||
where a RES packet is received and no resources have been allocated | a RES packet is received and no resources have been allocated the | |||
the admission controller immediately attempts to make a reservation. | admission controller immediately attempts to make a reservation. This | |||
This condition commonly occurs when reserved flows are rerouted | condition commonly occurs when reserved flows are rerouted during the | |||
during the lifetime of an active session due to mobility of sources, | lifetime of an active session due to mobility of sources, | |||
intermediate router nodes or destinations. | intermediate router nodes or destinations. | |||
3.3 SERVICE TYPE | 3.3 SERVICE TYPE | |||
The interpretation of the service type, which indicates either a | The interpretation of the service type, which indicates either a | |||
real-time (RT) or best-effort (BE) packet, is dependent on the | adaptice service (AS) or best-effort (BE) packet, is dependent on the | |||
reservation mode. A packet with the reservation mode set to REQ and | 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 | service type to AS is attempting to setup a real-time flow with the | |||
bandwidth requirements of the flow specified in the bandwidth | bandwidth requirements of the flow specified in the bandwidth request | |||
request field. A packet with RES/RT set indicates that an end-to-end | field. A packet with RES/AS set indicates that an end-to-end | |||
reservation has previously been established. A RES/RT packet service | reservation has previously been established. A RES/AS packet service | |||
may be degraded to RES/BE service if the flow is rerouted along a | may be degraded to RES/BE service if the flow is rerouted along a new | |||
new path when insufficient resources were available on the new path. | path when insufficient resources were available on the new path. | |||
A best effort packet sets the reservation mode to REQ as default and | 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 | the service type to BE requiring no resource reservation to be made | |||
in the network. Reception of a RES/BE by a destination node | in the network. Reception of a RES/BE by a destination node indicates | |||
indicates an active adaptive real-time flow was degraded to BE due | an active adaptive real-time flow was degraded to BE due to | |||
to insufficient resource availability after rerouting to a new path. | insufficient resource availability after rerouting to a new path. | |||
3.4 PAYLOAD INDICATOR | 3.4 PAYLOAD INDICATOR | |||
The payload field indicates the type of packet being transported. | The payload field indicates the type of packet being transported. | |||
INSIGNIA supports two types of payload, i.e., base (BL) and | INSIGNIA supports two types of payload, i.e., base (BL) and | |||
enhancement layers (EL). The semantics of the adaptive real-time | enhancement layers (EL). The semantics of the adaptive real-time | |||
services are related to the payload type and resource availability. | services are related to the payload type and resource availability. | |||
Base and enhancement layers can be assured via distributed end-to- | Base and enhancement layers can be assured via distributed end-to-end | |||
end admission control and resource reservation. Maximum bandwidth | admission control and resource reservation. Maximum bandwidth | |||
reservation is required to support both base and enhancement layers | reservation is required to support both base and enhancement layers | |||
of a flow whereas only minimum bandwidth reservation is required to | of a flow whereas only minimum bandwidth reservation is required to | |||
support the base layer. When a flow with minimum reservation | support the base layer. When a flow with minimum reservation receives | |||
receives a EL packet in reserved mode (RES/RT) set, it indicates | a EL packet in reserved mode (RES/AS) set, it indicates either the | |||
either the reservations for EL has been restored at the bottleneck | reservations for EL has been restored at the bottleneck node or an | |||
node or an adaptation (scale-up) has been occurred. | adaptation (scale-up) has been occurred. | |||
3.5 BANDWIDTH INDICATOR | 3.5 BANDWIDTH INDICATOR | |||
The bandwidth indicator represents the potential resource | The bandwidth indicator represents the potential resource | |||
availability for a flow/session along its current path between a | availability for a flow/session along its current path between a | |||
source and destination pair. In this respect the bandwidth indicator | source and destination pair. In this respect the bandwidth indicator | |||
represents the prospective resource availability to an application | represents the prospective resource availability to an application | |||
which will change over time. This does not, however, represent an | which will change over time. This does not, however, represent an | |||
actual resource reservation but the potential for one to succeed | actual resource reservation but the potential for one to succeed give | |||
give the current indication. The bandwidth indicator is carried in | the current indication. The bandwidth indicator is carried in each | |||
each packet and can be therefore viewed as a dynamic state variable | packet and can be therefore viewed as a dynamic state variable that | |||
that can be updated by any mobile host on the current path. Based on | can be updated by any mobile host on the current path. Based on its | |||
its value it represents a good bandwidth hint that resources are | value it represents a good bandwidth hint that resources are | |||
available along the current path to meet the flows minimum or | available along the current path to meet the flows minimum or maximum | |||
maximum needs. In this capacity the bandwidth indicator plays an | needs. In this capacity the bandwidth indicator plays an important | |||
important role during the flow setup phase and, more importantly, | role during the flow setup phase and, more importantly, during the | |||
during the adaptation phase. | adaptation phase. | |||
During flow setup the bandwidth indicator represents the resource | During flow setup the bandwidth indicator represents the resource | |||
availability along the chosen setup route. Reception of setup | availability along the chosen setup route. Reception of setup request | |||
request packets with the bandwidth indicator bit set to MAX | packets with the bandwidth indicator bit set to MAX indicates that | |||
indicates that all nodes en-route have sufficient resources to | all nodes en-route have sufficient resources to support the maximum | |||
support the maximum bandwidth requested. In contrast, a packet with | bandwidth requested. In contrast, a packet with the bandwidth | |||
the bandwidth indicator set to MIN implies that at least one of the | indicator set to MIN implies that at least one of the intermediate | |||
intermediate nodes (known as the bottlenecked mobile host) between | nodes (known as the bottlenecked mobile host) between the source and | |||
the source and destination has insufficient bandwidth resources to | destination has insufficient bandwidth resources to meet the maximum | |||
meet the maximum needs (if specified); however, reception of a | needs (if specified); however, reception of a packet with the | |||
packet with the bandwidth indicator set to MIN does indicate that | bandwidth indicator set to MIN does indicate that all nodes can | |||
all nodes can support the minimum bandwidth requirement. In this | support the minimum bandwidth requirement. In this case, only the | |||
case, only the base layer reservation is acknowledged as having | base layer reservation is acknowledged as having been successful | |||
been successful established via QOS reporting (see Section 4.2). QOS | established via QOS reporting (see Section 4.2). QOS reporting | |||
reporting between the destination and source can be used to force | between the destination and source can be used to force the source to | |||
the source to 'drop' enhancement layers. In this case the source | 'drop' enhancement layers. In this case the source would only forward | |||
would only forward the BL packets toward the destination in reserved | the BL packets toward the destination in reserved mode. Any | |||
mode. Any enhancement layer packets would be forwarded as best- | enhancement layer packets would be forwarded as best-effort packets. | |||
effort packets. This action has the benefit of releasing an 'partial | This action has the benefit of releasing an 'partial reservations' | |||
reservations' for the enhancement layer that may exist between a | for the enhancement layer that may exist between a bottlenecked | |||
bottlenecked mobile host and the destination. We will discuss the | mobile host and the destination. We will discuss the issue of | |||
issue of 'partial reservations' (which may occur in all phases of | 'partial reservations' (which may occur in all phases of INSIGNIA | |||
INSIGNIA operation)in the sections of flow setup, restoration and | operation)in the sections of flow setup, restoration and adaptation. | |||
adaptation. | ||||
The bandwidth indicator is also utilized for restoring the | The bandwidth indicator is also utilized for restoring the | |||
reservation for EL if previously degraded to best effort service. | reservation for EL if previously degraded to best effort service. In | |||
In order to accomplish scaling up adaptation, the adaptation | order to accomplish scaling up adaptation, the adaptation handler | |||
handler resident at destination should monitors a flow's resource | resident at destination should monitors a flow's resource | |||
availability (by monitoring the bandwidth indicator) | availability (by monitoring the bandwidth indicator) and, based on | |||
and, based on the adaptation policy, initiate a 'scale up' operation | the adaptation policy, initiate a 'scale up' operation using a QOS | |||
using a QOS report. | report. | |||
3.6 BANDWIDTH REQUEST | 3.6 BANDWIDTH REQUEST | |||
The bandwidth request allows a source to specify its maximum (MAX) | The bandwidth request allows a source to specify its maximum (MAX) | |||
and minimum (MIN) bandwidth requirements for adaptive real-time | and minimum (MIN) bandwidth requirements for adaptive real-time | |||
service support. This assumes that the source has selected the RT | service support. This assumes that the source has selected the AS | |||
service type. A source may also simply specify a minimum or a | service type. A source may also simply specify a minimum or a maximum | |||
maximum bandwidth requirement. For adaptive real-time services the | bandwidth requirement. For adaptive real-time services the base layer | |||
base layer is supported by the MIN bandwidth whereas the MAX | is supported by the MIN bandwidth whereas the MAX bandwidth supports | |||
bandwidth supports the delivery of the base and enhancement layers | the delivery of the base and enhancement layers between a source and | |||
between a source and destination pair. | destination pair. | |||
4. INSIGNIA OPERATIONS | 4. INSIGNIA OPERATIONS | |||
The IP option and operations support the delivery of adaptive real- | The IP option and operations support the delivery of adaptive real- | |||
time services to mobile hosts. These operations collectively define | time services to mobile hosts. These operations collectively define | |||
the foundation of the INSIGNIA system and include flow setup, flow | the foundation of the INSIGNIA system and include flow setup, flow | |||
restoration, soft-state management, adaptation and QOS reporting. | restoration, soft-state management, adaptation and QOS reporting. | |||
Once a flow has been established between a source-destination pair, | Once a flow has been established between a source-destination pair, | |||
QOS reports are used to inform the source of the progress of the | QOS reports are used to inform the source of the progress of the | |||
delivered packet quality at the destination. Node mobility may | delivered packet quality at the destination. Node mobility may | |||
trigger topology changes. In this case the MANET routing protocol | trigger topology changes. In this case the MANET routing protocol may | |||
may provide alternative or new path information to destination, | provide alternative or new path information to destination, in which | |||
in which case, INSIGNIA would attempt to restore reservations at all | case, INSIGNIA would attempt to restore reservations at all nodes on | |||
nodes on the new path through the restoration operation. Moreover, | the new path through the restoration operation. Moreover, adaptation | |||
adaptation may be triggered to adjust a flow to match resources | may be triggered to adjust a flow to match resources availability | |||
availability found on the new path. Managing the network state, | found on the new path. Managing the network state,while responding to | |||
while responding to these network dynamics, is handled by a soft- | these network dynamics, is handleby a soft-state management mechanism | |||
state management mechanism in INSIGNIA. In the following sections, | in INSIGNIA. In the following sections,each of the INSIGNIA | |||
each of the INSIGNIA operations are outlined. | operations are outlined. | |||
4.1 FLOW SETUP | 4.1 FLOW SETUP | |||
To establish adaptive real-time flows, source nodes set the | To establish adaptive real-time flows, source nodes set the | |||
appropriate fields in the IP option before forwarding 'reservation | appropriate fields in the IP option before forwarding 'reservation | |||
request' packets toward destination mobile hosts. A reservation | request' packets toward destination mobile hosts. A reservation | |||
request packet is characterized as having its reservation mode set | request packet is characterized as having its reservation mode set to | |||
to REQ, service type set to RT, a valid payload (viz. BL or EL) and | REQ, service type set to AS, a valid payload (viz. BL or EL) and a | |||
a MAX/MIN bandwidth requirement. | MAX/MIN bandwidth requirement. | |||
Reservation packets traverse intermediate nodes executing admission | Reservation packets traverse intermediate nodes executing admission | |||
control modules, allocating resources and establishing flow-state at | control modules, allocating resources and establishing flow-state at | |||
all nodes between source-destination pairs. If any intermediate | all nodes between source-destination pairs. If any intermediate | |||
mobile node lacks resources to support the requested flow setup, the | mobile node lacks resources to support the requested flow setup, the | |||
appropriate IP option field is changed to indicate this condition | appropriate IP option field is changed to indicate this condition (or | |||
(or state). | state). | |||
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 2 3 4 5 6 7 8 9 | |||
+---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|REQ| RT |BL/EL|max/min| max_bandwidth | min_bandwidth | | |REQ| AS |BL/EL|max/min| max_bandwidth | min_bandwidth | | |||
+---+----+-----+-------+---------------+---------------+ | +---+----+-----+-------+---------------+---------------+ | |||
Figure 3. INSIGNIA Packet Requesting MAX/MIN reservation | Figure 3. INSIGNIA Packet Requesting MAX/MIN reservation | |||
If an intermediate mobile receives a request packet and can only | If an intermediate mobile receives a request packet and can only | |||
support the minimum requirement then the flow request is degraded to | support the minimum requirement then the flow request is degraded to | |||
the minimum request at the bottleneck mobile node by resetting the | the minimum request at the bottleneck mobile node by resetting the | |||
bandwidth indicator to MIN. Meanwhile the source continues to send | bandwidth indicator to MIN. Meanwhile the source continues to send | |||
reservation requests packets until the destination informs it of the | reservation requests packets until the destination informs it of the | |||
status of flow establishment phase via QOS report (discussed in | status of flow establishment phase via QOS report (discussed in | |||
Section 4.2). Subsequent reservation request packets do not execute | Section 4.2). Subsequent reservation request packets do not execute | |||
admission control but simply refresh existing soft-state | admission control but simply refresh existing soft-state reservation. | |||
reservation. | ||||
The establishment of an adaptive real-time flow is illustrated in | The establishment of an adaptive real-time flow is illustrated in | |||
Figure 4. A source mobile host (M1) issues a flow setup by | Figure 4. A source mobile host (M1) issues a flow setup by requesting | |||
requesting resource reservation. M2 performs admission control upon | resource reservation. M2 performs admission control upon reception of | |||
reception of the request packet. Resources are allocated if | the request packet. Resources are allocated if available and the | |||
available and the request packet is forwarded to the next mobile | request packet is forwarded to the next mobile (M3). This process is | |||
(M3). This process is repeated hop by hop until the request packet | repeated hop by hop until the request packet reaches the destination | |||
reaches the destination mobile host (M6). The destination mobile | mobile host (M6). The destination mobile node determines the resource | |||
node determines the resource allocation status by checking the | allocation status by checking the service type and current level of | |||
service type and current level of service. | service. | |||
When a reservation request is received at the destination node, the | When a reservation request is received at the destination node, the | |||
INSIGNIA module checks the reservation status. The status of the | INSIGNIA module checks the reservation status. The status of the flow | |||
flow setup is determined by inspecting the bandwidth indication | setup is determined by inspecting the bandwidth indication field. If | |||
field. If the bandwidth indicator is set to MAX then this implies | the bandwidth indicator is set to MAX then this implies that all | |||
that all mobile hosts between the source destination have | mobile hosts between the source destination have successfully | |||
successfully allocated resources to meet the base and enhancement | allocated resources to meet the base and enhancement layers bandwidth | |||
layers bandwidth requirements. On the other hand, a bandwidth | requirements. On the other hand, a bandwidth indication set to MIN | |||
indication set to MIN indicates that only the base layer can be | indicates that only the base layer can be currently supported. In | |||
currently supported. In this case, all reserved packets with a | this case, all reserved packets with a payload of EL received at the | |||
payload of EL received at the destination have their service level | destination have their service level flipped from AS to BE by the | |||
flipped from RT to BE by the bottleneck node. In such case, a | bottleneck node. In such case, a partial reservation may exist | |||
partial reservation may exist between the source and bottleneck | between the source and bottleneck mobile node. This partial | |||
mobile node. This partial reservation can be viewed as a waste of | reservation can be viewed as a waste of resources between the source | |||
resources between the source and bottlenecked node (since they go | and bottlenecked node (since they go unused) or, as a 'near | |||
unused) or, as a 'near reservation' where all but the remaining | reservation' where all but the remaining nodes (between the | |||
nodes (between the bottlenecked node and the destination) hold | bottlenecked node and the destination) hold reservations. Holding on | |||
reservations. Holding on to these reservations - in effect locking | to these reservations - in effect locking them in - is a 'hedge' | |||
them in - is a 'hedge' against completing the setup phase in the | against completing the setup phase in the near future. The treatment | |||
near future. The treatment of 'partial reservations' is still under | of 'partial reservations' is still under consideration. Currently, | |||
consideration. Currently, the adaptation process allows the mobile | the adaptation process allows the mobile host to clear partial | |||
host to clear partial reservations using the adaptation process or | reservations using the adaptation process or leave them in place. | |||
leave them in place. | ||||
+----+ +----+ | +----+ +----+ | |||
QOS_REPORT(2)| M9 |---| M8 |\QOS_REPORT(2) | QOS_REPORT(2)| M9 |---| M8 |\QOS_REPORT(2) | |||
+----+ /+----+ +----+ \ +----+ | +----+ /+----+ +----+ \ +----+ | |||
| M2 |/ / \| M7 |\QOS_REPORT(2) | | M2 |/ / \| M7 |\QOS_REPORT(2) | |||
REQ(1)/+----+\ / +----+ \+----+ | REQ(1)/+----+\ / +----+ \+----+ | |||
+----+/ \ +----+/ +----+ | M6 | | +----+/ \ +----+/ +----+ | M6 | | |||
| M1 | REQ(1)\| M3 |---| M4 |REQ(1) /+----+ | | M1 | REQ(1)\| M3 |---| M4 |REQ(1) /+----+ | |||
+----+ +----+ +----+\ +----+/ | +----+ +----+ +----+\ +----+/ | |||
REQ(1) \| M5 | REQ(1) | REQ(1) \| M5 | REQ(1) | |||
+----+ | +----+ | |||
Figure 4. INSIGNIA Request Packet and QOS report | Figure 4. INSIGNIA Request Packet and QOS report | |||
4.2 QOS REPORTING | 4.2 QOS REPORTING | |||
QOS reports are used to inform the source of the status of received | QOS reports are used to inform the source of the status of received adaptive | |||
adaptive real-time flows. Destination nodes actively monitor on- | real-time flows. Destination nodes actively monitor on-going flows inspecting | |||
going flows inspecting status information (e.g., bandwidth | status information (e.g., bandwidth indication) and calculating QOS statistics | |||
indication) and calculating QOS statistics (viz. packet loss, delay, | (viz. packet loss, delay, out-of-sequence delivery and throughput). QOS | |||
out-of-sequence delivery and throughput). QOS reports are | reports are periodically sent to source host for the purpose of completing | |||
periodically sent to source host for the purpose of completing flow | flow establishment and managing adaptations. QOS reporting is application | |||
establishment and managing adaptations. QOS reporting is application | dependent where the periodicity of reports is determined by the application's | |||
dependent where the periodicity of reports is determined by the | sensitivity to the delivered QOS. Note that QOS reports do not have to travel | |||
application's sensitivity to the delivered QOS. Note that QOS | on the reverse path toward the source. Typically they will take an alternate | |||
reports do not have to travel on the reverse path toward the source. | route through the ad hoc network as illustrated in Figure 4. | |||
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 | In the case of flow establishment, reception of a reservation request packet | |||
request packet with the bandwidth indicator set to MAX (or MIN) | with the bandwidth indicator set to MAX (or MIN) indicates that the source's | |||
indicates that the source's maximum (minimum) reservation has been | maximum (minimum) reservation has been successfully made en-route. The | |||
successfully made en-route. The destination informs the source of | destination informs the source of this reservation status by setting the | |||
this reservation status by setting the bandwidth indicator field | bandwidth indicator field with MAX (MIN) in the QOS report, accordingly. The | |||
with MAX (MIN) in the QOS report, accordingly. The QOS report is a | QOS report is a best effort data packet with a payload that comprises of 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. | adaptation commands and measured QOS information. | |||
QOS reports are also used as part of on-going adaptation process | QOS reports are also used as part of on-going adaptation process that responds | |||
that responds to mobility and resources changes in the mobile ad hoc | to mobility and resources changes in the mobile ad hoc network. Periodic QOS | |||
network. Periodic QOS reports can be used to inform the source to | reports can be used to inform the source to 'drop' (e.g., drop all EL packets) | |||
'drop' (e.g., drop all EL packets) or 'scale-up' (i.e., transmit EL | or 'scale-up' (i.e., transmit EL packets) based on available resources and the | |||
packets) based on available resources and the adaptation policy of | adaptation policy of the application. These are the 'adaptation commands'. | |||
the application. These are the 'adaptation commands'. | ||||
4.2.1 QOS REPORT INTERVAL | 4.2.1 QOS REPORT INTERVAL | |||
Since each flow has different sensitivity to QOS, the periodicity of | Since each flow has different sensitivity to QOS, the periodicity of QOS | |||
QOS report for each flow should reflect this sensitivity. A flow | report for each flow should reflect this sensitivity. A flow that is sensitive | |||
that is sensitive to service quality requires more frequent QOS | to service quality requires more frequent QOS report than one that is less | |||
report than one that is less sensitive (i.e., more QOS control). A | sensitive (i.e., more QOS control). A source relates the sensitivity of a flow | |||
source relates the sensitivity of a flow via setting the TTL value | via setting the TTL value with relatively small value. The destination | |||
with relatively small value. The destination utilizes the TTL value, | utilizes the TTL value, requested bandwidth and the adaptation policy to | |||
requested bandwidth and the adaptation policy to determine the | determine the flow's sensitivity to service quality. We are currently | |||
flow's sensitivity to service quality. We are currently | investigating the migration of this function to the INSIGNIA IP options field. | |||
investigating the migration of this function to the INSIGNIA IP | ||||
options field. | ||||
4.2.2 QOS PACKET FORMAT | 4.2.2 QOS PACKET FORMAT | |||
The role of the QOS report is to serve as a simple notification of | The role of the QOS report is to serve as a simple notification of the | |||
the satisfaction level perceived by the destination. The QOS report | satisfaction level perceived by the destination. The QOS report includes a | |||
includes a 'mirror copy' of the INSIGNIA IP option, adaptation | QOS. In fact, the QOS report of INSIGNIA has the same format as a best effort | |||
commands and measured QOS. In fact, the QOS report of INSIGNIA has | INSIGNIA data packet. A QOS report has the reservation mode set to RES and | |||
the same format as a best effort INSIGNIA data packet. A QOS report | service type set to BE. The minimum bandwidth field is set to zeros and | |||
has the reservation mode set to RES and service type set to BE. The | maximum bandwidth is set to ones. By doing so, the QOS report can be | |||
minimum bandwidth field is set to zeros and maximum bandwidth is set | distinguished from the degraded RES packet. The various packet formats are | |||
to ones. By doing so, the QOS report can be distinguished from the | illustrated in Figure 8. | |||
degraded RES packet. The various packet formats are illustrated in | ||||
Figure 8. | ||||
4.2.3 QOS REPORT DELIVERY | 4.2.3 QOS REPORT DELIVERY | |||
QOS reports should be delivered in a timely fashion. We propose to | QOS reports should be delivered in a timely fashion. We propose to schedule | |||
schedule QOS reports before the transmission of best effort packets | QOS reports before the transmission of best effort packets but without | |||
but without affecting the performance of reserved flows. The IP | affecting the performance of reserved flows. The IP option codepoint for QOS | |||
option codepoint for QOS reports, even though best effort in | reports, even though best effort in service type, set it a side from all | |||
service type, set it a side from all other best effort traffic for a | other best effort traffic for a 'better than best effort treatment' at | |||
'better than best effort treatment' at intermediate nodes. | intermediate nodes. | |||
4.3 SOFT-STATE MANAGEMENT | 4.3 SOFT-STATE MANAGEMENT | |||
Maintaining the quality of service of real time flows in mobile ad | Maintaining the quality of service of real time flows in mobile ad hoc network | |||
hoc network is one of the most challenging aspects that INSIGNIA | is one of the most challenging aspects that INSIGNIA addresses. Typically, | |||
addresses. Typically, wireline networks requires little QOS or | wireline networks requires little QOS or state management where the routes and | |||
state management where the routes and the reservations remain fixed | the reservations remain fixed for the duration of the session/flows. This | |||
for the duration of the session/flows. This style of 'hard-state' | style of 'hard-state' connection oriented communications guarantees quality of | |||
connection oriented communications guarantees quality of service for | service for the duration of the holding time. However, these techniques are | |||
the duration of the holding time. However, these techniques are not | not applicable/valid in mobile ad hoc networks where paths and reservations | |||
applicable/valid in mobile ad hoc networks where paths and | need to dynamically respond to topology changes in a timely manner over | |||
reservations need to dynamically respond to topology changes in a | multiple time scales and network dynamics. | |||
timely manner over multiple time scales and network dynamics. | ||||
Based on the work by Clark [3], 'mobile soft-state' relies on the | Based on the work by Clark [3], 'mobile soft-state' relies on the fact that | |||
fact that sources periodically send data messages along the existing | sources periodically send data messages along the existing path. If a data | |||
path. If a data packet arrives at a mobile router and no reservation | packet arrives at a mobile router and no reservation exists then admission | |||
exists then admission control and resource reservations are needed | control and resource reservations are needed to establish soft-state | |||
to establish soft-state reservations. Subsequent reception of a data | reservations. Subsequent reception of a data packet at a router is used to | |||
packet at a router is used to refresh the soft-state reservation. | refresh the soft-state reservation. Thus a mobile host receiving a data packet | |||
Thus a mobile host receiving a data packet for an existing | for an existing reservation reconfirms the reservation over the next time | |||
reservation reconfirms the reservation over the next time interval. | interval. The holding-time for a reservation is based on a soft-state timer | |||
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 | |||
interval and not, as in the case of call setup, based on the session | holding time. If a new packet is not received within a soft-state timer | |||
duration holding time. If a new packet is not received within a | interval, resources are released and flow-states removed automatically without | |||
soft-state timer interval, resources are released and flow-states | any explicit tear-down messaging. | |||
removed automatically without any explicit tear-down messaging. | ||||
The soft-state approach is well suited for management of resources | The soft-state approach is well suited for management of resources in dynamic | |||
in dynamic environment where the path and reservation associated | environment where the path and reservation associated with a flow may change | |||
with a flow may change rapidly. The transmission of data packets is | rapidly. The transmission of data packets is strongly coupled to maintenance | |||
strongly coupled to maintenance of flow-states, i.e., reservations. | of flow-states, i.e., reservations. As the route changes in the network, new | |||
As the route changes in the network, new reservations will be | reservations will be automatically restored by the restoration mechanism | |||
automatically restored by the restoration mechanism provided that | provided that resources are available along the new path. | |||
resources are available along the new path. | ||||
Another benefit of mobile soft-state is that resources allocated | Another benefit of mobile soft-state is that resources allocated during flow | |||
during flow establishment are automatically removed when the path | establishment are automatically removed when the path changes without any | |||
changes without any explicit signaling interactions. In-band | explicit signaling interactions. In-band approaches are flexible and scalable | |||
approaches are flexible and scalable in dealing with a number of | in dealing with a number of difficult mobile ad hoc network issues whereas | |||
difficult mobile ad hoc network issues whereas out-of-band signaling | out-of-band signaling systems need to maintain source route information and | |||
systems need to maintain source route information and respond to | respond to topology changes by directly signaling 'affected mobiles' to | |||
topology changes by directly signaling 'affected mobiles' to | allocate or free radio resources. In some case, this is impossible to do when | |||
allocate or free radio resources. In some case, this is impossible | using out-of-band signaling techniques if the 'affected router' is out of | |||
to do when using out-of-band signaling techniques if the 'affected | radio contact from the signaling entity that is attempting to de-allocate | |||
router' is out of radio contact from the signaling entity that is | resources over the old path. | |||
attempting to de-allocate resources over the old path. | ||||
4.4 FLOW RESTORATION | 4.4 FLOW RESTORATION | |||
Flows are often rerouted during the lifetime of sessions due to | Flows are often rerouted during the lifetime of sessions due to mobility in | |||
mobility in mobile ad hoc networks. The goal of flow restoration is | mobile ad hoc networks. The goal of flow restoration is to re-establish | |||
to re-establish reservation as fast and efficiently as possible. | reservation as fast and efficiently as possible. Rerouting of an active flow | |||
Rerouting of an active flow involves new admission control and | involves new admission control and resource reservations for nodes on the new | |||
resource reservations for nodes on the new path. Restoration | path. Restoration procedures also call for the removal of flow-state at nodes | |||
procedures also call for the removal of flow-state at nodes along | along the old path. In an ideal case, the restoration of flows can be | |||
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 | |||
accomplished within the duration of a few consecutive packets | in-band nature of INSIGNIA's control. | |||
because of the in-band nature of INSIGNIA's control. | ||||
When a mobile moves out of radio contact and loses connectivity, | When a mobile moves out of radio contact and loses connectivity, the | |||
the forwarding router mobile interacts with the routing module and | forwarding router mobile interacts with the routing module and forwards | |||
forwards subsequent packets via the new route. (Note that if the | subsequent packets via the new route. (Note that if the routing table does not | |||
routing table does not have an alternative route toward the | have an alternative route toward the destination then the performance of the | |||
destination then the performance of the restoration process is | restoration process is tightly coupled to the performance of the | |||
tightly coupled to the performance of the proactive/reactive MANET | proactive/reactive MANET routing protocol that is operational. This issue is | |||
routing protocol that is operational. This issue is for further | for further study. In [25], however, we implemented INSIGNIA in a mid size ad | |||
study. In [25], however, we implemented INSIGNIA in a mid size ad | hoc network using TORA [1] as the routing protocol and discuss performance | |||
hoc network using TORA [1] as the routing protocol and discuss | issues there). | |||
performance issues there). | ||||
The mobile hosts on a new path receive rerouted packets and inspect | The mobile hosts on a new path receive rerouted packets and inspect their flow | |||
their flow state tables. If a reservation does not exist for the | state tables. If a reservation does not exist for the rerouted flow then the | |||
rerouted flow then the INSIGNIA module invokes admission control and | INSIGNIA module invokes admission control and tries to allocate | |||
tries to allocate resources. Note that, if the reserved packets are | resources. Note that, if the reserved packets are routed back on to the | |||
routed back on to the existing path then the old states are likely | existing path then the old states are likely to be still valid; hence, the | |||
to be still valid; hence, the states and reservations are simply | states and reservations are simply refreshed, minimizing any service | |||
refreshed, minimizing any service disruption due to re-rerouting. | disruption due to re-rerouting. | |||
Network dynamics may also trigger rerouting with service | Network dynamics may also trigger rerouting with service degradation. When a | |||
degradation. When a reserved flow is rerouted to a node where | reserved flow is rerouted to a node where resources are unavailable, the flow | |||
resources are unavailable, the flow is degraded to best effort | is degraded to best effort service. Subsequent downstream nodes receiving | |||
service. Subsequent downstream nodes receiving these degraded | these degraded packets make no attempt to attempt to allocate resources or | |||
packets make no attempt to attempt to allocate resources or refresh | refresh existing soft-state associated with the flow. This results in the | |||
existing soft-state associated with the flow. This results in the | automatic removal of any reservation state. In time the reservation may be | |||
automatic removal of any reservation state. In time the reservation | restored if resources free up at the bottleneck mobile node or because of the | |||
may be restored if resources free up at the bottleneck mobile node | subsequent rerouting allowing the complete restoration of the flow | |||
or because of the subsequent rerouting allowing the complete | quality. The worst case scenario is that the flow will remain degraded for the | |||
restoration of the flow quality. The worst case scenario is that the | duration of the session holding time. | |||
flow will remain degraded for the duration of the session holding | ||||
time. | ||||
The enhancement layer of a reserved flow with maximum reservation | The enhancement layer of a reserved flow with maximum reservation may get | |||
may get degraded during flow restoration if the nodes along the new | degraded during flow restoration if the nodes along the new path can only | |||
path can only support the minimum bandwidth requirement. If the | support the minimum bandwidth requirement. If the degradation of enhancement | |||
degradation of enhancement layer packets persist, it may cause | layer packets persist, it may cause service disruptions and may trigger the | |||
service disruptions and may trigger the destination mobile to invoke | destination mobile to invoke an adaptation procedure that force the source | |||
an adaptation procedure that force the source node to drop the EL | node to drop the EL packets. Adaptation details are provided in the following | |||
packets. Adaptation details are provided in the following section. | section. | |||
4.5 ADAPTATION | 4.5 ADAPTATION | |||
Reception quality of a flow is monitored and based on an | Reception quality of a flow is monitored and based on an application-specific | |||
application-specific adaptation policy, actions may be taken to | adaptation policy, actions may be taken to adapt the flow to observed network | |||
adapt the flow to observed network conditions. Actions taken are | conditions. Actions taken are conditional on the adaptation-policy resident at | |||
conditional on the adaptation-policy resident at the destination | the destination node, e.g., adaptation policy may chose to maintain the | |||
node, e.g., adaptation policy may chose to maintain the service | service level under degraded conditions or scale-down flows to their base | |||
level under degraded conditions or scale-down flows to their base | layers in respond to degraded conditions. Other policy could scale-up flows | |||
layers in respond to degraded conditions. Other policy could scale- | whenever resources become available. The application is free to program its | |||
up flows whenever resources become available. The application is | own adaptation policy that is executed by INSIGNIA through interaction between | |||
free to program its own adaptation policy that is executed by | the destination and source nodes. Details about the adaptation policy API are | |||
INSIGNIA through interaction between the destination and | described in [19]. | |||
source nodes. Details about the adaptation policy API are described | ||||
in [19]. | ||||
The adaptation process includes the following adaptation actions: | The adaptation process includes the following adaptation actions: | |||
(1) 'EL degradation' is a network driven action that forwards the | (1) 'EL degradation' is a network driven action that forwards the | |||
EL packets as best effort packets due to lack of resources; | EL packets as best effort packets due to lack of resources; | |||
(2) 'Drop enhancement layer' is a destination mobile driven action | (2) 'Drop enhancement layer' is a destination mobile driven action | |||
which requests a source to drop its enhancement layers. This | which requests a source to drop its enhancement layers. This | |||
happens when the EL degradation persists beyond an acceptable | happens when the EL degradation persists beyond an acceptable | |||
period; and | period; and | |||
(3) 'Scale-up', which requests a source to send its base and/or | (3) 'Scale-up', which requests a source to send its base and/or | |||
enhancement layers in reserved mode. This event occurs when | enhancement layers in reserved mode. This event occurs when | |||
a flow has only minimum reservation and the destination | a flow has only minimum reservation and the destination | |||
learns (through the bandwidth indicator) that the route | learns (through the bandwidth indicator) that the route | |||
can accommodate the maximum resource requirement. | can accommodate the maximum resource requirement. | |||
The EL degradation is a network driven action whereas the others two | The EL degradation is a network driven action whereas the others two actions | |||
actions are driven by an adaptation handler resident at the | are driven by an adaptation handler resident at the destination mobile | |||
destination mobile host. Typically, the EL degradation can be | host. Typically, the EL degradation can be observed after rerouting of an | |||
observed after rerouting of an adaptive real-time flow. In such an | adaptive real-time flow. In such an event the EL packets are degraded and | |||
event the EL packets are degraded and forwarded as best effort | forwarded as best effort packets whereas BL packets are forwarded in reserved | |||
packets whereas BL packets are forwarded in reserved mode. Note that | mode. Note that preference is given to base layers over enhancement layers in | |||
preference is given to base layers over enhancement layers in the | the event that reserved packets have to be degraded to best effort. If the EL | |||
event that reserved packets have to be degraded to best effort. | degradation persists, a `drop` command may be issued by the adaptation handler | |||
at the destination mobile host according to the adaptation policy. The | ||||
If the EL degradation persists, a `drop` command may be issued by | decision to drop the EL packets is facilitated by monitoring the incoming | |||
the adaptation handler at the destination mobile host according to | packets. The destination mobile can readily detect the degraded RES packets by | |||
the adaptation policy. The decision to drop the EL packets is | reading the IP option fields (where the degraded packets have the format of | |||
facilitated by monitoring the incoming packets. The destination | Figure 5d). Figure 5 illustrates the different modes of INSIGNIA packets. | |||
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 | 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 | | |REQ| BE |BL/EL| max | max_bandwidth | min_bandwidth | | |||
+---+----+-----+-----+---------------+---------------+ | +---+----+-----+-----+---------------+---------------+ | |||
Figure 5a. A Best Effort Packet | 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 | 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 | | |REQ| AS |BL/EL| max | max_bandwidth | min_bandwidth | | |||
+---+----+-----+-----+---------------+---------------+ | +---+----+-----+-----+---------------+---------------+ | |||
Figure 5b. A Request Packet (EL or BL) | Figure 5b. A Request Packet (EL or BL) | |||
+---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT |BL/EL|max/min| max_bandwidth | min_bandwidth | | |RES| AS |BL/EL|max/min| max_bandwidth | min_bandwidth | | |||
+---+----+-----+-------+---------------+---------------+ | +---+----+-----+-------+---------------+---------------+ | |||
Figure 5c. Typical Reserved (RES) Packet (EL or BL) | Figure 5c. Typical Reserved (RES) Packet (EL or BL) | |||
+---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| BE |BL/EL| max | max_bandwidth | min_bandwidth | | |RES| BE |BL/EL| max | max_bandwidth | min_bandwidth | | |||
+---+----+-----+-----+---------------+---------------+ | +---+----+-----+-----+---------------+---------------+ | |||
Figure 5d. A Degraded RES Packet (EL or BL) | 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| | |RES| BE | BL |max/min|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0| | |||
+---+----+----+-------+---------------+---------------+ | +---+----+----+-------+---------------+---------------+ | |||
|<----------->| |<----- unique format --------->| | |<----------->| |<----- unique format --------->| | |||
a QOS report | a QOS report | |||
* max/min indicates the accepted service level | * max/min indicates the accepted service level | |||
Figure 5e. Format of a QOS report | Figure 5e. Format of a QOS report | |||
'Dropping' the EL packet at the source removes partial reservations | exist between a source and bottleneck mobile freeing up resources for other | |||
that may exist between a source and bottleneck mobile freeing up | adaptive real-time flows to utilize. It also removes degraded enhancement | |||
resources for other adaptive real-time flows to utilize. It also | layer packets from the network which in turn benefits the normal best effort | |||
removes degraded enhancement layer packets from the network which in | service flows. | |||
turn benefits the normal best effort service flows. | ||||
INSIGNIA is also equipped with capability to restore the reservation | INSIGNIA is also equipped with capability to restore the reservation needed | |||
needed for enhancement layers. This process takes advantage of | for enhancement layers.This process takes advantage of network and session | |||
network and session dynamics allowing existing sessions to take | dynamics allowing existing sessions to take advantages of resources released | |||
advantages of resources released due to re-routing (e.g., resources | due to re-routing (e.g., resources released along an old path) or session | |||
released along an old path) or session termination. These events may | termination. These events may allow other mobile nodes to take advantage of | |||
allow other mobile nodes to take advantage of released resources by | released resources by scaling up. The bandwidth indicator plays a key role in | |||
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. | bandwidth needs of the particular session/flow. | |||
Typically, the scale-up process is invoked when the destination | Typically, the scale-up process is invoked when the destination observes | |||
observes sufficient resource have become available along the | sufficient resource have become available along the existing path restore the | |||
existing path restore the reservation of an enhancement layer. The | reservation of an enhancement layer. The decision to scale up is determined by | |||
decision to scale up is determined by the adaptation policy. | the adaptation policy. | |||
The following example scenario shows an example of a set of | The following example scenario shows an example of a set of states (marked | |||
states (marked [1] through [7]) observed at the destination | [1] through [7]) observed at the destination illustrating a flow adaptation | |||
illustrating a flow adaptation scenario: | scenario: | |||
Adaptation Procedures : | Adaptation Procedures : | |||
[1] Incoming Packets at time t1 with maximum resource allocation | [1] Incoming Packets at time t1 with maximum resource allocation | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | max | max_bandwidth | min_bandwidth | | |RES| AS | BL | max | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | EL | 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 | [2] EL packets are degraded due to lack of resources at an | |||
intermediate mobile node at time t2 and now packet formats become | intermediate mobile node at time t2 and now packet formats become | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | min | max_bandwidth | min_bandwidth | | |RES| AS | BL | min | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| BE | EL | min | max_bandwidth | min_bandwidth | | |RES| BE | EL | min | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
* Note that EL packet is degraded to a best effort packet | * Note that EL packet is degraded to a best effort packet | |||
. | . | |||
. | . | |||
. | . | |||
[3] If the degraded EL packets are determined to be not useful for | [3] If the degraded EL packets are determined to be not useful for | |||
destination mobile host, an EL drop command is issued via QOS | destination mobile host, an EL drop command is issued via QOS | |||
report. Upon reception of the QOS report the source transmits only | report. Upon reception of the QOS report the source transmits only | |||
BL packets in reserved mode and do not transmit any EL packets. | BL packets in reserved mode and do not transmit any EL packets. | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | min | max_bandwidth | min_bandwidth | | |RES| AS | BL | min | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
* EL packets are not transmitted/received | * EL packets are not transmitted/received | |||
. | . | |||
. | . | |||
. | . | |||
[4] Constant resource availability is detected through the bandwidth | [4] Constant resource availability is detected through the bandwidth | |||
indicator at t4 where the received packets indicating the resource | indicator at t4 where the received packets indicating the resource | |||
availability have the following format. | availability have the following format. | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | max | max_bandwidth | min_bandwidth | | |RES| AS | BL | max | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
* Currently no EL packets are received. | * Currently no EL packets are received. | |||
* Destination learns from the bandwidth indicator bit (set to max) | * Destination learns from the bandwidth indicator bit (set to max) | |||
that the current route has the resources available to restore the | that the current route has the resources available to restore the | |||
EL packet flow. | EL packet flow. | |||
. | . | |||
. | . | |||
. | . | |||
[5] Through the next QOS report destination informs the source to | [5] Through the next QOS report destination informs the source to | |||
reinitiate the transmission on EL in RES mode. If the recovery | reinitiate the transmission on EL in RES mode. If the recovery | |||
(scale up) is successful, destination receives the following | (scale up) is successful, destination receives the following | |||
packets. | packets. | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | max | max_bandwidth | min_bandwidth | | |RES| AS | BL | max | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| BE | EL | 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, | [6] If scale up attempt fails at any mobile node on the route, | |||
destination receives degraded EL packets. | destination receives degraded EL packets. | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| RT | BL | min | max_bandwidth | min_bandwidth | | |RES| AS | BL | min | max_bandwidth | min_bandwidth | | |||
+---+----+----+-----+---------------+---------------+ | +---+----+----+-----+---------------+---------------+ | |||
+---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|RES| BE | EL | 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 | [7] If the EL degradation persist after step [6], another drop EL | |||
command is issued via following QOS report. | command is issued via following QOS report. | |||
The decision to drop/scale up is entirely up to the application- | The decision to drop/scale up is entirely up to the application-specific | |||
specific adaptation policy residing at destination mobile. For | adaptation policy residing at destination mobile. For example a video flow may | |||
example a video flow may be sensitive to delays and delivery of | be sensitive to delays and delivery of constantly changing bandwidth so once | |||
constantly changing bandwidth so once enhancement layer packets are | enhancement layer packets are dropped, it requires stable resource | |||
dropped, it requires stable resource availability of resources | availability of resources before a scale up decision is made. In the case of | |||
before a scale up decision is made. In the case of real-time data, | real-time data, there may not be any drop command and the application may want | |||
there may not be any drop command and the application may want to | to closely follow the dynamics of resource availability. In such case the | |||
closely follow the dynamics of resource availability. In such case | adaptation policy is quite different from that of a video flow example. | |||
the adaptation policy is quite different from that of a video flow | ||||
example. | ||||
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. | ||||
Authentication : | 5. SECURITY ISSUES | |||
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 : | The MANET computing environment is very different from the ordinary computing | |||
Upper layer protocols, i.e., INSIGNIA must register with IMEP | environment. In many cases, mobile computers will be connected to the network | |||
prior to use. | 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. | ||||
7. APPLICATIONS | 6. APPLICATIONS | |||
INSIGNIA can be used as signaling support for small (pico-cell) and | INSIGNIA can be used as signaling support for small (pico-cell) and large | |||
large scale mobile networks. Flows and microflows can be supported. | scale mobile networks. Flows and microflows can be supported. Voice, video and | |||
Voice, video and real-time data applications can be supported using | real-time data applications can be supported using the INSIGNIA adaptive | |||
the INSIGNIA adaptive real-time service. In addition, INSIGNIA | real-time service. In addition, INSIGNIA networks support traditional best | |||
networks support traditional best effort services. | effort services. | |||
8. ACKNOWLEDGMENT | 7. ACKNOWLEDGMENT | |||
We would like to thank Mischa Schwartz and Javier Gomez Castellanos | The work is supported in part by the Army Research Office (ARO) under award | |||
for comments on this work. | DAAD19-99-1-0287 and with support from COMET Group industrial sponsors. | |||
9. REFERENCE | 8. REFERENCE | |||
[1] V. Park, and S. Corson, "Temporally Ordered Routing Algorithm | [1] V. Park, and S. Corson, "Temporally Ordered Routing Algorithm | |||
(TORA) Version 1 Functional Specification", draft-ietf-manet- | (TORA) Version 1 Functional Specification", draft-ietf-manet- | |||
tora-spec-00.txt, November 1997. | tora-spec-00.txt, November 1997. | |||
[2] J. Macker, and M. S. Corson, "Mobile Ad hoc Networking (MANET): | [2] J. Macker, and M. S. Corson, "Mobile Ad hoc Networking (MANET): | |||
Routing Protocol Performance Issues and Evaluation | Routing Protocol Performance Issues and Evaluation | |||
Considerations", draft-ietf-manet-issues-01.txt, April 1998. | Considerations", draft-ietf-manet-issues-01.txt, April 1998. | |||
[3] D. D. Clark and D.L. Tennenhouse, "Architectural Consideration | [3] D. D. Clark and D.L. Tennenhouse, "Architectural Consideration | |||
for a New Generation of Protocols", Proc. ACM SIGCOMM'90, August | for a New Generation of Protocols", Proc. ACM SIGCOMM'90, August | |||
1990. | 1990. | |||
skipping to change at page 24, line 4 | skipping to change at page 21, line 50 | |||
wireless packet networks". In Proceedings of ACM SIGCOMM, San | wireless packet networks". In Proceedings of ACM SIGCOMM, San | |||
Francisco, California, 1997 | Francisco, California, 1997 | |||
[23] OPNET, http://www.mil3.com | [23] OPNET, http://www.mil3.com | |||
[24] A. S. Acampora and M. Naghshineh, "QOS provisioning in micro- | [24] A. S. Acampora and M. Naghshineh, "QOS provisioning in micro- | |||
cellular networks supporting multiple classes of traffic", | cellular networks supporting multiple classes of traffic", | |||
Wireless Networks, 2(3), 1996. | Wireless Networks, 2(3), 1996. | |||
[25] Lee, S-B. and A.T. Campbell, "INSIGNIA: In-band Signaling | [25] Lee, S-B. and A.T. Campbell, "INSIGNIA: In-band Signaling | |||
Support for QOS in Mobile Ad Hoc Networks" Proc of 5th | Support for QOS in Mobile Ad Hoc Networks" Proc of 5th | |||
International Workshop on Mobile Multimedia Communications | International Workshop on Mobile Multimedia Communications | |||
(MoMuC,98), Berlin, Germany, October 1998. | (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). | ||||
10. AUTHORS' ADDRESSES | 9. AUTHORS' ADDRESSES | |||
Seoung-Bum Lee, Andrew T. Campbell | ||||
COMET Group | Seoung-Bum Lee (Managing Author), Gahng-Seop Ahn, Andrew T. Campbell, | |||
Columbia University | Xiawei Zhang | |||
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 | 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 | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |