idnits 2.17.1 draft-katsube-interop-between-lsps-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-19) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 11 instances of too long lines in the document, the longest one being 1 character 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Case 1' is mentioned on line 352, but not defined == Missing Reference: 'Case 2' is mentioned on line 366, but not defined == Missing Reference: 'Case 3' is mentioned on line 374, but not defined -- Possible downref: Normative reference to a draft: ref. 'ARIS' ** Downref: Normative reference to an Informational RFC: RFC 2098 ** Downref: Normative reference to an Informational RFC: RFC 2105 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Yasuhiro Katsube (Toshiba) 2 Hiroshi Esaki (Toshiba) 4 Interoperation Between Distinct Types of Label Switched Paths 6 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 Label Switching Routers are able to handle several distinct types 29 of Label Switched Paths (LSPs) depending on the triggers for 30 establishing or releasing LSPs or the granularity of the flow that 31 are dedicated to each of the LSPs. This memo first analyzes 32 characteristics of individual types of LSPs, and discusses possible 33 interoperation scenario between them. 35 1. Introduction 37 Routers with label switching capabilities can forward L3 packets 38 based on fixed length labels, e.g., VPI/VCI field in ATM, as well as 39 conventional packet forwarding based on L3 address information. 40 Each router manages mapping information between an incoming 41 interface(s)/label(s) and an outgoing interface(s)/label(s). 43 Label Switched Paths(LSPs) are largely classified into several types 44 which have distinct properties from the viewpoint of; "triggers for 45 establishing or releasing the LSP" and "flow granularity of the LSP". 46 With regard to triggers for establishing or releasing LSPs, following 47 three types would be possible; 49 Katsube, et al. Expires Dec. 1997 [Page 1] 50 a. Control Traffic driven 52 a1. Driven by Routing Information (Topology-driven) 53 LSPs are initiated by the creation of a new routing table 54 entry. 56 a2. Driven by Resource Reservation Messages (Reservation-driven) 57 LSPs are initiated by the reception of resource reservation 58 request messages for a specific flow. 60 b. Data Traffic driven (Data-driven) 61 LSPs are initiated by the detection of a specific data 62 packet (e.g., specific upper layers or specifig L3 addresses) 63 or by the result of measurement of data traffic. 65 A number of granularity levels (definition of "flow" which is allowed 66 to use the LSP) would be possible such as, but not limited to; 68 1. (* , egress router) ("*" means wildcard) 69 2. (* , L3_dst.prefix) 70 3. (ingress router , egress router) 71 4. (ingress router , L3_dst.prefix) 72 5. (L3_src.prefix/host , L3_dst.prefix/host) 73 6. (L3_src.host , L3_dst.host & protocol & port) 75 The former classification in terms of the "trigger" and the latter 76 one in terms of the "granularity" can be orthogonal in general, 77 although there is some dependency between them actually. 79 It is not reasonable to select only one of these alternatives but 80 several (or any) of these would co-exist depending on the 81 characteristics of the network or on the operational policy of the 82 network. An objective of this memo is to investigate characteristics 83 of individual types of LSPs and to discuss how distinct types of 84 LSPs can interoperate. 86 Discussing what should the control protocol for these switched paths 87 be is out of the scope of this memo. 89 2. Characteristics of Each Type of LSP 91 This section describes characteristics of topology-driven LSP, 92 data-driven LSP, and reservation-driven LSP. 94 Katsube, et al. Expires Dec. 1997 [Page 2] 95 2.1 Topology-driven LSP 97 Topology-driven LSPs are initiated by the creation of a new L3 98 routing table entry[ARIS][RFC2105]. They can generally accommodate 99 aggregated flow specified by, e.g., {ingress router, L3_dst.prefix}, 100 {*, L3_dst.prefix}, {ingress router, egress router}, or 101 {*, egress router}. 103 All packets, regardless of their higher layer information, can be 104 delivered from "ingress edge routers" to "egress edge routers" 105 without conventional L3 header processing in a domain. 106 Since the LSPs are established according to the creation of routing 107 table entries, packets don't have to wait for the LSP to be 108 established each time individual packet flows are generated, which 109 avoids delay for establishing LSPs as well as reduces LSP control 110 overhead due to frequent establishment or release. 112 The number of required LSPs at a domain depends on the aggregation 113 level of LSPs, availability of multipoint-to-point LSPs (LSP merge), 114 and availability of hierarchical label. When the flow is defined by 115 {ingress edge router, egress edge router} with no LSP merge assumed, 116 the number of LSPs in the domain will be the order of [the number of 117 egde routers]^2, while it will become the order of the number of edge 118 routers when the flow is defined by {*, egress edge router} with LSP 119 merge assumed. Topology-driven LSP establishment is suitable for 120 the backbone domain which handles large number of end-end flows since 121 it can provide aggregated paths regardless of the number of end-end 122 flows, and is suitable for the network with relatively large number 123 of transit routers rather than edge routers. Note that the LSP 124 merging capability is desirable for scalability in terms of the 125 number of edge routers. In order to make topology-driven LSP 126 provisioning applicable to the networks which include a number of 127 domains, hierarchical LSP configuration is strongly desirable 128 [RFC2105]. If not, issues of L3 processing bottleneck will arise at 129 domain boundary routers. 131 Topology-driven aggregated LSPs should not be extended beyond the 132 points where the processing for individual end-end flows (e.g., 133 security checking or QoS control) should be carried out. They 134 should be terminated at those points, e.g., domain border routers 135 between ISPs and customer networks. 137 With regard to bandwidth, best-effort aggregated LSPs with no 138 committed bandwidth will be provided as a default. But it would be 139 possible to provide certain bandwidth for topology-driven aggregated 140 LSPs, although it would be a kind of static bandwidth allocation like 141 least line services instead of on-demand resource allocation for 142 individual end-end flows. The amount of necessary bandwidth for 143 the aggregated LSPs should be properly estimated taking the tradeoff 145 Katsube, et al. Expires Dec. 1997 [Page 3] 146 between cost for bandwidth and provision of enough bandwidth to avoid 147 LSP congestion into account. Note that point-point LSP mesh 148 configuration with no LSP merge would be adequate for ease of traffic 149 control, although it has a scaling problem with regard to the number 150 of LSPs. 152 Even if some amount of configured bandwidth is allocated to the 153 aggregated LSP, packet level priority control or scheduling should be 154 carried out at the ingress point of the LSP in order to differentiate 155 end-end quality of services among flows which share the same LSP, or 156 in order to avoid congestion of the LSP because of the mis-behavior 157 of a certain flow. That requires ingress routers higher performance 158 and sophisticated packet processing functionality. 160 2.2 Data-driven LSP 162 Data-driven LSPs are initiated by the detection of a specific data 163 packet (e.g., specific upper layers) or by the result of measurement 164 of the data traffic[RFC2098]. Currently available control protocols 165 for data-driven LSPs are suitable for accommodating fine granularity 166 flows defined by, e.g., {L3_src.host, L3_dst.host} or {L3_src.host, 167 L3_dst.host, dst.protocol/port}. 169 Only the specific packet flow (based on their L3 or upper layer 170 information) are delivered from an ingress edge router (or hosts) to 171 an egress edge routers (or hosts) without conventional L3 header 172 processing. You should wait for the LSPs to be established each 173 time individual packet flow are generated, which may cause delay for 174 establishing LSPs, and may cause largeer LSP control overhead due to 175 frequent establishment or release. 177 The number of required LSPs at a domain does not depend on the number 178 of edge routers or hosts, but on the number of active end-to-end 179 flows. Data-driven, fine granularity LSP establishment, therefore, 180 is suitable for the domain in which there are relatively large number 181 of edge routers but traffic is not evenly dispersed among them. 182 It would not be adequate for large scale networks which accommodate 183 large number of end-end flows. 185 Establishing LSPs accommodating aggregated flow as shown in section 186 2.1 by the trigger of data packet arrival may be useful for reducing 187 the number of LSPs, though the issue of LSP setup latency may still 188 remain. 190 Data-driven LSPs would be useful at the point where the processing 191 for individual end-end flows (e.g., security checking or QoS 192 control) should be carried out, e.g., border routers between the ISP 193 and the customer network. The routers with data-driven LSP control 195 Katsube, et al. Expires Dec. 1997 [Page 4] 196 capability can check initial packet of individual end-end flow 197 through conventional packet processing, then they can establish the 198 LSPs if they lend themselves to such. 200 With regard to bandwidth, best-effort LSPs with no committed 201 bandwidth will be provided as a default for individual end-end 202 flows. But it would be possible to provide certain bandwidth for 203 data-driven end-end LSPs without using L3 resource reservation 204 mechanism (e.g., RSVP) although it would be a kind of static 205 bandwidth allocation like dial-up circuit services. 206 However it cannot provide individual end-end flow with optimal 207 bandwidth or QoS, it enables to avoid serious degradation of end-end 208 quality even in the congested state without wide deployment of L3 209 resource reservation protocol. 211 The amount of necessary bandwidth for those LSPs becomes the sum of 212 bandwidth for individual LSPs. That enables to reduce necessary 213 bandwidth compared with providing static bandwidth for topology- 214 driven aggregated LSPs regardless of actual traffic pattern, 215 and avoids any effect of the mis-behavior of a certain flow to any 216 other flows sharing the same ingress/egress edge routers without 217 using sophisticated L3 processing capability. 219 2.3 Reservation-driven LSP 221 Reservation-driven LSPs are initiated by the reception of L3 resource 222 reservation requests for a specific end-end flow. The granularity 223 levels of the reservation-driven LSPs depends on the flow granularity 224 indicated by the resource reservation messages. In the case of RSVP 225 version 1, for instance, fine granularity such as {L3_src.host, 226 L3_dst.host, dst.protocol/port} is used as a default. 228 In large scale networks which accommodate a large number of hosts, 229 namely a large number of end-end flows with bandwidth request, each 230 router will have to maintain extremely huge amount of states of 231 reservation flows, which may cause some limitation in the size of the 232 networks. This scalability issue may be resolved if the resource 233 reservation protocol is revised to be able to handle aggregation; a 234 reservation for a group of flows. 236 3. Interoperation of Distinct Type of LSPs 238 According to analyses described above, it can be said that the 239 topology-driven LSP which conveys aggregated flow, the data-driven 240 LSP which is dedicated to a specific end-end flow, and reservation- 241 driven LSP which is also dedicated to a specific end-end flow have 243 Katsube, et al. Expires Dec. 1997 [Page 5] 244 their own applicable areas. 246 Several possible relationships between topology-driven aggregated 247 LSPs and data-driven more specific LSPs (with/without certain 248 bandwidth) are described in this section. 250 It is assumed, in figure 1, that AS-a and AS-c are capable of 251 establishing Data-driven LSPs for selected end-end flows (specified 252 by {L3_src.host, L3_dst.host}), while AS-b provides topology-driven 253 LSP mesh for aggregated flows. AS-b actually can be multiple ASs, 254 which constitute hierarchically configured LSPs. 255 Note that the topology-driven LSPs can be extended to include AS 256 border router BR-a4 and BR-c4 provided that they can handle topology- 257 driven LSP control protocols. In that case, the topology-driven LSP 258 is originated at BR-a4 and is terminated at BR-c4. 259 The ER denotes Edge Router which accommodates non-LSP capable devices 260 and terminates LSPs. It can be hosts which is capable of handling 261 LSPs also. The IR and BR denote Internal Router and AS Border Router 262 respectively. 264 Three scenarios regarding the operational relationship between these 265 ASs are shown below. 267 [Case 1] L3 Interworking with Optional Merging at Aggregation Point 269 Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are 270 assumed to have capabilities to originate or terminate data-driven 271 LSPs in this case. That means that BR-b1 and BR-b3 should participate 272 in the data-driven LSP control protocol operated in AS-a and AS-c 273 respectively. 274 (As already noted, the termination points of topology-driven LSP can 275 be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4) 276 respectively) 278 As shown in figure 1, the egress router BR-a4 at AS-a and the ingress 279 router BR-c4 at AS-c can switch packets instead of L3 processing if 280 they like. In addition, BR-b1 at the ingress point of the 281 topology-driven AS-b is able to switch packets received from 282 data-driven LSPs (ER-a1 -> IR-a3 -> BR-a4 -> BR-b1, and ER-a2 -> 283 IR-a3 -> BR-a4 -> BR-b1) without L3 processing into the 284 topology-driven LSP (BR-b1 -> IR-b2 -> BR-b3), which is regarded as 285 "merging" of LSPs. This is because the granularity of the data- 286 driven LSPs is finer than the granularity of the topology-driven 287 LSP. Note that the BR-b1 should be able to handle multipoint-to- 288 point merging of LSPs. (e.g., ATM switch should avoid cell level 289 interleaving among distinct packets). 291 Above-mentioned switched forwarding capability does not apply to the 293 Katsube, et al. Expires Dec. 1997 [Page 6] 294 BR-b3 which is the termination point of the topology-driven aggregated 295 LSP and the origination point of the data-driven LSP with finer flow 296 granularity, but L3 processing is needed. 298 [Case 2] Data-driven LSP over Topology-driven LSP Tunnel 300 Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are 301 assumed to have capabilities to originate, terminate, and relay 302 data-driven LSPs in this case. In addition, BR-b1 is assumed to 303 memorizes that it has a topology-driven aggregated LSP dedicated to 304 the flow specified by {BR-b1, BR-b3} toward BR-b3. 305 (As already noted, the termination points of topology-driven LSP can 306 be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4) 307 respectively) 309 When BR-b1 wants to set up a data-driven LSP dedicated to a flow 310 specified by {H1, H3} or {H2, H4}, it exchanges a data-driven LSP 311 control message with BR-b3 which is a logical neighbor with the 312 support of topology-driven LSP from BR-b1 to BR-b3. Then the 313 data-driven LSP is established from ER-a1 (or ER-a2) to ER-c1 (or 314 ER-c2) by passing through the topology-driven aggregated LSP as a 315 tunnel. 317 This can be regarded as a hierarchical LSP configuration with two 318 levels of label; one applied by ER-a1 or ER-a2 for the {H1, H3} or 319 the {H2, H4} flow and the other applied by BR-b1 for the topology- 320 driven tunnel toward BR-b3. This enables configuration of end-to-end 321 data-driven LSPs without having internal routers in topology-driven 322 network be aware of dara-driven LSP control protocol. 324 [Case 3] Data-driven LSP independent of Topology-driven LSP Tunnel 326 Bandwidth allocation for LSPs dedicated to end-end flow may be 327 supported over topology-driven aggregated LSPs, or may be supported 328 independent of topology-driven LSPs. 330 The former case is regarded as an extension of Case 2, and requires 331 topology-driven LSPs to be given a proper amount of bandwidth. 332 Bandwidth of the topology-driven LSP should be managed to avoid 333 overload of itself. Dynamic changes of allocated bandwidth of 334 topology-driven LSPs in response to their usage may be useful if it 335 is possible. 337 In the latter case; Case 3; there is no interoperation between 338 the topology-driven LSP and the data-driven LSP. The topology-driven 339 aggregated LSPs do not have to be given certain bandwidth, although 340 additional number of LSPs for end-end flow with certain bandwidth 342 Katsube, et al. Expires Dec. 1997 [Page 7] 343 Data-driven Topology-driven Data-driven 344 (AS-a) (AS-b) (AS-c) 345 <--------------> <--------------> <--------------> 346 H1--ER ER--H3 347 (a1) IR BR BR IR BR BR IR (c1) 348 (a3) (a4) (b1) (b2) (b3) (c4) (c3) 349 H2--ER ER--H4 350 (a2) (c2) 352 [Case 1] L3 Interworking with Optional Merging at Aggregation Point 354 (for {H1,H3}) (for {H1,H3}) 355 L3-----::-----::----- -----::-----::-----L3 356 L3=====::=====L3 357 L3-----::-----::----- (for{b1,b3}) -----::-----::-----L3 358 (for {H2,H4}) (for {H2,H4}) 360 (for {H1,H3}) (for {H1,H3}) 361 L3-----::-----::-----\ -----::-----::-----L3 362 ::=====::=====L3 363 L3-----::-----::-----/ (for{b1,b3}) -----::-----::-----L3 364 (for {H2,H4}) (for {H2,H4}) 366 [Case 2] Data-driven LSP over Topology-driven LSP Tunnel 368 (for {H1,H3}) (for {H1,H3}) 369 L3-----::-----::-----:: tunnel ::-----::-----::-----L3 370 =====::===== 371 L3-----::-----::-----::(for{b1,b3})::-----::-----::-----L3 372 (for {H2,H4}) (for {H2,H4}) 374 [Case 3] Data-driven LSP independent of Topology-driven LSP 376 (for {H1,H3}) (for {H1,H3}) 377 L3-----::-----::-----::-----::-----::-----::-----::-----L3 378 =====::===== 379 L3-----::-----::-----::-----::-----::-----::-----::-----L3 380 (for {H2,H4}) (for {H2,H4}) 382 # "::" denotes switched forwarding. 383 # ------::------ Data-driven LSP 384 # ======::====== Topology-driven LSP 386 Figure 1 388 Katsube, et al. Expires Dec. 1997 [Page 8] 389 should be controlled in AS-b independent of the existense of the 390 topology-driven aggregated LSPs. 391 (Reservation-driven LSPs will also be controlled independent of the 392 existense of the topology-driven best-effort LSPs) 394 In this case, all the LSRs in AS-b should be able to handle both 395 topology-driven and data-driven LSPs. 397 5. Security Considerations 399 Security considerations are not addressed in this memo. 401 6. Acknowledgement 403 I would like to thank Yakov Rekhter and Paul Doolan for their help 404 and suggestions in writing this document. 406 7. References 408 [ARIS] R.Woundy, A.Wiswanathan, N.Feldman, R.Biovie, "ARIS: 409 Aggregated Route-Based IP Switching", 410 draft-woundy-aris-ipswitching-00.txt, November, 1996. 411 [RFC2098] Y.Katsube, K.Nagami, H.Esaki, "Toshiba's Router 412 Extensions for ATM", IETF RFC2098, February, 1997. 413 [RFC2105] Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow, 414 "Cisco System's Tag Switching Overview", IETF RFC2105, 415 February, 1997. 417 8. Authors' Addresses 419 Yasuhiro Katsube 420 R&D Center, Toshiba Corporation, 421 1 Komukai-Toshiba-cho, Saiwai-ku, 422 Kawasaki, 210, Japan 423 Email: katsube@isl.rdc.toshiba.co.jp 425 Hiroshi Esaki 426 Computer and Network Division, 427 Toshiba Corporation, 428 1-1-1 Shibaura, 429 Minato-ku, 105-01, Japan. 430 Email: hiroshi@isl.rdc.toshiba.co.jp 432 Katsube, et al. Expires Dec. 1997 [Page 9]