idnits 2.17.1 draft-ietf-manet-insignia-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 176 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 308 has weird spacing: '...ules of the w...' == Line 431 has weird spacing: '...rvation payl...' == Line 524 has weird spacing: '...tion is ackno...' == Line 566 has weird spacing: '...tion to desti...' == Line 634 has weird spacing: '...pleting the s...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2000) is 8746 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '26' on line 1078 looks like a reference -- Missing reference section? '20' on line 1058 looks like a reference -- Missing reference section? '15' on line 1044 looks like a reference -- Missing reference section? '2' on line 1007 looks like a reference -- Missing reference section? '1' on line 1004 looks like a reference -- Missing reference section? '7' on line 1019 looks like a reference -- Missing reference section? '5' on line 1015 looks like a reference -- Missing reference section? '6' on line 1017 looks like a reference -- Missing reference section? '3' on line 1010 looks like a reference -- Missing reference section? '22' on line 1067 looks like a reference -- Missing reference section? '25' on line 1074 looks like a reference -- Missing reference section? '19' on line 1054 looks like a reference -- Missing reference section? '4' on line 1013 looks like a reference -- Missing reference section? '8' on line 1021 looks like a reference -- Missing reference section? '9' on line 1024 looks like a reference -- Missing reference section? '10' on line 1028 looks like a reference -- Missing reference section? '11' on line 1032 looks like a reference -- Missing reference section? '12' on line 1036 looks like a reference -- Missing reference section? '13' on line 1039 looks like a reference -- Missing reference section? '14' on line 1042 looks like a reference -- Missing reference section? '16' on line 1046 looks like a reference -- Missing reference section? '17' on line 1048 looks like a reference -- Missing reference section? '18' on line 1051 looks like a reference -- Missing reference section? '21' on line 1062 looks like a reference -- Missing reference section? '23' on line 1070 looks like a reference -- Missing reference section? '24' on line 1071 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT G-S. Ahn, A. T. Cambell, S-B Lee, X. Zhang 2 Columbia University 3 October 1999 5 7 Expires May 2000 9 INSIGNIA 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' The list 23 of current Internet-Drafts can be accessed at: 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at: 27 http://www.ietf.org/shadow.html. Distribution of this memo is 28 unlimited. 30 Abstract 32 This document specifies INSIGNIA, an in-band signaling system for 33 supporting quality of service (QOS) in mobile ad hoc networks. The 34 term `in-band signaling` refers to the fact that control information 35 is carried along with data in IP packets. We argue that in-band 36 signaling is more suitable than explicit out-of-band approaches 37 (e.g., RSVP) when supporting end-to-end quality of service in highly 38 dynamic environments such as mobile ad hoc networks where network 39 topology, node connectivity and end-to-end quality of service are 40 strongly time-varying. INSIGNIA is designed to support the delivery 41 of adaptive real-time services and includes fast 42 session/flow/microflow reservation, restoration and adaptation 43 algorithms between source/destination pairs. In this memo we discuss 44 how INSIGNIA fits into our broader vision of a wireless flow 45 management model for mobile ad hoc networks and how it interfaces to 46 the proposed MANET Working Group routing algorithm. 48 Table of Contents 50 0. WHAT'S CHANGED .............................................. 2 52 1. INTRODUCTION ................................................ 3 53 1.1 TERMINOLOGY ............................................ 4 54 1.2 ASSUMPTIONS ............................................ 6 56 2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING 6 57 2.1 PACKET FORWARDING MODULE ............................... 7 58 2.2 ROUTING MODULE ......................................... 7 59 2.3 INSIGNIA MODULE ........................................ 7 60 2.4 ADMISSION CONTROL MODULE ............................... 7 61 2.5 PACKET SCHEDULING MODULE ............................... 8 62 2.6 MEDIUM ACCESS CONTROLLER MODULE ........................ 8 64 3. INSIGNIA PROTOCOL ........................................... 8 65 3.1 INSIGNIA IP OPTIONS .................................... 8 66 3.2 RESERVATION MODE ....................................... 9 67 3.3 SERVICE TYPE ........................................... 10 68 3.4 PAYLOAD INDICATOR ...................................... 10 69 3.5 BANDWIDTH INDICATOR .................................... 10 70 3.6 BANDWIDTH REQUEST ...................................... 11 72 4. INSIGNIA OPERATIONS ......................................... 11 73 4.1 FLOW SETUP ............................................. 12 74 4.2 QOS REPORTING .......................................... 13 75 4.3 SOFT-STATE MANAGEMENT .................................. 14 76 4.4 FLOW RESTROATION ....................................... 15 77 4.5 ADAPTATION ............................................. 16 79 5. SECURITY ISSUES ............................................. 20 81 6. APPLICATION ................................................. 20 83 7. ACKNOWLEDGMENT .............................................. 20 85 8. REFERENCE ................................................... 20 87 9. AUTHOR'S ADDRESSES .......................................... 22 89 0. WHAT'S CHANGED 91 This memo has minor modifications from the previous draft, the 92 operation of protocol remains the same. For full detail on the 93 evaluation of INSIGNIA see [26]. 95 1. INTRODUCTION 97 The introduction of real-time audio, video and data services into 98 mobile ad hoc networks presents number of technical barriers that are 99 due to the time-varying nature of the network topology, node 100 connectivity and end-to-end quality of service (QOS). In such 101 networks, mobile nodes function as hosts and routers. As hosts they 102 represent source and destination nodes in the network while as 103 routers they represent intermediate nodes between a source and 104 destination providing store-and-forward services to neighboring 105 nodes. The wireless topology that interconnects mobile hosts/routers 106 can change rapidly in unpredictable ways or remain relatively static 107 over long periods of time. Another technical issue that needs to be 108 addressed is associated with the wireless link level performance. 109 Mobile ad hoc networks are bandwidth constrained and time-varying due 110 to radio link characteristics and impairments. 112 The end-to-end communications abstraction between two communicating 113 mobile hosts can be viewed as a complex channel. Due to node mobility 114 and wireless link impairments, user-to-user sessions may need to be 115 rerouted in the network while preserving the session connectivity and 116 quality. Network algorithms need to be strongly adaptive and 117 responsive to the time-varying and location dependent topological 118 changes, resource availability, quality of service degradation and 119 session connectivity. 121 In order to provide adaptive quality of service support for real-time 122 service in mobile ad hoc networks, 'flow-states' (i.e., reservation 123 states at nodes associated with flows or microflows) need to be 124 managed. A flow needs to be established, restored, adapted and 125 removed over the course of a user-to-user session in response to 126 time-varying topology, connectivity and end-to-end quality of service 127 conditions. 129 Since wireless and computational resources are limited in mobile ad 130 hoc networks, any signaling overhead needed for wireless flow 131 management must be kept to a bare minimum. Future signaling systems 132 should be capable of restoring reservations and associated flow- 133 states along a new path in response to topological changes with 134 minimum noticeable degradation at the user session level. 136 This memo provides an overview of wireless flow management model that 137 supports the delivery of adaptive real-time services in dynamic 138 mobile ad hoc networks. A key component of wireless flow management 139 is INSIGNIA, an in-band signaling system that supports fast flow 140 reservation, restoration and adaptation algorithms that are 141 specifically designed to deliver adaptive real-time services in 142 mobile ad hoc networking environments. INSIGNIA is designed to be 143 lightweight and highly responsive to changes in network topology, 144 node connectivity and end-to-end quality of service conditions. For 145 full detail on the evaluation of INSIGNIA, see [26]. 147 1.1 TERMINOLOGY 149 Mobile Ad Hoc Networks: 150 Represent autonomous distributed systems that comprise a 151 number of mobile nodes connected by wireless links forming 152 arbitrary time-varying wireless network topologies [20]. 154 Adaptive real-time flows: 155 This type of flow represents delay sensitive traffic, 156 e.g., voice and video which can sustain some loss. Real time 157 data flows are assumed to be somewhat loss tolerant and delay 158 sensitive. These types of flows typically require flow setup 159 procedures, resource reservation provided by INSIGNIA. 161 Microflows: 162 Micro flows represent short-lived flows, e.g. web style 163 client/server interactions that comprises a limited train of 164 data packets. These types of flows may require resource 165 assurances in the network and, therefore, typically require 166 some form of in-band support for fast resource allocation. We 167 use the terms session/flow and microflow interchangeably. 168 INSIGNIA has been designed to transparently support the 169 requirements of both flowsand microflows in mobile ad hoc 170 networks. 172 Flow Setup: 173 A Source initiates a flow set up by transmitting a request 174 packet with its minimum and maximum bandwidth requirements. 175 Intermediate mobiles receiving request packets, processes the 176 requests and forward them to the next appropriate mobile host. 177 A flow setup is complete when a source receives a QOS report 178 from its peer destination. 180 Restoration: 181 When a reserved flow is rerouted and its associated states 182 (e.g., reservation) are successfully created along the new 183 route. Three types of restoration (viz. `max to max`, 184 `max to min` and `min to max`) may be observed along the new 185 path. 187 Enhancement Layer (EL) Degradation: 188 When a reserved flow is rerouted and its EL restoration fails, 189 then a flow/sessions enhancement layer packets are degraded 190 to best effort service. In a such case, only base layer (BL) 191 packets are forwarded/received as reserved packets. 193 Flow Degradation: 194 When a reserved flow is rerouted and both EL and BL restoration 195 fails. No resource allocation or associated states are created 196 and all packets are treated as best effort after re-routing. 198 Adaptation: 199 When EL degradation persists for an unacceptable period, a 200 destination mobile notifies its source to drop the EL packets 201 at the source host (scaling down). The destination can also 202 initiates an EL resource recovery (scaling up) procedure when a 203 monitored flow state at the destination indicate that 204 sufficient resources exist along the path to support a better 205 quality level. 207 Adaptation Policy: 208 Describes the bandwidth adaptation characteristics of a flow 209 and the actions to be taken based on the observed network 210 conditions experienced by a flow and its ability to adapt to 211 those conditions. The decision to trigger adaptation mechanisms 212 (i.e., scaling flows up/down)is based on application-specific 213 adaptation policy. 215 Adaptation Handler: 216 A module that stores the adaptation policy that interacts with 217 flow monitoring and QOS report modules. 219 Monitoring Module: 220 A module that keeps track of the incoming INSIGNIA flow state. 221 Typically the packet type, resource availability and QOS 222 are periodically monitored. 224 QOS reports: 225 These are periodic messages that are generated by destinations 226 to inform peer sources of reception state/status of adaptive 227 real-time flows. The periodicity depends on the sensitivity of 228 a flow. Best effort flows do not, typically, generate QOS 229 reports. 231 Soft-state management: 232 Each mobile host creates, stores and updates the state 233 information for each adaptive real-time flow and its 234 reservation status. This state information requires subsequent 235 packets to refresh the flow state otherwise the flow state is 236 considered old and automatically removed after a soft-state 237 interval. 239 Soft-state timer: 240 The soft-state timer value defines the holding time for real- 241 time reservation state for adaptive real-time flows/flows. If 242 the mobile soft-state is not refreshed within the soft-state 243 timer interval then the state is automatically removed. (Note 244 that the treatment of flows and microflows may differ in terms 245 of the setting of this state variable. Typically, flows would 246 call for extremely fast reservation and release that may be 247 more aggressive than the dynamics and timescales associated 248 with longer lived flows. This issue is under experimentation 249 and for further study.) 251 1.2 ASSUMPTIONS 253 INSIGNIA assumes that link status sensing and access schemes are 254 provided by lower layer entities/protocols. 256 2. A WIRELESS FLOW MANAGEMENT MODEL FOR MOBILE AD HOC NETWORKING 258 The goal of wireless flow management is to support the delivery of 259 adaptive real-time services in mobile ad hoc hosts under time- 260 varying conditions. An adaptive service model allows packet audio, 261 video and real-time data applications to specify their maximum and 262 minimum bandwidth needs. INSIGNIA plays a central role in the 263 resources allocation and management between source and destination 264 mobiles. Based on availability of end-to-end resources, wireless 265 flow management attempts to provide assurances for the minimum or 266 maximum bandwidth needs depending of resource availability. In 267 addition to supporting adaptive real-time services the service 268 model also supports IP best-effort packet delivery. 270 adaptive mobile 271 applications 272 ^ 273 +--------------------------------------------------------------+ 274 | | | 275 | +---------------+ | +-----------------+ +-----------+ | 276 | | MANET routing | | | INSIGNIA |<--->| admission | | 277 | | protocol | | | | | control | | 278 | +---------------+ | +-----------------+ +-----------+ | 279 | | \ | | | | | | 280 | | \ | | | control | | 281 | --------- \ | | --------- | --------- | 282 | routing \ | | mobile | channel | 283 | table \ | | soft-state | state | 284 | --------- \ | | --------- | --------- | 285 | \ \ | signal / \ | packet / \ | 286 | \ \ v -ing / \ | drop / \ | 287 | \ +------------+ +-----------+ \ | 288 | +-----+ \| packet | | packet | +-----+ | 289 ===>| MAC |===>| forwarding |======>| scheduling|====>| MAC |===> 290 | +-----+ +------------+ +-----------+ +-----+ | 291 |IP packet in data packets IP packet out| 292 +--------------------------------------------------------------+ 294 Figure 1. Wireless Flow Management Model at a Mobile Host/Router 296 Realizing wireless flow management in mobile ad hoc networks presents 297 a number of technical challenges. First, flows and microflows should 298 be rapidly established without the penalty of a round trip delay and 299 with minimal overhead due to signaling. Second, active flows should 300 be maintained and restored in case of routing changes or link 301 failure. Wireless flow management should be capable of rapidly 302 responding to dynamic topology changes by adapting and re- 303 establishing affected flows with minimal service disruption. Third, 304 flow-state set up during flow establishment should be automatically 305 removed when an application session terminates. Flow-state should 306 also be automatically removed at routers no longer on the new path 307 after re-routing has occurred due to topological changes. The main 308 modules of the wireless flow management model are illustrated in 309 Figure 1). 311 2.1 PACKET FORWARDING MODULE 313 The packet forwarding module [15] classifies incoming packets and 314 forwards them to the appropriate module (viz. MANET routing, 315 INSIGNIA, local applications, wireless packet scheduling modules). 316 Signaling messages are processed by INSIGNIA and data packets 317 delivered locally or forwarded to the packet scheduling module. 319 2.2 ROUTING MODULE 321 The routing module dynamically tracks changes in ad hoc network 322 topology making the routing table visible (via APIs) to all 323 intermediate packet forwarding module (e.g., INSIGNIA, packet 324 forwarding). Wireless flow management assumes the availability of 325 MANET routing protocol [2] (e.g. Temporally Ordered Routing Algorithm 326 (TORA) [1], Dynamic Source Routing [7], Zone Routing Protocol [5], Ad 327 Hoc On demand Distance Vector Routing Protocol [6]). 329 2.3 INSIGNIA MODULE 331 The INSIGNIA module establishes, restores, adapts and tears down 332 real-time flows. Flow restoration algorithms respond to dynamic route 333 changes due to mobility. Adaptation algorithms respond to changes in 334 available bandwidth. Based on an in-band signaling approach that 335 explicitly carries control information in the IP packet header, flows 336 can be rapidly established, restored, adapted and released in 337 response wireless impairments and topology changes. Because of this 338 dynamic environment, network state management is based on soft-state 339 [3], which is well suited to managing reservation flow-state in 340 mobile ad hoc networks. 342 2.4 ADMISSION CONTROL MODULE 344 The admission control module is responsible for allocating bandwidth 345 to flows based on the maximum/minimum bandwidth requested. Once 346 resources have been allocated they are periodically refreshed by a 347 mobile soft-state mechanism through the reception of data packets. 348 Admission control testing is based on the measured channel 349 capacity/utilization and requested bandwidth. To keep the protocol 350 simple and lightweight, new reservation requests do not affect 351 existing flow reservations. Rerouted or new flows may be degraded 352 ifresources are unavailable. 354 2.5 PACKET SCHEDULING MODULE 356 The packet scheduling module responds to location dependent channel 357 conditions experienced in wireless networks [22]. The scheduling 358 mechanism is implementation and QOS model dependent. Currently, we 359 have implemented a simple Weighted Round-Robin (WRR) service 360 discipline which takes location dependent channel conditions into 361 account. It should be noted that a wide variety of scheduling 362 disciplines can be used to realize the packet scheduling module. 364 2.6 MEDIUM ACCESS CONTROLLER MODULE 366 The medium access controller module (possibly) provides quality of 367 service driven access to the shared wireless media for adaptive 368 real-time services and best-effort services. The wireless flow 369 management is designed to be transparent to any underlying media 370 access control protocols. However, the performance of the MANET is 371 strongly coupled to the provisioning of QOS support at the MAC layer. 372 Nevertheless, our approach is to investigate the performance of 373 INSIGNIA using both non QOS-capable and QOS-capable MACs. 375 3. INSIGNIA PROTOCOL 377 Mobile ad hoc signaling systems should be lightweight in terms of the 378 amount of bandwidth they consume and be capable of reacting to fast 379 network dynamics close to call/session and packet transmission time 380 scales. Future signaling systems should be highly responsive to flow 381 re-routing and be capable of re-establishing active reservations 382 along the new path with minimum disruption to on-going services. 384 In-band signaling systems are capable of operating close to packet 385 transmission time scales and are therefore well suited toward 386 managing fast time-scale dynamics found in mobile ad hoc 387 environments. In contrast, out-of-band signaling systems (e.g. 388 Internet's RSVP, ATM's UNI, etc.) are incapable of responding to such 389 fast time-scale dynamics. Based on an in-band approach, INSIGNIA is 390 designed to restore 'flow-state' (i.e., a reservation) in response to 391 topology changes within the interval of two consecutive IP packets 392 under ideal conditions. 394 3.1 IP OPTIONS 396 To establish an adaptive real-time flows, INSIGNIA uses a new IP 397 option to setup, restore and adapt resources between source- 398 destination pairs. When intermediate nodes receive packets with the 399 these IP options set they attempt to reserve, restore or adapt 400 resources forwarding date packets toward the destination. 402 By coding control information in the INSIGNIA IP option (in each IP 403 header), we support the notion of in-band control which we believe is 404 called for to support QOS in ad-hoc mobile networks. The INSIGNIA IP 405 option supports flow reservation, restoration and adaptation control. 406 Best effort and adaptive real-time services are supported by INSIGNIA 407 and are indicated by the reservation mode and service type fields in 408 the IP options as illustrated in Figure 2. Flows are represented as 409 having a discrete base layer (BL) with a minimum bandwidth and an 410 enhancement layer, which requires the maximum bandwidth. This 411 characterization is commonly used for multi-resolution traffic (e.g., 412 MPEG audio and video) and more generally for real-time data that has 413 discrete max-min requirements. 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |Version| IHL |Type of Service| Total Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Identification |Flags| Fragment Offset | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Time to Live | Protocol | Header Checksum | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Source Address | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Destination Address | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Options (Used for INSIGNIA IP Options) | Padding | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 2a. IP Header 431 reservation payload bandwidth request 432 mode indicator 433 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 434 +-------+-----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |REQ/RES|AS/BE|BL/EL|max/min| max_bandwidth | min_bandwidth | 436 +-------+-----+-----+-------+---------------+---------------+ 437 service bandwidth 438 type indicator 439 |<----->|<--->|<--->|<----->|<----------------------------->| 440 1 bit 1 bit 1 bit 1 bit 16 bits 442 Figure 2b. INSIGNIA IP Options 444 3.2 RERSERVATION MODE 446 To establish an adaptive real-time flow, a source node sets the 447 request (REQ) bit in the IP option of a data packet to initiate a 448 reservation request. On reception of a REQ packet, the intermediate 449 nodes execute admission control and accept or deny the request. If 450 the request is accepted, resources are committed and subsequent 451 packets are scheduled accordingly. Otherwise, packets are treated as 452 best effort packets if resources are unavailable. 454 Packets that are received by nodes with their reservation mode set to 455 reserved (RES) indicate that the session has previously passed 456 admission control and resources have been reserved. In the case where 457 a RES packet is received and no resources have been allocated the 458 admission controller immediately attempts to make a reservation. This 459 condition commonly occurs when reserved flows are rerouted during the 460 lifetime of an active session due to mobility of sources, 461 intermediate router nodes or destinations. 463 3.3 SERVICE TYPE 465 The interpretation of the service type, which indicates either a 466 adaptice service (AS) or best-effort (BE) packet, is dependent on the 467 reservation mode. A packet with the reservation mode set to REQ and 468 service type to AS is attempting to setup a real-time flow with the 469 bandwidth requirements of the flow specified in the bandwidth request 470 field. A packet with RES/AS set indicates that an end-to-end 471 reservation has previously been established. A RES/AS packet service 472 may be degraded to RES/BE service if the flow is rerouted along a new 473 path when insufficient resources were available on the new path. 475 A best effort packet sets the reservation mode to REQ as default and 476 the service type to BE requiring no resource reservation to be made 477 in the network. Reception of a RES/BE by a destination node indicates 478 an active adaptive real-time flow was degraded to BE due to 479 insufficient resource availability after rerouting to a new path. 481 3.4 PAYLOAD INDICATOR 483 The payload field indicates the type of packet being transported. 484 INSIGNIA supports two types of payload, i.e., base (BL) and 485 enhancement layers (EL). The semantics of the adaptive real-time 486 services are related to the payload type and resource availability. 487 Base and enhancement layers can be assured via distributed end-to-end 488 admission control and resource reservation. Maximum bandwidth 489 reservation is required to support both base and enhancement layers 490 of a flow whereas only minimum bandwidth reservation is required to 491 support the base layer. When a flow with minimum reservation receives 492 a EL packet in reserved mode (RES/AS) set, it indicates either the 493 reservations for EL has been restored at the bottleneck node or an 494 adaptation (scale-up) has been occurred. 496 3.5 BANDWIDTH INDICATOR 498 The bandwidth indicator represents the potential resource 499 availability for a flow/session along its current path between a 500 source and destination pair. In this respect the bandwidth indicator 501 represents the prospective resource availability to an application 502 which will change over time. This does not, however, represent an 503 actual resource reservation but the potential for one to succeed give 504 the current indication. The bandwidth indicator is carried in each 505 packet and can be therefore viewed as a dynamic state variable that 506 can be updated by any mobile host on the current path. Based on its 507 value it represents a good bandwidth hint that resources are 508 available along the current path to meet the flows minimum or maximum 509 needs. In this capacity the bandwidth indicator plays an important 510 role during the flow setup phase and, more importantly, during the 511 adaptation phase. 513 During flow setup the bandwidth indicator represents the resource 514 availability along the chosen setup route. Reception of setup request 515 packets with the bandwidth indicator bit set to MAX indicates that 516 all nodes en-route have sufficient resources to support the maximum 517 bandwidth requested. In contrast, a packet with the bandwidth 518 indicator set to MIN implies that at least one of the intermediate 519 nodes (known as the bottlenecked mobile host) between the source and 520 destination has insufficient bandwidth resources to meet the maximum 521 needs (if specified); however, reception of a packet with the 522 bandwidth indicator set to MIN does indicate that all nodes can 523 support the minimum bandwidth requirement. In this case, only the 524 base layer reservation is acknowledged as having been successful 525 established via QOS reporting (see Section 4.2). QOS reporting 526 between the destination and source can be used to force the source to 527 'drop' enhancement layers. In this case the source would only forward 528 the BL packets toward the destination in reserved mode. Any 529 enhancement layer packets would be forwarded as best-effort packets. 530 This action has the benefit of releasing an 'partial reservations' 531 for the enhancement layer that may exist between a bottlenecked 532 mobile host and the destination. We will discuss the issue of 533 'partial reservations' (which may occur in all phases of INSIGNIA 534 operation)in the sections of flow setup, restoration and adaptation. 536 The bandwidth indicator is also utilized for restoring the 537 reservation for EL if previously degraded to best effort service. In 538 order to accomplish scaling up adaptation, the adaptation handler 539 resident at destination should monitors a flow's resource 540 availability (by monitoring the bandwidth indicator) and, based on 541 the adaptation policy, initiate a 'scale up' operation using a QOS 542 report. 544 3.6 BANDWIDTH REQUEST 546 The bandwidth request allows a source to specify its maximum (MAX) 547 and minimum (MIN) bandwidth requirements for adaptive real-time 548 service support. This assumes that the source has selected the AS 549 service type. A source may also simply specify a minimum or a maximum 550 bandwidth requirement. For adaptive real-time services the base layer 551 is supported by the MIN bandwidth whereas the MAX bandwidth supports 552 the delivery of the base and enhancement layers between a source and 553 destination pair. 555 4. INSIGNIA OPERATIONS 557 The IP option and operations support the delivery of adaptive real- 558 time services to mobile hosts. These operations collectively define 559 the foundation of the INSIGNIA system and include flow setup, flow 560 restoration, soft-state management, adaptation and QOS reporting. 562 Once a flow has been established between a source-destination pair, 563 QOS reports are used to inform the source of the progress of the 564 delivered packet quality at the destination. Node mobility may 565 trigger topology changes. In this case the MANET routing protocol may 566 provide alternative or new path information to destination, in which 567 case, INSIGNIA would attempt to restore reservations at all nodes on 568 the new path through the restoration operation. Moreover, adaptation 569 may be triggered to adjust a flow to match resources availability 570 found on the new path. Managing the network state,while responding to 571 these network dynamics, is handleby a soft-state management mechanism 572 in INSIGNIA. In the following sections,each of the INSIGNIA 573 operations are outlined. 575 4.1 FLOW SETUP 577 To establish adaptive real-time flows, source nodes set the 578 appropriate fields in the IP option before forwarding 'reservation 579 request' packets toward destination mobile hosts. A reservation 580 request packet is characterized as having its reservation mode set to 581 REQ, service type set to AS, a valid payload (viz. BL or EL) and a 582 MAX/MIN bandwidth requirement. 584 Reservation packets traverse intermediate nodes executing admission 585 control modules, allocating resources and establishing flow-state at 586 all nodes between source-destination pairs. If any intermediate 587 mobile node lacks resources to support the requested flow setup, the 588 appropriate IP option field is changed to indicate this condition (or 589 state). 591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 592 +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |REQ| AS |BL/EL|max/min| max_bandwidth | min_bandwidth | 594 +---+----+-----+-------+---------------+---------------+ 596 Figure 3. INSIGNIA Packet Requesting MAX/MIN reservation 598 If an intermediate mobile receives a request packet and can only 599 support the minimum requirement then the flow request is degraded to 600 the minimum request at the bottleneck mobile node by resetting the 601 bandwidth indicator to MIN. Meanwhile the source continues to send 602 reservation requests packets until the destination informs it of the 603 status of flow establishment phase via QOS report (discussed in 604 Section 4.2). Subsequent reservation request packets do not execute 605 admission control but simply refresh existing soft-state reservation. 607 The establishment of an adaptive real-time flow is illustrated in 608 Figure 4. A source mobile host (M1) issues a flow setup by requesting 609 resource reservation. M2 performs admission control upon reception of 610 the request packet. Resources are allocated if available and the 611 request packet is forwarded to the next mobile (M3). This process is 612 repeated hop by hop until the request packet reaches the destination 613 mobile host (M6). The destination mobile node determines the resource 614 allocation status by checking the service type and current level of 615 service. 617 When a reservation request is received at the destination node, the 618 INSIGNIA module checks the reservation status. The status of the flow 619 setup is determined by inspecting the bandwidth indication field. If 620 the bandwidth indicator is set to MAX then this implies that all 621 mobile hosts between the source destination have successfully 622 allocated resources to meet the base and enhancement layers bandwidth 623 requirements. On the other hand, a bandwidth indication set to MIN 624 indicates that only the base layer can be currently supported. In 625 this case, all reserved packets with a payload of EL received at the 626 destination have their service level flipped from AS to BE by the 627 bottleneck node. In such case, a partial reservation may exist 628 between the source and bottleneck mobile node. This partial 629 reservation can be viewed as a waste of resources between the source 630 and bottlenecked node (since they go unused) or, as a 'near 631 reservation' where all but the remaining nodes (between the 632 bottlenecked node and the destination) hold reservations. Holding on 633 to these reservations - in effect locking them in - is a 'hedge' 634 against completing the setup phase in the near future. The treatment 635 of 'partial reservations' is still under consideration. Currently, 636 the adaptation process allows the mobile host to clear partial 637 reservations using the adaptation process or leave them in place. 639 +----+ +----+ 640 QOS_REPORT(2)| M9 |---| M8 |\QOS_REPORT(2) 641 +----+ /+----+ +----+ \ +----+ 642 | M2 |/ / \| M7 |\QOS_REPORT(2) 643 REQ(1)/+----+\ / +----+ \+----+ 644 +----+/ \ +----+/ +----+ | M6 | 645 | M1 | REQ(1)\| M3 |---| M4 |REQ(1) /+----+ 646 +----+ +----+ +----+\ +----+/ 647 REQ(1) \| M5 | REQ(1) 648 +----+ 649 Figure 4. INSIGNIA Request Packet and QOS report 651 4.2 QOS REPORTING 653 QOS reports are used to inform the source of the status of received adaptive 654 real-time flows. Destination nodes actively monitor on-going flows inspecting 655 status information (e.g., bandwidth indication) and calculating QOS statistics 656 (viz. packet loss, delay, out-of-sequence delivery and throughput). QOS 657 reports are periodically sent to source host for the purpose of completing 658 flow establishment and managing adaptations. QOS reporting is application 659 dependent where the periodicity of reports is determined by the application's 660 sensitivity to the delivered QOS. Note that QOS reports do not have to travel 661 on the reverse path toward the source. Typically they will take an alternate 662 route through the ad hoc network as illustrated in Figure 4. 664 In the case of flow establishment, reception of a reservation request packet 665 with the bandwidth indicator set to MAX (or MIN) indicates that the source's 666 maximum (minimum) reservation has been successfully made en-route. The 667 destination informs the source of this reservation status by setting the 668 bandwidth indicator field with MAX (MIN) in the QOS report, accordingly. The 669 QOS report is a best effort data packet with a payload that comprises of a 670 adaptation commands and measured QOS information. 672 QOS reports are also used as part of on-going adaptation process that responds 673 to mobility and resources changes in the mobile ad hoc network. Periodic QOS 674 reports can be used to inform the source to 'drop' (e.g., drop all EL packets) 675 or 'scale-up' (i.e., transmit EL packets) based on available resources and the 676 adaptation policy of the application. These are the 'adaptation commands'. 678 4.2.1 QOS REPORT INTERVAL 680 Since each flow has different sensitivity to QOS, the periodicity of QOS 681 report for each flow should reflect this sensitivity. A flow that is sensitive 682 to service quality requires more frequent QOS report than one that is less 683 sensitive (i.e., more QOS control). A source relates the sensitivity of a flow 684 via setting the TTL value with relatively small value. The destination 685 utilizes the TTL value, requested bandwidth and the adaptation policy to 686 determine the flow's sensitivity to service quality. We are currently 687 investigating the migration of this function to the INSIGNIA IP options field. 689 4.2.2 QOS PACKET FORMAT 691 The role of the QOS report is to serve as a simple notification of the 692 satisfaction level perceived by the destination. The QOS report includes a 693 QOS. In fact, the QOS report of INSIGNIA has the same format as a best effort 694 INSIGNIA data packet. A QOS report has the reservation mode set to RES and 695 service type set to BE. The minimum bandwidth field is set to zeros and 696 maximum bandwidth is set to ones. By doing so, the QOS report can be 697 distinguished from the degraded RES packet. The various packet formats are 698 illustrated in Figure 8. 700 4.2.3 QOS REPORT DELIVERY 702 QOS reports should be delivered in a timely fashion. We propose to schedule 703 QOS reports before the transmission of best effort packets but without 704 affecting the performance of reserved flows. The IP option codepoint for QOS 705 reports, even though best effort in service type, set it a side from all 706 other best effort traffic for a 'better than best effort treatment' at 707 intermediate nodes. 709 4.3 SOFT-STATE MANAGEMENT 711 Maintaining the quality of service of real time flows in mobile ad hoc network 712 is one of the most challenging aspects that INSIGNIA addresses. Typically, 713 wireline networks requires little QOS or state management where the routes and 714 the reservations remain fixed for the duration of the session/flows. This 715 style of 'hard-state' connection oriented communications guarantees quality of 716 service for the duration of the holding time. However, these techniques are 717 not applicable/valid in mobile ad hoc networks where paths and reservations 718 need to dynamically respond to topology changes in a timely manner over 719 multiple time scales and network dynamics. 721 Based on the work by Clark [3], 'mobile soft-state' relies on the fact that 722 sources periodically send data messages along the existing path. If a data 723 packet arrives at a mobile router and no reservation exists then admission 724 control and resource reservations are needed to establish soft-state 725 reservations. Subsequent reception of a data packet at a router is used to 726 refresh the soft-state reservation. Thus a mobile host receiving a data packet 727 for an existing reservation reconfirms the reservation over the next time 728 interval. The holding-time for a reservation is based on a soft-state timer 729 interval and not, as in the case of call setup, based on the session duration 730 holding time. If a new packet is not received within a soft-state timer 731 interval, resources are released and flow-states removed automatically without 732 any explicit tear-down messaging. 734 The soft-state approach is well suited for management of resources in dynamic 735 environment where the path and reservation associated with a flow may change 736 rapidly. The transmission of data packets is strongly coupled to maintenance 737 of flow-states, i.e., reservations. As the route changes in the network, new 738 reservations will be automatically restored by the restoration mechanism 739 provided that resources are available along the new path. 741 Another benefit of mobile soft-state is that resources allocated during flow 742 establishment are automatically removed when the path changes without any 743 explicit signaling interactions. In-band approaches are flexible and scalable 744 in dealing with a number of difficult mobile ad hoc network issues whereas 745 out-of-band signaling systems need to maintain source route information and 746 respond to topology changes by directly signaling 'affected mobiles' to 747 allocate or free radio resources. In some case, this is impossible to do when 748 using out-of-band signaling techniques if the 'affected router' is out of 749 radio contact from the signaling entity that is attempting to de-allocate 750 resources over the old path. 752 4.4 FLOW RESTORATION 754 Flows are often rerouted during the lifetime of sessions due to mobility in 755 mobile ad hoc networks. The goal of flow restoration is to re-establish 756 reservation as fast and efficiently as possible. Rerouting of an active flow 757 involves new admission control and resource reservations for nodes on the new 758 path. Restoration procedures also call for the removal of flow-state at nodes 759 along the old path. In an ideal case, the restoration of flows can be 760 accomplished within the duration of a few consecutive packets because of the 761 in-band nature of INSIGNIA's control. 763 When a mobile moves out of radio contact and loses connectivity, the 764 forwarding router mobile interacts with the routing module and forwards 765 subsequent packets via the new route. (Note that if the routing table does not 766 have an alternative route toward the destination then the performance of the 767 restoration process is tightly coupled to the performance of the 768 proactive/reactive MANET routing protocol that is operational. This issue is 769 for further study. In [25], however, we implemented INSIGNIA in a mid size ad 770 hoc network using TORA [1] as the routing protocol and discuss performance 771 issues there). 773 The mobile hosts on a new path receive rerouted packets and inspect their flow 774 state tables. If a reservation does not exist for the rerouted flow then the 775 INSIGNIA module invokes admission control and tries to allocate 776 resources. Note that, if the reserved packets are routed back on to the 777 existing path then the old states are likely to be still valid; hence, the 778 states and reservations are simply refreshed, minimizing any service 779 disruption due to re-rerouting. 781 Network dynamics may also trigger rerouting with service degradation. When a 782 reserved flow is rerouted to a node where resources are unavailable, the flow 783 is degraded to best effort service. Subsequent downstream nodes receiving 784 these degraded packets make no attempt to attempt to allocate resources or 785 refresh existing soft-state associated with the flow. This results in the 786 automatic removal of any reservation state. In time the reservation may be 787 restored if resources free up at the bottleneck mobile node or because of the 788 subsequent rerouting allowing the complete restoration of the flow 789 quality. The worst case scenario is that the flow will remain degraded for the 790 duration of the session holding time. 792 The enhancement layer of a reserved flow with maximum reservation may get 793 degraded during flow restoration if the nodes along the new path can only 794 support the minimum bandwidth requirement. If the degradation of enhancement 795 layer packets persist, it may cause service disruptions and may trigger the 796 destination mobile to invoke an adaptation procedure that force the source 797 node to drop the EL packets. Adaptation details are provided in the following 798 section. 800 4.5 ADAPTATION 802 Reception quality of a flow is monitored and based on an application-specific 803 adaptation policy, actions may be taken to adapt the flow to observed network 804 conditions. Actions taken are conditional on the adaptation-policy resident at 805 the destination node, e.g., adaptation policy may chose to maintain the 806 service level under degraded conditions or scale-down flows to their base 807 layers in respond to degraded conditions. Other policy could scale-up flows 808 whenever resources become available. The application is free to program its 809 own adaptation policy that is executed by INSIGNIA through interaction between 810 the destination and source nodes. Details about the adaptation policy API are 811 described in [19]. 813 The adaptation process includes the following adaptation actions: 815 (1) 'EL degradation' is a network driven action that forwards the 816 EL packets as best effort packets due to lack of resources; 817 (2) 'Drop enhancement layer' is a destination mobile driven action 818 which requests a source to drop its enhancement layers. This 819 happens when the EL degradation persists beyond an acceptable 820 period; and 821 (3) 'Scale-up', which requests a source to send its base and/or 822 enhancement layers in reserved mode. This event occurs when 823 a flow has only minimum reservation and the destination 824 learns (through the bandwidth indicator) that the route 825 can accommodate the maximum resource requirement. 827 The EL degradation is a network driven action whereas the others two actions 828 are driven by an adaptation handler resident at the destination mobile 829 host. Typically, the EL degradation can be observed after rerouting of an 830 adaptive real-time flow. In such an event the EL packets are degraded and 831 forwarded as best effort packets whereas BL packets are forwarded in reserved 832 mode. Note that preference is given to base layers over enhancement layers in 833 the event that reserved packets have to be degraded to best effort. If the EL 834 degradation persists, a `drop` command may be issued by the adaptation handler 835 at the destination mobile host according to the adaptation policy. The 836 decision to drop the EL packets is facilitated by monitoring the incoming 837 packets. The destination mobile can readily detect the degraded RES packets by 838 reading the IP option fields (where the degraded packets have the format of 839 Figure 5d). Figure 5 illustrates the different modes of INSIGNIA packets. 841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 842 +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |REQ| BE |BL/EL| max | max_bandwidth | min_bandwidth | 844 +---+----+-----+-----+---------------+---------------+ 845 Figure 5a. A Best Effort Packet 847 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 848 +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 |REQ| AS |BL/EL| max | max_bandwidth | min_bandwidth | 850 +---+----+-----+-----+---------------+---------------+ 851 Figure 5b. A Request Packet (EL or BL) 853 +---+----+-----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |RES| AS |BL/EL|max/min| max_bandwidth | min_bandwidth | 855 +---+----+-----+-------+---------------+---------------+ 856 Figure 5c. Typical Reserved (RES) Packet (EL or BL) 858 +---+----+-----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |RES| BE |BL/EL| max | max_bandwidth | min_bandwidth | 860 +---+----+-----+-----+---------------+---------------+ 861 Figure 5d. A Degraded RES Packet (EL or BL) 863 +---+----+----+-------+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |RES| BE | BL |max/min|1 1 1 1 1 1 1 1|0 0 0 0 0 0 0 0| 865 +---+----+----+-------+---------------+---------------+ 866 |<----------->| |<----- unique format --------->| 867 a QOS report 868 * max/min indicates the accepted service level 869 Figure 5e. Format of a QOS report 871 exist between a source and bottleneck mobile freeing up resources for other 872 adaptive real-time flows to utilize. It also removes degraded enhancement 873 layer packets from the network which in turn benefits the normal best effort 874 service flows. 876 INSIGNIA is also equipped with capability to restore the reservation needed 877 for enhancement layers.This process takes advantage of network and session 878 dynamics allowing existing sessions to take advantages of resources released 879 due to re-routing (e.g., resources released along an old path) or session 880 termination. These events may allow other mobile nodes to take advantage of 881 released resources by scaling up. The bandwidth indicator plays a key role in 882 bandwidth needs of the particular session/flow. 884 Typically, the scale-up process is invoked when the destination observes 885 sufficient resource have become available along the existing path restore the 886 reservation of an enhancement layer. The decision to scale up is determined by 887 the adaptation policy. 889 The following example scenario shows an example of a set of states (marked 890 [1] through [7]) observed at the destination illustrating a flow adaptation 891 scenario: 893 Adaptation Procedures : 895 [1] Incoming Packets at time t1 with maximum resource allocation 896 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |RES| AS | BL | max | max_bandwidth | min_bandwidth | 898 +---+----+----+-----+---------------+---------------+ 899 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 |RES| AS | EL | max | max_bandwidth | min_bandwidth | 901 +---+----+----+-----+---------------+---------------+ 902 . 903 . 904 . 906 [2] EL packets are degraded due to lack of resources at an 907 intermediate mobile node at time t2 and now packet formats become 908 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |RES| AS | BL | min | max_bandwidth | min_bandwidth | 910 +---+----+----+-----+---------------+---------------+ 911 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |RES| BE | EL | min | max_bandwidth | min_bandwidth | 913 +---+----+----+-----+---------------+---------------+ 914 * Note that EL packet is degraded to a best effort packet 915 . 916 . 917 . 919 [3] If the degraded EL packets are determined to be not useful for 920 destination mobile host, an EL drop command is issued via QOS 921 report. Upon reception of the QOS report the source transmits only 922 BL packets in reserved mode and do not transmit any EL packets. 923 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |RES| AS | BL | min | max_bandwidth | min_bandwidth | 925 +---+----+----+-----+---------------+---------------+ 926 * EL packets are not transmitted/received 927 . 928 . 929 . 931 [4] Constant resource availability is detected through the bandwidth 932 indicator at t4 where the received packets indicating the resource 933 availability have the following format. 934 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 |RES| AS | BL | max | max_bandwidth | min_bandwidth | 936 +---+----+----+-----+---------------+---------------+ 937 * Currently no EL packets are received. 938 * Destination learns from the bandwidth indicator bit (set to max) 939 that the current route has the resources available to restore the 940 EL packet flow. 941 . 942 . 943 . 945 [5] Through the next QOS report destination informs the source to 946 reinitiate the transmission on EL in RES mode. If the recovery 947 (scale up) is successful, destination receives the following 948 packets. 949 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 |RES| AS | BL | max | max_bandwidth | min_bandwidth | 951 +---+----+----+-----+---------------+---------------+ 952 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 |RES| BE | EL | max | max_bandwidth | min_bandwidth | 954 +---+----+----+-----+---------------+---------------+ 955 . 956 . 957 . 959 [6] If scale up attempt fails at any mobile node on the route, 960 destination receives degraded EL packets. 961 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 |RES| AS | BL | min | max_bandwidth | min_bandwidth | 963 +---+----+----+-----+---------------+---------------+ 964 +---+----+----+-----+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 |RES| BE | EL | min | max_bandwidth | min_bandwidth | 966 +---+----+----+-----+---------------+---------------+ 968 [7] If the EL degradation persist after step [6], another drop EL 969 command is issued via following QOS report. 971 The decision to drop/scale up is entirely up to the application-specific 972 adaptation policy residing at destination mobile. For example a video flow may 973 be sensitive to delays and delivery of constantly changing bandwidth so once 974 enhancement layer packets are dropped, it requires stable resource 975 availability of resources before a scale up decision is made. In the case of 976 real-time data, there may not be any drop command and the application may want 977 to closely follow the dynamics of resource availability. In such case the 978 adaptation policy is quite different from that of a video flow example. 980 5. SECURITY ISSUES 982 The MANET computing environment is very different from the ordinary computing 983 environment. In many cases, mobile computers will be connected to the network 984 via wireless links. Such links are particularly vulnerable to passive 985 eavesdropping, active replay attacks, and other active attacks. A stringent 986 authentication and registration processes are required to avoid any malicious 987 users. Currently, INSIGNIA does not specify any special security measures. 989 6. APPLICATIONS 991 INSIGNIA can be used as signaling support for small (pico-cell) and large 992 scale mobile networks. Flows and microflows can be supported. Voice, video and 993 real-time data applications can be supported using the INSIGNIA adaptive 994 real-time service. In addition, INSIGNIA networks support traditional best 995 effort services. 997 7. ACKNOWLEDGMENT 999 The work is supported in part by the Army Research Office (ARO) under award 1000 DAAD19-99-1-0287 and with support from COMET Group industrial sponsors. 1002 8. REFERENCE 1004 [1] V. Park, and S. Corson, "Temporally Ordered Routing Algorithm 1005 (TORA) Version 1 Functional Specification", draft-ietf-manet- 1006 tora-spec-00.txt, November 1997. 1007 [2] J. Macker, and M. S. Corson, "Mobile Ad hoc Networking (MANET): 1008 Routing Protocol Performance Issues and Evaluation 1009 Considerations", draft-ietf-manet-issues-01.txt, April 1998. 1010 [3] D. D. Clark and D.L. Tennenhouse, "Architectural Consideration 1011 for a New Generation of Protocols", Proc. ACM SIGCOMM'90, August 1012 1990. 1013 [4] M. Gerla and J.T-C Tsai, "Multicluster, mobile. Multimedia Radio 1014 Network", Wireless Networks 1(3), 1995 1015 [5] Z. Haas and M. Pearlman, "The Zone Routing Protocol (ZRP) for Ad 1016 Hoc Networks", draft-ietf-manet-zone-zrp-00.txt 1017 [6] C. Perkins, "Ad hoc On demand Distance Vector Routing", 1018 draft-ieft-manet-aodv-01.txt 1019 [7] D. B. Johnson and D. A. Maltz, "Dynamic Source Routing in Ad Hoc 1020 Wireless Network", In Mobile Computing, Chapter 5, pp. 153-181. 1021 [8] M. S. Corson, "Issues in Supporting Quality of Service in Mobile 1022 Ad Hoc Networks", Proc. IFIP Fifth International Workshop on 1023 Quality of Service (IWQOS '97), Columbia University. 1024 [9] C. R. Lin and M. Gerla, "A Distributed Architecture for 1025 Multimedia in a Multihop Dynamic Packet Radio Network," 1026 Proceedings of IEEE Globecom'95, Nov., pp. 1468-1472. 1028 [10] V. Park and M. S. Corson, "A Highly Adaptive Distributed Routing 1029 Algorithm for Mobile Wireless Networks", Proceedings of IEEE 1030 INFOCOM'97, April 1997 1032 [11] V. Park and M.S. Corson, "A Performance Comparison of the 1033 Temporally-Ordered-Routing Algorithm and Ideal Link-State 1034 Routing", Proceedings of IEEE Symposium on Computers and 1035 Communication '98, June 1998, Athens, Greece. 1036 [12] W. Almesberger, T. Ferrari and J. Le Boudec, "SRP: a Scalable 1037 Resource Reservation Protocol for the Internet", 1038 http://lrcwww.epfl.ch/srp/ 1039 [13] R. Ramanathan and M. Streenstrup, "Hierarchically-organized, 1040 multihop mobile wireless networks for quality-of-service 1041 support", ftp://ftp.bbn.com /pub/ramanath/mmwn-paper.ps 1042 [14] C. R. Lin and M. Gerla, "Asynchronous Multimedia Multihop 1043 Wireless Networks," Proceedings of IEEE INFOCOM'97, April 1997. 1044 [15] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 1045 ReSerVation Protocol (RSVP)", RFC 2205, September 1997. 1046 [16] P. Sharma, D. Estrin, S. Floyd, and V. Jacobson, "Scalable Timers 1047 for Soft-State Protocols", IEEE INFOCOM 1997, April 1997. 1048 [17] P. Ferguson, "Simple Differential Services: IP TOS and 1049 Precedence, Delay Indication and Drop Preferences", 1050 draft-ferguson-delay-drop-00.txt 1051 [18] M. S. Corson and V. Park, "An Internet MANET Encapsulation 1052 Protocol (IMEP) Specification. Internet Draft, 1053 draft-ietf-manet-imep-spec-01.txt, November 1997. 1054 [19] R. R-F. Liao and A.T. Campbell, "On Programmable Universal Mobile 1055 Channels in a Cellular Internet", 4th ACM/IEEE International 1056 Conference on Mobile Computing and Networking 1057 (MOBICOM'98), Dallas, October, 1998. 1058 [20] M.S. Corson and A.T Campbell, "Toward Supporting Quality of 1059 Service in Mobile Ad Hoc Networks", First Conference on Open 1060 Architecture and Network Programming, San Franscisco, April 3-4, 1061 1998. 1062 [21] J. Broch, D. A. Maltz, D. B. Johnson, Y-C Hu, and J. Jetcheva, "A 1063 Performance Comparison of Multi-Hop Wireless Ad Hoc Network 1064 Routing Protocols", to appear in Proc. of the 4th Annual ACM/IEEE 1065 International Conference on Mobile Computing and Networking, ACM, 1066 Dallas, TX, October 1998. 1067 [22] S. Lu, V. Bharghavan, and R. Srikant. "Fair scheduling in 1068 wireless packet networks". In Proceedings of ACM SIGCOMM, San 1069 Francisco, California, 1997 1070 [23] OPNET, http://www.mil3.com 1071 [24] A. S. Acampora and M. Naghshineh, "QOS provisioning in micro- 1072 cellular networks supporting multiple classes of traffic", 1073 Wireless Networks, 2(3), 1996. 1074 [25] Lee, S-B. and A.T. Campbell, "INSIGNIA: In-band Signaling 1075 Support for QOS in Mobile Ad Hoc Networks" Proc of 5th 1076 International Workshop on Mobile Multimedia Communications 1077 (MoMuC,98), Berlin, Germany, October 1998. 1078 [26] S-B. Lee, G-S. Ahn, X. Zhang and Andrew T. Campbell, 1079 "INSIGNIA: A QoS Framework for Mobile Ad Hoc Networks", Journal of 1080 Parallel and Distributed Computing - Special Issues on Wireless and 1081 Mobile Computing, Jan 2000 (to be published). 1083 9. AUTHORS' ADDRESSES 1085 Seoung-Bum Lee (Managing Author), Gahng-Seop Ahn, Andrew T. Campbell, 1086 Xiawei Zhang 1088 Department of Electrical Engineering, Columbia University 1089 Rm. 801 Schapiro Research Building 1090 530 W. 120th Street, New York, N.Y. 10027 1091 phone: (212) 854 3109 1092 fax : (212) 316 9068 (COMET Group) 1093 email: [sbl, ahngang, campbell, xzhang]@comet.columbia.edu