idnits 2.17.1 draft-ohta-rsvp-friendly-hop-path-00.txt: 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-04-26) 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 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 1996) is 10024 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) == Unused Reference: 'PIM' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RSVP' is defined on line 284, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT M. Ohta 2 draft-ohta-rsvp-friendly-hop-path-00.txt Tokyo Institute of Technology 3 Y. Goto 4 Institute of Systems & Information Technologies/KYUSHU 5 and Kyushu University 6 November 1996 8 Path QoS Collection for RSVP-friendly Hop-by-hop QoS Routing 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 24 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 QoS routing needs some stabilization mechanism to prevent a delayed 31 negative feedback on the link QoS information by the routed traffic. 33 So far, route pinning was the only known way of the stabilization. 35 But, as RSVP merges multiple RESV messages to create a new one, 36 pinned route computed elsewhere for different QoS requirement is not 37 useful after the merge. 39 That is, we need a sticky hop-by-hop QoS routing algorithm. 41 Path QoS Collection is such an algorithm to collect true upstream 42 link QoS in PATH messages to correct the link QoS information 43 distributed by QoS routing protocols. 45 1. Introduction 47 Path QoS Collection is a fully distributed soft state mechanism for 48 QoS routing to accumulate QoS information of links in Path_msg of 49 RSVP (Resource Reservation Protocol). Using link state information 50 distributed with a QoS routing protocol along with the Path QoS 51 Collection, receivers and intermediate routers can stably choose the 52 best route with the required QoS hop-by-hop in a distributed and 53 scalable manner for unicast and multicast communications over the 54 Internet. 56 With RSVP, resource reservations are initiated by receivers with 57 Resv_msgs toward the sender because the QoS requirements may be 58 different receiver by receiver and only receivers know their 59 requirement. To avoid that Resv_msgs concentrate at the sender, 60 RSVP-capable routers merge incoming Resv_msgs to form a new Resv_msg 61 and send it toward the sender. To merge Resv_msgs with different QoS 62 requirements, the largest requirement is chosen to form a merged 63 Resv_msg. Since RSVP does not adopt QoS routing protocol yet, a 64 sender sends a Path_msg to receivers so that intermediate routers can 65 know the direction of Reverse Path Forwarding of Resv_msgs. But, 66 without QoS routing, we may not be able to use available resource. 67 For example, in Figure-1, the shortest path between R1 and S is S-C- 68 B-R1. So, with a simple shortest path routing, a bandwidth 69 requirement of 15 can not be warranted, even though a longer path S- 70 F-E-D-A-B-R1 can satisfy the requirement. 72 +--+ 73 +--+R1| 74 20| +--+ 75 +--+ +---+ 25 +-+-+ 10 +---+ 10 +---+ 76 |R0|----| A |-----+ B +------+ C |-----| S | A,B,C,D,E,F: Router 77 +--+ 30 +-+-+ +---+ +---+ +-+-+ S: Sender 78 | +---+ +---+ +---+ | R0, R1: Receiver 79 +----+ D |----+ E |----+ F |---+ Number: Available 80 18 +---+ 20 +---+ 30 +---+ 20 Bandwidth 82 Figure-1 84 Therefore, some QoS routing protocol, which distributes information 85 to routers and receivers about which path to follow, is necessary for 86 RSVP. To quickly reflect the changes of the state of the network such 87 as available bandwidth, which changes a lot more often than binary 88 up/down state of a link, QoS routing protocol should adopt Link State 89 Routing Algorithm such as OSPF. 91 But, simple-minded QoS routing has a stability problem. In Figure-1, 92 if R0 requires QoS of Bandwidth 9, a path S-C-B-A-R0 will be chosen. 93 The link state of Figure-1 changes into that of Figure-2. That is, 94 link S-C and C-B have Bandwidth of only 1. Unless R0 knows that the 95 link state has changed because of the flow of its own request, R0 96 will think that the only path that satisfy the Bandwidth requirement 97 of the flow is S-F-E-D-A-R0 and stop using the path S-C-B-A-R0. But, 98 then, link state on the path S-C-B-A turns back to link state of 99 Figure-1, and R0 will select the path S-C-B-A-R0 again. And such 100 route flapping is repeated forever resulting in an unstable routing. 102 +--+ 103 +--+R1| A,B,C,D,E,F: Router 104 20| +--+ S: Sender 105 +--+ +---+ 16 +-+-+ 1 +---+ 1 +---+ R0, R1: Receiver 106 |R0|----| A |-----+ B +------+ C |-----| S | Number: Available 107 +--+ 21 +-+-+ +---+ +---+ +-+-+ Bandwidth 108 | | 109 | +---+ +---+ +---+ | 110 +----+ D |----+ E |----+ F |---+ 111 18 +---+ 20 +---+ 30 +---+ 20 113 Figure-2 115 Route Pinning is an existing method to stabilize routing. A receiver 116 finds the best path, notifies it to routers on the path, and the 117 routers use the specified path. In Figure-1, as the receiver knows 118 that the path S-C-B-A-R0 is used by its own flow, it can cancel the 119 effect of the flow from the advertised link state of Figure-2 to 120 reconstruct the original link state of Figure-1. 122 The problem of Route Pinning is that it's not good for multicast. For 123 example, in Figure-1, if R0 requests a path S-C-B-A-R0 of bandwidth 9 124 and R1 requests a path S-F-E-D-A-B-R1 of bandwidth 15, it is not 125 naturally possible to merge Resv_msgs with different path 126 specifications. That is, there will be two redundant data streams. If 127 Resv_msgs are forcibly merged on the router B, then a new path should 128 be computed by the router B. As a result, the path S-F-E-D-A-R0 would 129 be selected which contradicts with R0's idea of the flow. 131 2. Path QoS Collection and Path QoS Correction 133 To solve the problem, path recomputation at the multicast merge 134 points is seemingly inevitable. 136 That is, we must have a sticky hop-by-hop QoS routing algorithm. 138 If a QoS routing protocol distributes detailed link state about which 139 flow consumes how much resource on each link, each hop can fully 140 reconstruct a real resource usage and we can have a sticky QoS 141 routing. But, obviously, such a routing protocol distributes too much 142 routing information to be scalable. 144 But, looking closely at the feedback problem, the feedback loop is 145 formed through upstream resource consumption. That is, to make 146 routing sticky, we don't have to resonctruct downstream resource 147 consumption. 149 For the correction of upstream information only, Path_msgs can, 150 naturally, carry upstream resource consumption information to break 151 the loop for sticky QoS routing. 153 That is, Path QoS Collection stabilizes fully distributed hop-by-hop 154 route computation. 156 The simple hop-by-hop method is unstable because the receivers and 157 the intermediate routers can't know which link state information is 158 affected by their own flow. With Path QoS Collection, QoS information 159 on links from the ender to the receivers are collected in a Path_msg. 160 Thus, even if the link state information of Figure 2 is distributed 161 through some QoS routing protocol, the receivers and the intermediate 162 routers can reconstruct state of Figure 1, for the upstream links 163 toward the sender. For example, between S and R0, Resv_msgs are added 164 the amount of QoS consumed by the flow on each link. The router C 165 receives ({S-C},9), the router B ({S-C,9}, {C-B,9}), the router A 166 ({S-C,9}, {C-B,9}, {B-A,9}) and the receiver R0 ({S-C,9}, {C-B,9}, 167 {B-A,9}, {A-R0,9}). 169 Then, the forwarding direction of Resv_msg is decided distributedly 170 by individual routers and receivers with the corrected link state. 172 It should be noted that hop-by-hop QoS routing solves the killer 173 reservation problem. As individual routers know which Resv_msg can't 174 be satisfied, killer reservations are bounced before being merged by 175 satisfyable reservations. 177 Figure-3 illustrates the router B's view of the corrected QoS 178 information. 180 +--+ 181 +--+R1| A,B,C,D,E,F: Router 182 20| +--+ S: Sender 183 +--+ +---+ 16 +-+-+ 10 +---+ 10 +---+ R0, R1: Receiver 184 |R0|----| A |-----+ B +------+ C |-----| S | Number: Available 185 +--+ 21 +-+-+ +---+ +---+ +-+-+ Bandwidth 186 | | 187 | +---+ +---+ +---+ | 188 +----+ D |----+ E |----+ F |---+ 189 18 +---+ 20 +---+ 30 +---+ 20 191 Figure-3 193 Router B knows that, without the flow, the path S-C-B has bandwidth 194 of 10, not 1. 196 While the QoS information on downstream links R0-A-B is not 197 corrected, it increases the stability of the route and is not a 198 problem. 200 The amount of the collected Path QoS Collection information in a 201 Path_msg is proportional to the length of the path. That is, only as 202 much as the amount of the information necessary for Route Pinning in 203 Resv_msg and is not a problem. 205 3. Multicasting with Path QoS Collection 207 Merged Resv_msg for multicast, of course, is not an exception and 208 forwarded toward the sender over a path that satisfies the new QoS 209 requirement. 211 Suppose that, R0 wants bandwidth of 9 and R1 12. 213 Then, Resv_msg from R0 (intended to follow a path R0-A-B-C-S) and 214 Resv_msg from R1 (intendet to follow a path R1-B-A-D-E-F-S) is merged 215 on Router A to be a bandwidth requirement of 12. 217 Then, router A locally decides that the merged Resv_msg should follow 218 a path A-D-E-F-S. 220 Figure-4 illustrate such an situation. 222 Note that the receiver R0 will receive Path QoS Collection 223 information of ({S-F,12}, {F-E,12), {E-D,12}, {D-A,12}, {A-R0,9}). 225 +--+ 226 +--+R1| A,B,C,D,E,F: Router 227 8| +--+ S: Sender 228 +--+ +---+ 13 +-+-+ 10 +---+ 10 +---+ R0, R1: Receiver 229 |R0|----| A |-----+ B +------+ C |-----| S | Number: Available 230 +--+ 12 +-+-+ +---+ +---+ +-+-+ Bandwidth 231 | | 232 | +---+ +---+ +---+ | 233 +----+ D |----+ E |----+ F |---+ 234 6 +---+ 8 +---+ 18 +---+ 8 236 Figure-4 238 4. Protocol Extensions 240 First of all, we need a new field, "Path QoS", in Path_msg. 242 Secondly, Resv_msg shouldn't follow reverse path established by 243 Path_msg. Instead, Path_msgs should follow forward path established 244 by Resv_msg. Resv_msg should work something like PIM_join. 246 Exact details of what and how QoS information should be collected 247 needs further discussion. 249 For example, it may be better to collect corrected link QoS state on 250 each link than to collect consumed QoS and correct it on each router. 252 For hierarchical routing, QoS may still be collected hop-by-hop or 253 QoS information in a lower hierarchy may be aggregated in upper 254 hierarchy. 256 Path QoS field and QoS routing protocol should have common time stamp 257 (local to the router which originate the information) to suppress 258 race conditions. 260 5. Requirement and Suggestions for Routing Protocol 262 As Path QoS correction is performed on link state information, 263 unicast routing protocol must be that of link state type. 265 Moreover, to suppress unnecessarily frequent link state updates, new 266 link state should be advertised only when the amount of available 267 resource is below the current advertised value, considerably above 268 the current advertised value or long enough time has passed since the 269 last update. 271 It is suggested that, when the amount of available resource is 272 reducing, the advertised value should be a little less than the 273 exactly available amount. 275 Any multicast routing protocol may be used to forward Resv_msgs. 277 Path_msgs and data streams should be forwarded to the reverse 278 direction to that established by the Resv_msgs. 280 6. References 282 [PIM] 284 [RSVP] 286 7. Security Considerations 288 (to be provided) 290 8. Authors' Addresses 292 Masataka Ohta 293 Computer Center 294 Tokyo Institute of Technology 295 2-12-1, O-okayama, Meguro-ku 296 Tokyo 152, JAPAN 298 Phone: +81-3-5734-3299 299 Fax: +81-3-5734-3415 300 EMail: mohta@necom830.hpcl.titech.ac.jp 302 Yukinori GOTO 303 Institute of Systems & Information Technologies/KYUSHU 304 and Kyushu University. 305 Fukuoka SRP Center Building 7F 306 2-1-22-707, Momochihama , 307 Sawara-ku, Fukuoka City 814, JAPAN 309 Phone: +81-92-852-3460 310 Fax: +81-92-852-3465 311 E-mail: yuki@k-isit.or.jp