idnits 2.17.1 draft-bergkvist-boomerang-framework-00.txt: -(693): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(707): 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): ---------------------------------------------------------------------------- ** 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 the list of Shadow Directories. == There are 2 instances 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. 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.) -- The document date (November 2000) is 8562 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: 'MF' is mentioned on line 84, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. 'DSARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'DSRSVP' -- 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. 'DGVECTOR' -- Possible downref: Non-RFC (?) normative reference: ref. 'MEASURE' -- Possible downref: Non-RFC (?) normative reference: ref. 'TICKET' -- Possible downref: Non-RFC (?) normative reference: ref. 'BOOMER' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bergkvist, Telia Research 3 INTERNET-DRAFT I. Cselenyi, Telia Research 4 Expiration Date: May 2001 D. Ahlard, Telia Research 6 November 2000 8 Boomerang - A Simple Resource Reservation Framework for IP 9 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. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft shadow directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This memo provides information for the Internet community. This memo 33 does not specify an Internet standard of any kind. Distribution of 34 this memo is unlimited. 36 Abstract 38 This draft describes a framework for providing quantitative IP 39 services with guaranteed QoS. The proposed reservation approach is 40 based on a new, lightweight signaling protocol and it suits both 41 Diff-Serv, Int-Serv QoS architectures. 43 The main designing principle of the Boomerang protocol is to make 44 reservation almost as simple as forwarding an ordinary packet. Thus: 46 * Signaling messages are generated only by the initiating node, 47 therefore complexity and intelligence is concentrated in one point 48 enabling simple implementation 50 * Flow state aggregation can be suggested to subsequent nodes by 51 appending the Boomerang message 53 * Bi-directional reservation can be made by a single message loop 54 independently of the path, which yields fast and effective 55 reservation setup 57 * The only requirement on the far-end node is that it should be able 58 to bounce the Boomerang message back, thus it works where Ping 59 works. 61 According to actual measurements, a Linux-based Boomerang-aware 62 router can handle more than 120 000 concurrent reservation sessions 63 and up to 6800 reservation requests per second, while the impact on 64 data forwarding performance is negligible. 66 1. Terminology 68 The terminology given in [E2E] is used in this document extended with 69 the following notions: 71 Boomerang Protocol (BOOMP) 72 The simple, hop-by-hop resource reservation protocol used in this 73 framework. 75 Initiating Node (IN) 76 This is the node that initiates the resource reservation. Can be the 77 sender or receiver of data traffic or any BOOMP-aware network node. 79 Far-End Node (FEN) 80 This is the destination node to which reservations are being made. 82 Micro-Flow 83 A data flow from one end-point to another, defined uniquely by MF 84 classification [MF]. 86 Boomerang Node (BN) 87 A BOOMP-aware node which performs admission control and reservation 88 for single or aggregated micro-flows. 90 Aggregating Node (AN) 91 A Boomerang Node that associates several micro-flows with a common, 92 aggregated QoS specification and appends an aggregation field to the 93 Boomerang messages of associated micro-flows, in order to suggest an 94 aggregated reservation state for subsequent BNs. 96 2. Introduction 98 In DiffServ networks, the DS field signals the resource and 99 forwarding demands of DS Behavior Aggregates [DSARCH]. Traffic 100 Conditioner nodes - placed on the edge or inside of the DS region - 101 are responsible for enforcing the Traffic Conditioning Agreement 102 (TCA) referred by the particular DiffServ Code Point (DSCP) 103 [DSFIELD]. Although signaling protocol based interaction between 104 traffic conditioners and traffic sources were discouraged earlier, 105 there are emerging work on this topic again [DSRSVP]. 107 A simple and dynamic way of interchanging information between traffic 108 conditioners and traffic sources is to periodically insert signaling 109 packets among data packets and let them return to the traffic source 110 [TICKET]. Signaling messages can be transparently forwarded on 111 statically overprovisioned links while border nodes and upstream 112 nodes of bottleneck links can reserve resources according to the 113 message content. In this way, the source can explicitly express the 114 resource demand of a specific traffic stream in terms of bandwidth, 115 buffer or forwarding behavior and it can generate traffic according 116 to the feed-back from traffic conditioners. Using this dynamic QoS 117 approach, network operators can offer guaranteed services to 118 ambitious customers and quantitative QoS applications [E2E] in an 119 end-to-end manner. 121 Currently RSVP is the only accepted signaling protocol for resource 122 reservation setup in IP networks [RSVP] and it is probably the best 123 choice for making multicast reservation sessions. However, there are 124 several points where the handling of signaling could be simplified 125 (i.e. speeded up), if unicast sessions are considered: 127 * Reservation and path finding messages should not be separated 129 * The far end host should not be modified 131 * Network nodes should not keep track of the life-cycle of signaling 132 session, i.e. they should not store signaling states just 133 reservation states 135 * The number of message types should be kept very low 137 Therefore we propose a new reservation protocol for IP networks, 138 called Boomerang, which meets the following challenges: 140 1. Simple way for aggregating micro-flow reservation states 142 2. Simple processing of signaling messages at network nodes resulting 143 in simple implementation 145 3. Only one message type and a single signaling loop for reservation 146 set-up and tear-down 148 4. No requirements on the far end node 150 5. Concentrating the intelligence in the Initiating Node (IN). The IN 151 is responsible for signaling and maintaining the reservation 152 session. Network nodes along reserved path keep only flow states, 153 resulting in low load and processing time on network nodes. 155 The Boomerang protocol has been designed to be quick and simple, yet 156 powerful. It aims for extending the QoS mechanisms offered by DS, 157 RSVP, Int-Serv [IntServ] rather than replacing them. 159 3. Designing Objectives 161 3.1 Simple Implementation 163 In BOOMP, signaling states (meaning intelligence) are needed only in 164 the initiating node. Other BNs are 'passive' and the only requirement 165 is that they are able to interpret the Boomerang message. Therefore 166 the most complex BOOMP implementation is made locally in IN, while 167 other BNs only look-up reservation state and setup QoS treatment for 168 the flow. That also contributes to simplicity that BOOMP is focused 169 on unicast and sender oriented multicast services. 171 3.2 Small Processing Load in Routers 173 In order to decrease the context made for keeping track of the 174 reservation state of micro-flows, ANs can propose an aggregation of 175 these flow states. Consistency of micro-flow aggregation is 176 maintained by appending an aggregation field in the repeatedly 177 circulated BOOMP refresh messages. All control logic related to an 178 aggregation is concentrated in one AN, while other nodes can simply 179 rely on the information steadily coming in Boomerang messages or 180 handle micro-flow states. 182 3.3 Fast Reservation Setup 184 3.3.1 Bi-Directional Reservation 186 This implies that both the sender and the receiver node can send a 187 Boomerang, i.e. can act as IN. Many applications can not benefit from 188 receiver orientated reservations. Moreover, policy and billing may 189 suit better to sender initiated reservation in case of certain 190 applications (like broadcast video). For unicast applications BOOMP 191 can be used in a receiver oriented manner. 193 Different QoS parameters might be set up along the forward and 194 reverse path of the traffic flow. The forward and reverse path for a 195 bi-directional flow may differ. 197 3.3.2 Resource Query 199 When the Boomerang flies through the network, each BN decreases the 200 resource request field if it has less resources available for the 201 corresponding reservation. In this way the IN gets information about 202 the current network state and has a good chance to make a successful 203 reservation trial. 205 3.3.3 Single Message Loop 207 BOOMP requires only one 'signaling loop' between the IN and FEN for a 208 successful reservation. 210 3.4 Low Protocol Overhead 212 There is typically one or maximum two signaling loop required per 213 reservation session and signaling messages are small. A simple 214 calculation is given in Section 6. about the amount of signaling 215 overhead for BOOMP. 217 3.5 Robustness 219 BNs maintain reservation states as soft states, i.e. reservations 220 time out if they are not refreshed periodically. In this way orphan 221 reservations disappear automatically and routing changes have just a 222 temporary effect. 224 3.6 Quick Penetration 226 The following features results in an incremental deployment of BOOMP 227 in current IP networks. 229 3.6.1 Transparency 231 The only requirement for BOOMP-unaware nodes is to forward the BOOMP 232 messages. QoS in this node has to be ensured by another (loose or 233 tight) QoS mechanism, otherwise the end-to-end QoS can be 234 compromised. There is a prototype in which PING is used as the 235 transport mechanism of BOOMP enabling the proper behavior in the vast 236 majority of current IP-capable network devices. 238 3.6.2 QoS Interoperability 240 On the top of guaranteed resource reservation in Boomerang Nodes, 241 BOOMP can be used for asking for both tight QoS (such as the EF DSCP) 242 and loose QoS (such as AF DSCP) [EF, AF]. It is not limited to any 243 specific QoS specification, for instance it can transport Intserv 244 parameters as well. 246 3.6.3 Multiple Scope 248 There are many different way of using the Boomerang protocol for 249 resource reservation. It can be used between two hosts running 250 unicast services, either in a sender in or receiver oriented manner. 251 It can also be used for sender oriented multicast services. 253 Moreover, the scope of BOOMP can be limited to a single network 254 domain, which is connected to domains utilizing other QoS techniques. 256 3.6.4 No requirements on the Far-end Node 258 The other end-user can be quite unaware of all BOOMP implementation 259 in initiating node and network nodes and still profit from its 260 functionality. 262 4. Reservation Concept 264 4.1 Boomerang Reservation Message 266 The BOOMP reservation message contains the following fields for IPv4 267 traffic [BOOMER]: 269 * A signaling header 270 * A flow specification 271 * QoS specification 273 4.1.1 Signaling Header 275 This field contains the refresh interval and several flags in which 276 BNs can indicate the result of processing the Boomerang message. 278 The refresh interval is a measure of how often the reservation has to 279 be refreshed in order to preserve it in network nodes. The Initiating 280 Node can choose any refresh interval. Moreover, it can be decreased 281 by any router that needs a higher refresh rate. 283 If the IN stops sending refresh messages the resource allocation will 284 eventually time out. 286 4.1.2 Flow Specification 288 A BN identifies a micro-flow uniquely by five fields, found in the 289 BOOMP reservation message that sets up the flow. These fields in the 290 reservation message are: source IP address, source port number, 291 destination IP address, destination port number and the IP protocol 292 field. 294 4.1.3 QoS Specification 296 The IN indicates the type of QoS it requires with the BOOMP 297 reservation message - for the forward as well as for the reverse 298 direction. The QoS parameter specifies a service class (PHB) and 299 related resources. In our current BOOMP implementation EF PHB [EF] 300 and bit rate are used, but other formats are also possible 301 [DGVECTOR]. 303 4.1.4 Transport Mechanism 305 There are several ways for transporting the Boomerang protocol. 307 ICMP ECHO / ECHO REPLY 308 In the current prototype implementation BOOMP is wrapped in an ICMP 309 ECHO / ECHO REPLY messages, i.e. a normal PING message. This 310 conveniently ensures the correct node behavior from most existing 311 nodes both passive routers and hosts. 313 New protocol or new ICMP message 314 A cleaner implementation would be to define a new ICMP message for 315 the BOOMP primitives, or to assign an entirely new protocol for BOOMP 316 signaling. 318 In both these later cases however, we would not have the correct end- 319 node behavior for free. We would probably have to configure each 320 unaware network node to accept these messages. 322 The router alert option should be set for each Boomerang message in 323 order to indicate that the routers should investigate this message 324 [RALERT]. 326 Inbound signaling 327 A slightly different approach is to transport the reservation 328 messages as an integral part of the transport protocol. In this case 329 a transport mechanism must be defined for each transport protocol 330 where we desire to do resource reservation. This is the approach 331 taken in YESSIR [YESSIR], which is an inbound signaling protocol for 332 RTP connections. 334 4.2 Operation 336 Resource reservation with the Boomerang protocol is simple. The 337 Initiating Node (IN) sends a Boomerang message to the Far-End Node 338 (FEN) containing the desired forward and reverse QoS descriptors 339 (e.g. bit rate). When this message reaches the FEN, it is echoed back 340 to the IN. The Boomerang message follows standard routing protocols, 341 and allocates resources hop-by-hop in all Boomerang-aware nodes (BNs) 342 en route. This ensures that the reservation will be made along the 343 correct path for both upstream and downstream traffic. When IN gets 344 back the Boomerang message, it verifies the completion of the 345 reservation by examining the appropriate message flags that have been 346 set in the BOOMP message by the BNs along the way. Reservation 347 messages are then sent periodically from the IN to the FEN (the rate 348 is specified by the IN itself) to keep the reservation alive in all 349 of the nodes along the upstream and downstream paths. 351 If a reservation request is denied by a BN, the following actions are 352 taken before the reservation message is forwarded using standard 353 routing rules: 355 a) The NACK flag in the message is set 357 b) If the requested resources are greater than the available 358 resources at the current node, the QoS Specification fields of 359 the Boomerang message are updated to reflect the current lowest 360 available resources. 362 c) If the Refresh Interval in the Boomerang exceeds the network 363 node's current maximum refresh interval, it is updated to reflect 364 the current minimum refresh interval. 366 If a message arrives at the network node with the NACK flag already 367 set, only actions (b) and (c) are taken. 369 When the reservation arrives back at the IN, it checks the message to 370 see if the reservation was successful. 371 If the NACK flag is NOT set, the reservation was successful, but the 372 Refresh Interval field might still have changed. If this is the case, 373 the IN continues to send Boomerang messages with the interval stated 374 in the refresh interval field. 375 If the NACK flag is set, the request was denied somewhere along the 376 message path. This is where the IN has to take some action. A new 377 maximum QoS Specification might have been specified, so the IN may 378 choose to retry the old request, revoke it with the attained new QoS 379 specification, or release the request. 381 4.2.1 Lost Boomerang 383 If the Boomerang message does not return to the IN within a certain 384 time, it is considered to be lost. The IN can wait and repeat the 385 original request again, or downgrade the demanded resource amount and 386 request less. 388 5. Issues 390 5.1 Flow-state Aggregation 392 The Boomerang protocol requires no signaling states in the network 393 nodes, but aggregation of reservation (or flow) states is still 394 desirable. There are different ways for making flow state aggregation 395 in BOOMP. 397 5.1.1 Aggregation Suggested by Earlier Node 399 This is an extension to the Boomerang protocol, which allows a 400 microflow node to suggest a destination subnet-based aggregation to a 401 later network node. When the microflow node discovers that it has a 402 large number of reservations between two subnets it can decide to 403 append aggregation information for these subnets to each signaling 404 message within this aggregated flow. This is done by appending a 405 special message field to Boomerang containing the class, IP protocol, 406 source / destination subnetmask for this aggregation, an aggregation 407 key (e.g. the aggregating node's own IP number) and the total 408 resource demand of this aggregated flow. Nodes inside the network may 409 now use this information to create states for these aggregates of 410 micro-flows and can perform policing on these. The later node can 411 then in turn suggest further aggregation for following nodes. 413 5.1.2 Measurement Based Admission Control 415 This covers any method where no hard control is kept of the allocated 416 resources. On contrary, admission control is performed by measuring 417 the current amount of traffic in the given class. Experiments 418 indicate [MEASURE] that measurement based techniques can be made to 419 work even with long range dependant flows for a reasonably large 420 aggregation. 422 5.1.3 Refresh Message based Admission Control 424 Instead of storing hard states for keeping track of the used 425 resources, the refresh request messages can be used. By summing the 426 requested rates weighted by the refresh interval over a sliding 427 window, the node can estimate the amount of resources already 428 reserved and use this knowledge to do admission control. A similar 429 approach is proposed in [TICKET]. The accuracy of the estimate will 430 depend on the number of refresh messages within the sliding window, 431 and the node should therefore refresh a rather frequent refresh 432 interval. As with the measurement-based scheme, dynamic policeing of 433 individual flows is not possible. 435 5.2 Route Changes 437 While the issues of routing and route changes are not strictly a part 438 of the signaling problem, the questions inevitably arise. If we are 439 granted resources along a specific path, our data must stay along 440 this path or our reservation will be useless. Furthermore, if we 441 reserve resources along a path and allow these packets through 442 policing as e.g. EF PHB, a path change may ruin the performance of 443 other EF users in violation of the PHB specifications. To avoid this 444 we must either keep states at each potential bottleneck where we 445 might expect sudden route changes, or pin the route. This can be done 446 either dynamically by "freezing" the router cache entry, or by using 447 static route policies over narrow links. Our own experiences shows 448 that in a network with best effort routing, route changes are very 449 rare and are almost always triggered by a change in topology (such as 450 a link failure). The case of non topology driven route changes almost 451 always occur in the access network where the number of flows is 452 reasonably low. Refreshed reservations and soft reservation states 453 can help in most of the cases. 455 5.3 Multicasting 457 The Boomerang protocol does not distinguish individual leafs within a 458 multicast group, so the most natural way to use it in conjunction 459 with multicast would be a sender oriented scheme. The sender would 460 send the reservation request to the entire multicast group and it 461 would be up to the leafs to detect the success or failure for that 462 particular branch. A typical application could be a broadcast video 463 server similar to the pay-TV found in hotel rooms. The server would 464 send reservation messages to the multicast group with a short refresh 465 interval (e.g. 3 seconds) and the NO_ECHO flag set. When a new client 466 is added to the multicast group resource reservation is attempted 467 within one refresh interval and the client will start receiving data 468 along with either ACKed or NACKed reservations. If it receives NACKs 469 then obviously the reservation failed and it is up to the client to 470 ask to be removed from the multicast list. 472 From the perspective of the BOOMP, it is possible to ask for 473 resources for a multicast group along a specific branch. However, we 474 think that solving the complexity of multiple users depending on the 475 same reservation (accounting and such) is out of the scope of the 476 network layer. 478 5.4 Denial of Service Attacks 480 The Boomerang protocol provides a special "key" field for preventing 481 misuse of partially failed reservations. The access router could 482 easily have a rate limit mechanism per source address. This is mainly 483 an implementation issue. 485 5.5 Selective Hunting 487 The main idea is that even if the node is "Boomerang aware" we only 488 need to actually process the Boomerang messages if the node is judged 489 to be a bottleneck. The Boomerang protocol could be deactivated by 490 something like a bandwidth broker, if the node is not a bottleneck. 491 However, computers as opposed to humans do not benefit significantly 492 from resting so the main gain from deactivating the Boomerang 493 protocol would be a decrease in signaling delay. 495 5.6 Security 497 TBD. 499 5.7 Decreasing network signaling 501 There are a few issues concerning the efficiency of the protocol and 502 their possible solutions. 504 5.7.1 Signaling Overhead 506 Since the Boomerang protocol suggests refreshing of reservations with 507 intervals down to a few seconds, using it with no aggregation might 508 create a significant network load. If the refresh interval is the 509 same for a large number of sources these will not quickly decorrelate 510 if they happen to be correlated, which may result in unpleasant 511 bursts of network traffic. A small numerical example: with the very 512 short refresh interval of 3 sec and packets consisting of 56 byte 513 IPv4 Boomerang message + ICMP + IP+ Ethernet = 92 bytes we will have 514 a bitrate of 245bps. For a 12kbps IP telephony call this is about 2% 515 overhead. In practical use with longer refresh interval, the overhead 516 should be significantly less. As for the correlation, the 517 reservations are obviously initiated in an uncorrelated fashion and 518 it would therefore be quite rare that more than a few sources at a 519 time would drive into correlation. The impact of these occurrences 520 could be further reduced by letting hosts and nodes that sets the 521 refresh value randomize it in a neighborhood of the desired value. 523 5.7.2 Network loading by end to end transmission of NACKED connections 525 In the Boomerang protocol we state that all signaling is end to end. 526 This means that network nodes does not generate signaling they only 527 modify and update incoming signaling messages. The reason for this is 528 that it makes the protocol extremely simple to implement. This also 529 means that a reservation which is NACKed early in the network still 530 has to travel the entire way to the end node and back, which both 531 loads the network and increases the probability of the reservation 532 getting lost. A solution to this would be to return the NACK 533 immediately by the NACKing node. We have chosen not to do this since 534 the NACK messages are an extremely small part of the network traffic 535 and we value the simplicity of passive nodes more. Instead we treat 536 the NACKed message as a query, and update it along the path with the 537 minimum available resources. This way the returning NACK can serve as 538 decision support for the initiating node. 540 6. Illustrative scenarios 542 The multiple scopes of Boomerang based reservation process is 543 illustrated by two simple examples. 545 6.1 Single-domain with a bottleneck 547 Let us consider a scenario where we have two hosts (A, F) attached to 548 a DS domain (B-C-D-E). The DS network is non blocking for high 549 priority traffic, but there is a highly utilized link in the middle 550 (C-D) where over-provisioning is difficult or very expensive (e.g. 551 the Atlantic cable). This is a potential bottleneck link for the 552 guaranteed service. 554 A B C D E F 555 /-------------------------\ 556 | | 557 +---+ +----+ +---+ +---+ +----+ +---+ 558 |IN | | | |BN | |BN | | | |FEN| 559 +---+--| |----| |===| |----| |--+---+ 560 +---+ +----+ +---+ +---+ +----+ +---+ 561 | | 562 \-------DS domain---------/ 564 The traffic between hosts (A) and (F) has to pass through the DS 565 compliant network including the bottleneck link. Therefore one of the 566 hosts should send a BOOMP reservation request, in order to get 567 resources on the bottleneck link in a guaranteed manner. 569 Let us assume that host (A) sends a BOOMP message, which is forwarded 570 hop-by-hop through the network and echoed back by host (F). Since (B) 571 and (E) are BOOMP-unaware nodes, they just simply forward the 572 Boomerang message to the next hop. Node (C) as the ingress node of 573 the bottleneck link performs admission control for the requested 574 resources and indicates the result in the Boomerang message. 576 Similarly, node (D) performs admission control for the backward 577 traffic. It is possible to specify different amount of resources for 578 the traffic going in the forward and reverse directions, and forward 579 and reverse paths can differ. 581 Host A can then see the result of the reservation from the returned 582 BOOMP message. 584 In case of a successful reservation, host A can start to send (or 585 receive) traffic with guaranteed QoS on the bottleneck links and DS- 586 based QoS in the rest of the DS network. For the latter, data packets 587 shall be marked with proper DSCP [DSFIELD]. The initiating host 588 should refresh the reservation by sending BOOMP messages periodically 589 to prevent the soft states in the nodes from timing out. 591 6.2 End-to-end reservation with aggregation 593 SUBNET_1 SUBNET_2 595 +---+ +---+ 596 | X |\ A B C D /| Z | 597 +---+ \ +---+ +----+-+ +----+ +----+ / +---+ 598 +---+ \ | | | AN | | |BN | |BN | / +---+ 599 *---+ +--| | |--| |--| |---* 600 +---+ / +---+ +----+-+ +----+ +----+ \ +---+ 601 | Y | / \ | U | 602 +---+/ \+---+ 603 +---+ B -- aggregating node +---+ 605 Aggregation of flow states can be made, if one or more resource 606 reservations share the same QoS specifications. It can be made on a 607 subnet-to-subnet basis, and requires no special de-aggregation 608 functionality. 610 In this example, (X) and (Y) are two nodes that want to allocate 611 resources to (Z). They do this in the usual way by sending Boomerang 612 messages that will pass through (A), (B), (C) and (D), bounce at (Z) 613 and then go back, reserving bandwidth in the opposite direction. (X) 614 and (Y) send their reservations periodically, each with its own 615 refresh interval. 617 The (B) node might aggregate these reservations, since it is aware of 618 the fact that both reservations are made with source=SUBNET_1 and 619 destination=SUBNET_2. To aggregate these reservations, (B) appends an 620 aggregation field to each refresh Boomerang message that arrives from 621 (X) and (Y). This aggregation field contains the sum of resources 622 reserved for the aggregate, information that helps to identify the 623 corresponding subnets (SUBNET_1 and SUBNET_2), and a special 624 aggregation key to differentiate this aggregation from other ones 625 made between the same subnets. 627 (B) still keeps track of each reservation, it does not remove any 628 context. When the Boomerang messages leaves (B), heading for (Z), it 629 will contain this appended aggregation field and subsequent nodes may 630 use it to create contexts. 632 If (C) gets a Boomerang message from (X), with an aggregation field 633 appended, it may ignore the information about the individual flow, 634 and only create a context for the aggregation. Whenever another 635 reservation message arrives, (C) looks for aggregation fields, and 636 uses this part of the Boomerang message as a refresh message for the 637 aggregated reservation state. 639 Node (D) may, on the other hand, simply ignore these aggregation 640 fields, and treat each message as a unique reservation. If (X) then 641 stops sending refresh messages, the corresponding reservation state 642 times out in (B), and (B) updates the aggregated state to be 643 consistent with the currently reserved bandwidth. Moreover, (B) 644 indicates this change in the corresponding Boomerang messages by 645 removing the aggregation field. When the aggregation is removed 646 completely, the aggregated reservation will eventually time out in 647 (C), but by that time a new context should have been created in (C) 648 for each individual flow. 650 7. References 652 [E2E] Bernet, Y., Yavatka,r R., Ford, P., Baker, F., Nichols, 653 K., Speer, M., "A Framework for End-to-End QoS Combining 654 RSVP/Intserv and Differentiated Services", Internet 655 Draft, , March 1998. 657 [DSARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 658 and W. Weiss, "An Architecture for Differentiated 659 Services", RFC 2475, December 1998. 661 [DSFIELD] Nichols, K., Blake, S., Baker, F. and D. Black, 662 "Definition of the Differentiated Services Field (DS 663 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 664 1998. 666 [DSRSVP] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. 667 Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine 668 "A Framework for Integrated Services Operation Over 669 Diffserv Networks", Internet Draft, September 1999, 670 672 [EF] V. Jacobson, Kathleen Nichols, Kedernath Poduri, "An 673 Expedited Forwarding PHB", Internet Draft, February 1999, 674 676 [AF] F. Baker, J. Heinanen, J. Wroclawski, W. Weiss, "Assured 677 Forwarding PHB Group", Internet Draft, February 1999. 678 680 [IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services 681 in the Internet Architecture: An Overview", Internet RFC 682 1633, July 1994. 684 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, 685 S., "Resource Reservation Protocol (RSVP) Version 1 686 Functional Specification", IETF RFC 2205, Proposed 687 Standard, September 1997. 689 [YESSIR] P. Pan, H. Schulzrinne, "YESSIR: A Simple Reservation 690 Mechanism for the Internet", 691 http://www.ctr.columbia.edu/~pan/work/yessir/yessir.ps 693 [DGVECTOR] Csel�nyi, I., Szab�, R., Szab�, I., Bj�rkman, N., Latour- 694 Henner, A., "Experimental Platform for Telecommunication 695 Resource Management" Computer Communications (21)17 696 (1998) pp.1624-1640 698 [MEASURE] J.T. Lewis, R. Russell, F. Toomey, B. McGurk, S. Crosby, 699 I. Leslie, "Practical connection admission control for 700 ATM networks based on on-line measurements", Computer 701 Communications (21)17 (1998) pp. 1585-1596 703 [TICKET] A. Eriksson, C. Gehrmann, "Robust and Secure Light-weight 704 Resource Reservation for Unicast IP Traffic", 705 International WS on QoS'98, IWQoS'98, May 18-20, 1998 707 [BOOMER] D. Ahlard, J. Bergkvist, I. Csel�nyi, "Boomerang Protocol 708 Specification", Internet Draft, June 1999, Internet 709 Draft, 711 [RALERT] D. Katz, "IP router alert option", RFC 2113, IETF, 712 February 1997 714 8. Author Information 716 Bergkvist, Joakim 717 Telia Research 718 Vitsandsgatan 9B 719 S-123 86 Farsta, Sweden 720 Phone: +46 8 713 81 71 721 Email: jobe@trab.se 723 Cselenyi, Istvan 724 Telia Research 725 Vitsandsgatan 9B 726 S-123 86 Farsta, Sweden 727 Phone: +46 8 713 81 73 728 Email: cse@trab.se 730 Ahlard, David 731 Telia Research 732 Vitsandsgatan 9B 733 S-123 86 Farsta, Sweden 734 Phone: +46 8 713 81 90 735 Email: davahl@trab.se