idnits 2.17.1 draft-ahlard-boomerang-framework-00.txt: -(743): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'MF' is mentioned on line 123, but not defined == Missing Reference: 'DGVECTOR' is mentioned on line 340, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSHEAD' -- Possible downref: Non-RFC (?) normative reference: ref. 'EF' -- Possible downref: Non-RFC (?) normative reference: ref. 'AF' ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. 'IntServ') -- Possible downref: Non-RFC (?) normative reference: ref. 'YESSIR' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEASURE' -- Possible downref: Non-RFC (?) normative reference: ref. 'TICKET' -- Possible downref: Non-RFC (?) normative reference: ref. 'BOOMP' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Ahlard, Telia Research 3 Expires: August 1999 J. Bergkvist, Telia Research 4 I. Cselenyi, Telia Research 5 T. Engborg, Telia Research 7 February, 1999 9 Boomerang - A Simple Resource Reservation Framework for IP 10 12 Status of this Memo 14 This document is an Internet-Draft and is NOT offered in 15 accordance with Section 10 of RFC2026, and the author does not 16 provide the IETF with any rights other than to publish as an 17 Internet-Draft. Internet-Drafts are working documents of the 18 Internet Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check 29 the "1id-abstracts.txt" listing contained in the Internet-Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 31 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 32 Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This draft describes a framework for providing quantitative IP 37 services with guaranteed QoS. Although the proposed reservation 38 approach is based on a new, lightweight signaling protocol, it can 39 be used with interoperability with other IP QoS techniques such as 40 Diff-Serv, Int-Serv. 42 Distinguishing features of the Boomerang protocol are: 43 * signaling messages are generated only by the initiating 44 node, therefore complexity and intelligence is 45 concentrated in one point enabling simple implementation 46 * flow state aggregation can be suggested to subsequent 47 nodes by appending the Boomerang message, thus good 48 scalability can be achieved 49 * bi-directional reservation can be made independently of 50 the path, which yields a fast and effective reservation 51 process 52 * the only requirement on the far-end node is that it 53 should be able to bounce the Boomerang message back, 54 ensuring quick penetration into the current Internet. 56 There is a lab prototype in which the Boomerang protocol is 57 wrapped in ICMP ECHO / ECHO-REPLY (PING) messages. 59 Table of contents 61 1 Terminology 3 62 2 Introduction 3 63 3 Properties 4 64 3.1Simple Implementation 4 65 3.2Good Scalability 4 66 3.3Simple But Effective Signaling Process 5 67 3.3.1Bi-directional Reservation 5 68 3.3.2Concentrated Intelligence 5 69 3.3.3Low protocol overhead 5 70 3.3.4Soft-state 5 71 3.3.5Resource Query 5 72 3.3.6Fast Reservation Process 5 73 3.4Penetration 6 74 3.4.1Transparency 6 75 3.4.2QoS Interoperability 6 76 3.4.3Multiple Scope 6 77 3.4.4No requirements on the Far-end Node 6 78 4 Reservation Concept 6 79 4.1Boomerang Reservation Message 6 80 4.1.1Signaling Header 7 81 4.1.2Flow Specification 7 82 4.1.3QoS Specification 7 83 4.1.4Transport Mechanism 7 84 4.2Operation 8 85 4.2.1Lost Boomerang 9 86 5 Issues 9 87 5.1Flow-state Aggregation 9 88 5.1.1Aggregation Suggested by Earlier Node 9 89 5.1.2Measurement Based Admission Control 10 90 5.1.3Refresh Message based Admission Control 10 91 5.2Route Changes 10 92 5.3Multicasting 11 93 5.4Denial of Service 11 94 5.5Selective Hunting 11 95 5.6Security 11 96 5.7Decreasing network signaling 11 97 5.7.1Network flooding by refresh messages 12 98 5.7.2Network loading by end to end transmission of NACKED 99 connections 12 100 6 Illustrative scenarios 13 101 6.1Single-domain with a bottleneck 13 102 6.2End-to-end reservation with aggregation 14 103 7 References 15 104 8 Author Information 16 105 1 Terminology 107 The terminology given in [E2E] is used in this document extended 108 with the following notions: 110 Boomerang Protocol (BOOMP) 111 The simple, hop-by-hop resource reservation protocol used in this 112 framework. 114 Initiating Node (IN) 115 This is the node initiating the resource reservation. Can be the 116 sender or receiver host or any BOOMP-aware network node. 118 Far-End Node (FEN) 119 This is the node to which reservations are being made. 121 Micro-Flow 122 A data flow from one end-point to another, defined uniquely by MF 123 classification [MF]. 125 Boomerang Node (BN) 126 A BOOMP-aware node which performs admission control and 127 reservation for single or aggregated micro-flows. 129 Aggregating Node (AN) 130 A Boomerang Node that associates several micro-flows with a 131 common, aggregated QoS specification and appends an aggregation 132 field to the Boomerang messages of associated micro-flows, in 133 order to suggest an aggregated reservation state for subsequent 134 BNs. 136 2 Introduction 138 Besides Differentiated Services [DSARCH] network operators may 139 also be interested in offering guaranteed services to ambitious 140 customers, and quantitative QoS applications [E2E] in an end-to- 141 end manner. However, best effort network domains or bottleneck 142 segments within a DS domain may compromise the end-to-end QoS 143 during peak hours in the network. Therefore a simple signaling 144 protocol is needed to signal per micro-flow QoS requirements to 145 the network and to reserve resources end-to-end in guaranteed 146 manner. 148 RSVP is the only accepted signaling protocol for resource 149 reservation setup in IP networks [RSVP], although it has several 150 limitations: 152 1. it relies on per micro-flow state, which results in a 153 scalability problem in terms of memory, capacity and processing 154 time 155 2. it is complex to implement both in nodes and hosts due to 156 separation of reservation and path finding messages, receiver 157 diversity 158 3. it requires modification in the far end host 159 4. The intelligence of signaling processing is spread over 160 the network. Each node along a reserved path contains a flow state 161 and a signaling state. Therefore, each reservation session 162 increases the load on network nodes. 163 5. it requires multiple interaction between sender and 164 receiver for a successful reservation setup 166 We propose a new reservation protocol for IP networks, called 167 Boomerang, which meets the following challenges: 169 1. Simple way for aggregating micro-flow reservation states 170 2. Simple processing of signaling messages at network nodes 171 resulting in simple implementation 172 3. No special requirements on the far end 173 4. Concentrating the intelligence in the Initiating Node (IN). The 174 IN is responsible for signaling- and handling flow state for the 175 setup reservation. Network nodes along reserved path keep only 176 flow states, resulting in low load and processing time on network 177 nodes. 178 5. Quick reservation setup thanks to a single signaling loop 180 The Boomerang protocol has been designed to be quick and simple, 181 yet powerful. It aims for extending the QoS mechanisms offered by 182 DS, RSVP, Int-Serv [IntServ] rather than replacing them. 184 3 Properties 186 The properties of the Boomerang protocol are grouped according to 187 the main benefits they yield. 189 3.1 Simple Implementation 191 In BOOMP, signaling states (meaning intelligence) are needed only 192 in the initiating node. Other BNs are 'passive' and the only 193 requirement is that they are able to interpret the Boomerang 194 message. Therefore the most complex BOOMP implementation is made 195 locally in IN and it is a reasonable belief that BOOMP can be 196 simply implemented in other nodes. Another feature that 197 contributes to simplicity is that BOOMP is focused on unicast and 198 sender oriented multicast services. 200 3.2 Good Scalability 202 In order to decrease the context made for keeping track of the 203 reservation state of micro-flows, ANs can propose an aggregation 204 of these flow states. Consistency of micro-flow aggregation is 205 maintained by appending an aggregation field in the repeatedly 206 circulated BOOMP refresh messages. All control logic related to an 207 aggregation is concentrated in one AN, while other nodes can 208 simply rely on the information steadily coming in Boomerang 209 messages or handle micro-flow states. 211 3.3 Simple But Effective Signaling Process 213 3.3.1 Bi-directional Reservation 215 This implies that both the sender and the receiver node can send a 216 Boomerang, i.e. can act as IN. Many applications can not benefit 217 from receiver orientated reservations. Moreover, policy and 218 billing may suit better to sender initiated reservation in case of 219 certain applications (like broadcast video). For unicast 220 applications BOOMP can be used in a receiver oriented manner. 222 Different QoS parameters might be set up along the forward and 223 reverse path of the traffic flow. The forward and reverse path for 224 a bi-directional flow may differ. 226 3.3.2 Concentrated Intelligence 228 The signaling control logic is concentrated in the initiating node 229 in BOOMP. Other nodes are not generating signaling messages. 231 3.3.3 Low protocol overhead 233 There is typically one or maximum two signaling loop required per 234 reservation session. Only the IN generates signaling messages, 235 other BNs do not. A simple calculation is given in Section 6. 236 about the amount of signaling overhead for BOOMP. 238 3.3.4 Soft-state 240 BNs maintain reservation states as soft states, i.e. reservations 241 time out if they are not refreshed periodically. In this way 242 orphan reservations disappear automatically and routing changes 243 have just a temporary effect. 245 3.3.5 Resource Query 247 When the Boomerang flies through the network, each BN decreases 248 the resource request field if it has less resources available for 249 the corresponding reservation. In this way the IN gets information 250 about the current network state and has a good chance to make a 251 successful reservation trial. 253 3.3.6 Fast Reservation Process 255 BOOMP requires only one 'signaling loop' between the IN and FEN 256 for a successful reservation. 258 3.4 Penetration 260 The following features results in an incremental deployment of 261 BOOMP in current IP networks. 263 3.4.1 Transparency 265 The only requirement for BOOMP-unaware nodes is to forward the 266 BOOMP messages. QoS in this node has to be ensured by another 267 (loose or tight) QoS mechanism, otherwise the end-to-end QoS can 268 be compromised. There is a prototype in which PING is used as the 269 transport mechanism of BOOMP enabling the proper behavior in the 270 vast majority of current IP-capable network devices. 272 3.4.2 QoS Interoperability 274 On the top of guaranteed resource reservation in Boomerang Nodes, 275 BOOMP can be used for asking for both tight QoS (such as the EF 276 DSCP) and loose QoS (such as AF DSCP) [EF, AF]. It is not limited 277 to any specific QoS specification, for instance it can transport 278 Intserv parameters as well. 280 3.4.3 Multiple Scope 282 There are many different way of using the Boomerang protocol for 283 resource reservation. It can be used between two hosts running 284 unicast services, either in a sender in or receiver oriented 285 manner. It can also be used for sender oriented multicast 286 services. 288 Moreover, the scope of BOOMP can be limited to a single 289 network domain, which is connected to domains utilizing other QoS 290 techniques. 292 3.4.4 No requirements on the Far-end Node 294 The other end-user can be quite unaware of all BOOMP 295 implementation in initiating node and network nodes and still 296 profit from its functionality. 298 4 Reservation Concept 300 4.1 Boomerang Reservation Message 302 The BOOMP reservation message contains the following fields for 303 IPv4 traffic [BOOMP]: 305 * a signaling header 306 * a flow specification 307 * QoS specification 309 4.1.1 Signaling Header 311 This field contains the refresh interval and several flags in 312 which BNs can indicate the result of processing the Boomerang 313 message. 315 The refresh interval in the Boomerang message is a measure of how 316 often the reservation has to be refreshed in order to keep it from 317 timing out in the network nodes. The Initiating Node chooses a 318 refresh interval. But it can be decreased by any router that needs 319 a lower refresh interval; thus enforcing a higher refresh rate by 320 the IN. 322 If the IN stops sending refresh messages the resource allocation 323 will eventually time out. The network administrator should choose 324 the actual timeout in the network, and the IN should make no 325 assumptions about it. 327 4.1.2 Flow Specification 329 A BN identifies a micro-flow uniquely by five fields, found in the 330 BOOMP reservation message that sets up the flow. These fields in 331 the reservation message are: source IP address, source port 332 number, destination IP address, destination port number and the IP 333 protocol field. 335 4.1.3 QoS Specification 337 The IN indicates the type of QoS it requires with the BOOMP 338 reservation message - for the forward as well as for the reverse 339 direction. The QoS parameter in current BOOMP implementation is 340 bit rate, but other formats are also possible [DGVECTOR]. 341 Requested handling of the flow is specified in the reservation 342 message. Different types of data flow require different queue 343 handling rules in the nodes. The Boomerang protocol categorizes 344 different service classes, each with different types of queue 345 handling rules. Queue handling rules differ regarding priority, 346 loss sensitivity and delay sensitivity. 348 4.1.4 Transport Mechanism 350 There are several ways for transporting the Boomerang protocol. 352 ICMP ECHO / ECHO REPLY 353 In the current prototype implementation BOOMP is wrapped in an 354 ICMP 355 ECHO / ECHO REPLY messages, i.e. a normal PING message. This 356 conveniently ensures the correct node behavior from most existing 357 nodes both passive routers and hosts. 359 New protocol or new ICMP message 360 A cleaner implementation would be to define a new ICMP message for 361 the BOOMP primitives, or to assign an entirely new protocol for 362 BOOMP signaling. 364 In both these later cases however, we would not have the correct 365 end-node behavior for free. We would probably have to configure 366 each unaware network node to accept these messages. 368 The router alert option should be set for each Boomerang message 369 in order to indicate that the routers should investigate this 370 message [RALERT]. 372 Inbound signaling 373 A slightly different approach is to transport the reservation 374 messages as an integral part of the transport protocol. In this 375 case a transport mechanism must be defined for each transport 376 protocol where we desire to do resource reservation. This is the 377 approach taken in YESSIR [YESSIR], which is an inbound signaling 378 protocol for RTP connections. 380 4.2 Operation 382 Resource reservation with the Boomerang protocol is simple. The 383 Initiating Node (IN) sends a Boomerang message to the Far-End Node 384 (FEN) containing the desired forward and reverse QoS descriptors 385 (e.g. bit rate). When this message reaches the FEN, it is echoed 386 back to the IN. The Boomerang message follows standard routing 387 protocols, and allocates resources hop-by-hop in all Boomerang- 388 aware nodes (BNs) en route. This ensures that the reservation will 389 be made along the correct path for both upstream and downstream 390 traffic. When IN gets back the Boomerang message, it verifies the 391 completion of the reservation by examining the appropriate message 392 flags that have been set in the BOOMP message by the BNs along the 393 way. Reservation messages are then sent periodically from the IN 394 to the FEN (the rate is specified by the IN itself) to keep the 395 reservation alive in all of the nodes along the upstream and 396 downstream paths. 398 If a reservation request is denied by a BN, the following actions 399 are taken before the reservation message is forwarded using 400 standard routing rules: 401 a) The NACK flag in the message is set 402 b) If the requested resources are greater than the available 403 resources at the current node, the QoS Specification fields of the 404 Boomerang message are updated to reflect the current lowest 405 available resources. 407 c) If the Refresh Interval in the Boomerang exceeds the 408 network node's current maximum refresh interval, it is updated to 409 reflect the current minimum refresh interval. 411 If a message arrives at the network node with the NACK flag 412 already set, only actions (b) and (c) are taken. 414 When the reservation arrives back at the IN, it checks the message 415 to see if the reservation was successful. 416 If the NACK flag is NOT set, the reservation was successful, but 417 the Refresh Interval field might still have changed. If this is 418 the case, the IN continues to send Boomerang messages with the 419 interval stated in the refresh interval field. 420 If the NACK flag is set, the request was denied somewhere along 421 the message path. This is where the IN has to take some action. A 422 new maximum QoS Specification might have been specified, so the IN 423 may choose to retry the old request, revoke it with the attained 424 new QoS specification, or release the request. 426 4.2.1 Lost Boomerang 428 If the Boomerang message does not return to the IN within a 429 certain time, it is considered to be lost. The IN can wait and 430 repeat the original request again, or downgrade the demanded 431 resource amount and request less. 433 5 Issues 435 5.1 Flow-state Aggregation 437 The Boomerang protocol requires no signaling states in the network 438 nodes. However, other kind of states may be needed for several 439 other reasons such as policing of flows and to keep track of the 440 amount of resources used in a robust way. To take full benefit of 441 the Boomerang protocol in network nodes with a high aggregation of 442 traffic we require ways of doing admission control that does not 443 require us to keep information per micro-flow. 445 There are different ways for making flow state aggregation in 446 BOOMP. 448 5.1.1 Aggregation Suggested by Earlier Node 450 This is an extension to the Boomerang protocol, which allows a 451 microflow node to suggest a destination subnet-based aggregation 452 to a later network node. When the microflow node discovers that it 453 has a large number of reservations between two subnets it can 454 decide to append aggregation information for these subnets to each 455 signaling message within this aggregated flow. This is done by 456 appending a special message field to Boomerang containing the 457 class, IP protocol, source / destination subnetmask for this 458 aggregation, an aggregation key (e.g. the aggregating node's own 459 IP number) and the total resource demand of this aggregated flow. 460 Nodes inside the network may now use this information to create 461 states for these aggregates of micro-flows and can perform 462 policing on these. The later node can then in turn suggest further 463 aggregation for following nodes. 465 5.1.2 Measurement Based Admission Control 467 This covers any method where no hard control is kept of the 468 allocated resources. On contrary, admission control is performed 469 by measuring the current amount of traffic in the given class. 470 Experiments indicate [MEASURE] that measurement based techniques 471 can be made to work even with long range dependant flows for a 472 reasonably large aggregation. 474 5.1.3 Refresh Message based Admission Control 476 Instead of storing hard states for keeping track of the used 477 resources, the refresh request messages can be used. By summing 478 the requested rates weighted by the refresh interval over a 479 sliding window, the node can estimate the amount of resources 480 already reserved and use this knowledge to do admission control. A 481 similar approach is proposed in [TICKET]. The accuracy of the 482 estimate will depend on the number of refresh messages within the 483 sliding window, and the node should therefore refresh a rather 484 frequent refresh interval. As with the measurement-based scheme, 485 dynamic policeing of individual flows is not possible. 487 5.2 Route Changes 489 While the issues of routing and route changes are not strictly a 490 part of the signaling problem, the questions inevitably arise. If 491 we are granted resources along a specific path, our data must stay 492 along this path or our reservation will be useless. Furthermore, 493 if we reserve resources along a path and allow these packets 494 through policing as e.g. EF PHB, a path change may ruin the 495 performance of other EF users in violation of the PHB 496 specifications. To avoid this we must either keep states at each 497 potential bottleneck where we might expect sudden route changes, 498 or pin the route. This can be done either dynamically by 499 "freezing" the router cache entry, or by using static route 500 policies over narrow links. Our own experiences shows that in a 501 network with best effort routing, route changes are very rare and 502 are almost always triggered by a change in topology (such as a 503 link failure). The case of non topology driven route changes 504 almost always occur in the access network where the number of 505 flows is reasonably low. Refreshed reservations and soft 506 reservation states can help in most of the cases. 508 5.3 Multicasting 510 The Boomerang protocol does not distinguish individual leafs 511 within a multicast group, so the most natural way to use it in 512 conjunction with multicast would be a sender oriented scheme. The 513 sender would send the reservation request to the entire multicast 514 group and it would be up to the leafs to detect the success or 515 failure for that particular branch. A typical application could be 516 a broadcast video server similar to the pay-TV found in hotel 517 rooms. The server would send reservation messages to the multicast 518 group with a short refresh interval (e.g. 3 seconds) and the 519 NO_ECHO flag set. When a new client is added to the multicast 520 group resource reservation is attempted within one refresh 521 interval and the client will start receiving data along with 522 either ACKed or NACKed reservations. If it receives NACKs then 523 obviously the reservation failed and it is up to the client to ask 524 to be removed from the multicast list. 526 From the perspective of the BOOMP, it is possible to ask for 527 resources for a multicast group along a specific branch. However, 528 we think that solving the complexity of multiple users depending 529 on the same reservation (accounting and such) is out of the scope 530 of the network layer. 532 5.4 Denial of Service 534 The Boomerang protocol provides a special ?key? field for 535 preventing misuse of partially failed reservations. The access 536 router could easily have a rate limit mechanism per source 537 address. This is mainly an implementation issue. 539 5.5 Selective Hunting 541 The main idea is that even if the node is "Boomerang aware" we 542 only need to actually process the Boomerang messages if the node 543 is judged to be a bottleneck. The Boomerang protocol could be 544 deactivated by something like a bandwidth broker, if the node is 545 not a bottleneck. However, computers as opposed to humans do not 546 benefit significantly from resting so the main gain from 547 deactivating the Boomerang protocol would be a decrease in 548 signaling delay. 550 5.6 Security 552 TBD. 554 5.7 Decreasing network signaling 556 There are a few issues concerning the efficiency of the protocol 557 and their possible solutions. 559 5.7.1 Network flooding by refresh messages 561 Since the Boomerang protocol suggests refreshing of reservations 562 with intervals down to a few seconds, using it with no aggregation 563 might create a significant network load. If the refresh interval 564 is the same for a large number of sources these will not quickly 565 decorrelate if they happen to be correlated, which may result in 566 unpleasant bursts of network traffic. A small numerical example: 567 with the very short refresh interval of 3 sec and packets 568 consisting of 56 byte IPv4 Boomerang message + ICMP + IP+ Ethernet 569 = 92 bytes we will have a bitrate of 245bps. For a 12kbps IP 570 telephony call this is about 2% overhead. In practical use with 571 longer refresh interval, the overhead should be significantly 572 less. As for the correlation, the reservations are obviously 573 initiated in an uncorrelated fashion and it would therefore be 574 quite rare that more than a few sources at a time would drive into 575 correllation. The impact of these occurrences could be further 576 reduced by letting hosts and nodes that sets the refresh value 577 randomize it in a neighborhood of the desired value. 579 5.7.2 Network loading by end to end transmission of NACKED connections 581 In the Boomerang protocol we state that all signaling is end to 582 end. This means that network nodes does not generate signaling 583 they only modify and update incoming signaling messages. The 584 reason for this is that it makes the protocol extremely simple to 585 implement. This also means that a reservation which is NACKed 586 early in the network still has to travel the entire way to the end 587 node and back, which both loads the network and increases the 588 probability of the reservation getting lost. A solution to this 589 would be to return the NACK immediately by the NACKing node. We 590 have chosen not to do this since the NACK messages are an 591 extremely small part of the network traffic and we value the 592 simplicity of passive nodes more. Instead we treat the NACKed 593 message as a query, and update it along the path with the minimum 594 available resources. This way the returning NACK can serve as 595 decision support for the initiating node. 597 6 Illustrative scenarios 599 The multiple scopes of Boomerang based reservation process is 600 illustrated by two simple examples. 602 6.1 Single-domain with a bottleneck 604 Let us consider a scenario where we have two hosts (A, F) attached 605 to a DS domain (B-C-D-E). The DS network is non blocking for high 606 priority traffic, but there is a highly utilized link in the 607 middle (C-D) where over-provisioning is difficult or very 608 expensive (e.g. the Atlantic cable). This is a potential 609 bottleneck link for the guaranteed service. 611 A B C D E F 612 /-------------------------\ 613 | | 614 +---+ +----+ +---+ +---+ +----+ +---+ 615 |IN | | | |BN | |BN | | | |FEN| 616 +---+--| |----| |===| |----| |--+---+ 617 +---+ +----+ +---+ +---+ +----+ +---+ 618 | | 619 \-------DS domain---------/ 621 The traffic between hosts (A) and (F) has to pass through the DS 622 compliant network including the bottleneck link. Therefore one of 623 the hosts should send a BOOMP reservation request, in order to get 624 resources on the bottleneck link in a guaranteed manner. 626 Let us assume that host (A) sends a BOOMP message, which is 627 forwarded hop-by-hop through the network and echoed back by host 628 (F). Since (B) and (E) are BOOMP-unaware nodes, they just simply 629 forward the Boomerang message to the next hop. Node (C) as the 630 ingress node of the bottleneck link performs admission control for 631 the requested resources and indicate the result in the Boomerang 632 message. Similarly, node (D) performs admission control for the 633 backward traffic. It is possible to specify different amount of 634 resources for the traffic going in the forward and reverse 635 directions, and forward and reverse paths can differ. 637 Host A can then see the result of the reservation from the 638 returned BOOMP message. 640 In case of a successful reservation, host A can start to send (or 641 receive) traffic with guaranteed QoS on the bottleneck links and 642 DS-based QoS in the rest of the DS network. For the latter, data 643 packets shall be marked with proper DSCP [DSHEAD]. The initiating 644 host should refresh the reservation by sending BOOMP messages 645 periodically to prevent the soft states in the nodes from timing 646 out. 648 6.2 End-to-end reservation with aggregation 650 SUBNET_1 SUBNET_2 652 +---+ +---+ 653 | X |\ A B C D /| Z | 654 +---+ \ +---+ +----+-+ +----+ +----+ / +---+ 655 +---+ \ | | | AN | | |BN | |BN | / +---+ 656 *---+ +--| | |--| |--| |---* 657 +---+ / +---+ +----+-+ +----+ +----+ \ +---+ 658 | Y | / \ | U | 659 +---+/ \+---+ 660 +---+ B -- aggregating node +---+ 662 Aggregation of flow states can be made, if one or more resource 663 reservations share the same QoS specifications. It can be made on 664 a subnet-to-subnet basis, and requires no special de-aggregation 665 functionality. 667 In this example, (X) and (Y) are two nodes that want to allocate 668 resources to (Z). They do this in the usual way by sending 669 Boomerang messages that will pass through (A), (B), (C) and (D), 670 bounce at (Z) and then go back, reserving bandwidth in the 671 opposite direction. (X) and (Y) send their reservations 672 periodically, each with its own refresh interval. 674 The (B) node might aggregate these reservations, since it is aware 675 of the fact that both reservations are made with source=SUBNET_1 676 and destination=SUBNET_2. To aggregate these reservations, (B) 677 appends an aggregation field to each refresh Boomerang message 678 that arrives from (X) and (Y). This aggregation field contains the 679 sum of resources reserved for the aggregate, information that 680 helps to identify the corresponding subnets (SUBNET_1 and 681 SUBNET_2), and a special aggregation key to differentiate this 682 aggregation from other ones made between the same subnets. 684 (B) still keeps track of each reservation, it does not remove any 685 context. When the Boomerang messages leaves (B), heading for (Z), 686 it will contain this appended aggregation field and subsequent 687 nodes may use it to create contexts. 689 If (C) gets a Boomerang message from (X), with an aggregation 690 field appended, it may ignore the information about the individual 691 flow, and only create a context for the aggregation. Whenever 692 another reservation message arrives, (C) looks for aggregation 693 fields, and uses this part of the Boomerang message as a refresh 694 message for the aggregated reservation state. 696 Node (D) may, on the other hand, simply ignore these aggregation 697 fields, and treat each message as a unique reservation. If (X) 698 then stops sending refresh messages, the corresponding reservation 699 state times out in (B), and (B) updates the aggregated state to be 700 consistent with the currently reserved bandwidth. Moreover, (B) 701 indicates this change in the corresponding Boomerang messages by 702 removing the aggregation field. When the aggregation is removed 703 completely, the aggregated reservation will eventually time out in 704 (C), but by that time a new context should have been created in 705 (C) for each individual flow. 707 7 References 709 [E2E] Bernet, Y., Yavatka,r R., Ford, P., Baker, F., Nichols, 710 K., Speer, M., "A Framework for End-to-End QoS Combining 711 RSVP/Intserv and Differentiated Services", IETF 712 , March 1998. 714 [DSARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, 715 and W. Weiss, "An Architecture for Differentiated Services", 716 Internet Draft, May 1998. 718 [DSHEAD] K. Nichols and S. Blake, "Definition of the Differentiated 719 Services Field (DS Byte) in the IPv4 and IPv6 Headers", 720 Internet Draft, May 1998. 722 [EF] V. Jacobson, Kathleen Nichols, Kedernath Poduri, 723 "An Expedited Forwarding PHB", Internet Draft, February 1999 724 726 [AF] F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured 727 Forwarding PHB Group", Internet Draft, February 1999. 728 730 [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated 731 Services in the Internet Architecture: An Overview", Internet 732 RFC 1633, July 1994. 734 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and 735 Jamin, S., "Resource Reservation Protocol (RSVP) Version 1 736 Functional Specification", IETF RFC 2205, Proposed 737 Standard, September 1997. 739 [YESSIR] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation 740 Mechnism for the Internet", 741 http://www.ctr.columbia.edu/~pan/work/yessir/yessir.ps 743 [DGVECTOR]Csel�nyi, I., Szab�, R., Szab�, I., Bj�rkman, N., Latour- 744 Henner, A., "Experimental Platform for Telecommunication 745 Resource Management" Computer Communications (21)17 (1998) 746 pp.1624-1640 748 [MEASURE] J.T. Lewis, R. Russell, F. Toomey, B. McGurk, S. Crosby, 749 I. Leslie, "Practical connection admission control 750 for ATM networks based on on-line measurements", 751 Computer Communications (21)17 (1998) pp. 1585-1596 753 [TICKET] A. Eriksson, C. Gehrmann, "Robust and Secure Light- 754 weight Resource Reservation for Unicast IP Traffic", 755 International WS on QoS'98, IWQoS'98, May 18-20, 1998 757 [BOOMP] _The Boomerang Resource Reservation Protocol_ 759 [RALERT] D. Katz, "IP router alert option", RFC 2113, IETF, 760 February 1997 762 8 Author Information 764 Ahlard, David 765 Telia Research 766 Vitsandsgatan 9B 767 S-123 86 Farsta, Sweden 768 Phone: +46 8 713 81 90 769 Email: davahl@trab.se 771 Bergkvist, Joakim 772 Telia Research 773 Vitsandsgatan 9B 774 S-123 86 Farsta, Sweden 775 Phone: +46 8 713 81 71 776 Email: jobe@trab.se 778 Cselenyi, Istvan 779 Telia Research 780 Vitsandsgatan 9B 781 S-123 86 Farsta, Sweden 782 Phone: +46 8 713 81 73 783 Email: cse@trab.se 785 Engborg, Tomas 786 Telia Research 787 Vitsandsgatan 9B 788 S-123 86 Farsta, Sweden 789 Phone: +46 8 713 81 76 790 Email: toeng@trab.se