Internet Draft Internet Draft June 1997 Yasuhiro Katsube (Toshiba) Hiroshi Esaki (Toshiba) Interoperation Between Distinct Types of Label Switched Paths <draft-katsube-interop-between-lsps-00.txt> Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Label Switching Routers are able to handle several distinct types of Label Switched Paths (LSPs) depending on the triggers for establishing or releasing LSPs or the granularity of the flow that are dedicated to each of the LSPs. This memo first analyzes characteristics of individual types of LSPs, and discusses possible interoperation scenario between them. 1. Introduction Routers with label switching capabilities can forward L3 packets based on fixed length labels, e.g., VPI/VCI field in ATM, as well as conventional packet forwarding based on L3 address information. Each router manages mapping information between an incoming interface(s)/label(s) and an outgoing interface(s)/label(s). Label Switched Paths(LSPs) are largely classified into several types which have distinct properties from the viewpoint of; "triggers for establishing or releasing the LSP" and "flow granularity of the LSP". With regard to triggers for establishing or releasing LSPs, following three types would be possible; Katsube, et al. Expires Dec. 1997 [Page 1] Internet Draft Interoperation Between LSPs June 1997 a. Control Traffic driven a1. Driven by Routing Information (Topology-driven) LSPs are initiated by the creation of a new routing table entry. a2. Driven by Resource Reservation Messages (Reservation-driven) LSPs are initiated by the reception of resource reservation request messages for a specific flow. b. Data Traffic driven (Data-driven) LSPs are initiated by the detection of a specific data packet (e.g., specific upper layers or specifig L3 addresses) or by the result of measurement of data traffic. A number of granularity levels (definition of "flow" which is allowed to use the LSP) would be possible such as, but not limited to; 1. (* , egress router) ("*" means wildcard) 2. (* , L3_dst.prefix) 3. (ingress router , egress router) 4. (ingress router , L3_dst.prefix) 5. (L3_src.prefix/host , L3_dst.prefix/host) 6. (L3_src.host , L3_dst.host & protocol & port) The former classification in terms of the "trigger" and the latter one in terms of the "granularity" can be orthogonal in general, although there is some dependency between them actually. It is not reasonable to select only one of these alternatives but several (or any) of these would co-exist depending on the characteristics of the network or on the operational policy of the network. An objective of this memo is to investigate characteristics of individual types of LSPs and to discuss how distinct types of LSPs can interoperate. Discussing what should the control protocol for these switched paths be is out of the scope of this memo. 2. Characteristics of Each Type of LSP This section describes characteristics of topology-driven LSP, data-driven LSP, and reservation-driven LSP. Katsube, et al. Expires Dec. 1997 [Page 2] Internet Draft Interoperation Between LSPs June 1997 2.1 Topology-driven LSP Topology-driven LSPs are initiated by the creation of a new L3 routing table entry[ARIS][RFC2105]. They can generally accommodate aggregated flow specified by, e.g., {ingress router, L3_dst.prefix}, {*, L3_dst.prefix}, {ingress router, egress router}, or {*, egress router}. All packets, regardless of their higher layer information, can be delivered from "ingress edge routers" to "egress edge routers" without conventional L3 header processing in a domain. Since the LSPs are established according to the creation of routing table entries, packets don't have to wait for the LSP to be established each time individual packet flows are generated, which avoids delay for establishing LSPs as well as reduces LSP control overhead due to frequent establishment or release. The number of required LSPs at a domain depends on the aggregation level of LSPs, availability of multipoint-to-point LSPs (LSP merge), and availability of hierarchical label. When the flow is defined by {ingress edge router, egress edge router} with no LSP merge assumed, the number of LSPs in the domain will be the order of [the number of egde routers]^2, while it will become the order of the number of edge routers when the flow is defined by {*, egress edge router} with LSP merge assumed. Topology-driven LSP establishment is suitable for the backbone domain which handles large number of end-end flows since it can provide aggregated paths regardless of the number of end-end flows, and is suitable for the network with relatively large number of transit routers rather than edge routers. Note that the LSP merging capability is desirable for scalability in terms of the number of edge routers. In order to make topology-driven LSP provisioning applicable to the networks which include a number of domains, hierarchical LSP configuration is strongly desirable [RFC2105]. If not, issues of L3 processing bottleneck will arise at domain boundary routers. Topology-driven aggregated LSPs should not be extended beyond the points where the processing for individual end-end flows (e.g., security checking or QoS control) should be carried out. They should be terminated at those points, e.g., domain border routers between ISPs and customer networks. With regard to bandwidth, best-effort aggregated LSPs with no committed bandwidth will be provided as a default. But it would be possible to provide certain bandwidth for topology-driven aggregated LSPs, although it would be a kind of static bandwidth allocation like least line services instead of on-demand resource allocation for individual end-end flows. The amount of necessary bandwidth for the aggregated LSPs should be properly estimated taking the tradeoff Katsube, et al. Expires Dec. 1997 [Page 3] Internet Draft Interoperation Between LSPs June 1997 between cost for bandwidth and provision of enough bandwidth to avoid LSP congestion into account. Note that point-point LSP mesh configuration with no LSP merge would be adequate for ease of traffic control, although it has a scaling problem with regard to the number of LSPs. Even if some amount of configured bandwidth is allocated to the aggregated LSP, packet level priority control or scheduling should be carried out at the ingress point of the LSP in order to differentiate end-end quality of services among flows which share the same LSP, or in order to avoid congestion of the LSP because of the mis-behavior of a certain flow. That requires ingress routers higher performance and sophisticated packet processing functionality. 2.2 Data-driven LSP Data-driven LSPs are initiated by the detection of a specific data packet (e.g., specific upper layers) or by the result of measurement of the data traffic[RFC2098]. Currently available control protocols for data-driven LSPs are suitable for accommodating fine granularity flows defined by, e.g., {L3_src.host, L3_dst.host} or {L3_src.host, L3_dst.host, dst.protocol/port}. Only the specific packet flow (based on their L3 or upper layer information) are delivered from an ingress edge router (or hosts) to an egress edge routers (or hosts) without conventional L3 header processing. You should wait for the LSPs to be established each time individual packet flow are generated, which may cause delay for establishing LSPs, and may cause largeer LSP control overhead due to frequent establishment or release. The number of required LSPs at a domain does not depend on the number of edge routers or hosts, but on the number of active end-to-end flows. Data-driven, fine granularity LSP establishment, therefore, is suitable for the domain in which there are relatively large number of edge routers but traffic is not evenly dispersed among them. It would not be adequate for large scale networks which accommodate large number of end-end flows. Establishing LSPs accommodating aggregated flow as shown in section 2.1 by the trigger of data packet arrival may be useful for reducing the number of LSPs, though the issue of LSP setup latency may still remain. Data-driven LSPs would be useful at the point where the processing for individual end-end flows (e.g., security checking or QoS control) should be carried out, e.g., border routers between the ISP and the customer network. The routers with data-driven LSP control Katsube, et al. Expires Dec. 1997 [Page 4] Internet Draft Interoperation Between LSPs June 1997 capability can check initial packet of individual end-end flow through conventional packet processing, then they can establish the LSPs if they lend themselves to such. With regard to bandwidth, best-effort LSPs with no committed bandwidth will be provided as a default for individual end-end flows. But it would be possible to provide certain bandwidth for data-driven end-end LSPs without using L3 resource reservation mechanism (e.g., RSVP) although it would be a kind of static bandwidth allocation like dial-up circuit services. However it cannot provide individual end-end flow with optimal bandwidth or QoS, it enables to avoid serious degradation of end-end quality even in the congested state without wide deployment of L3 resource reservation protocol. The amount of necessary bandwidth for those LSPs becomes the sum of bandwidth for individual LSPs. That enables to reduce necessary bandwidth compared with providing static bandwidth for topology- driven aggregated LSPs regardless of actual traffic pattern, and avoids any effect of the mis-behavior of a certain flow to any other flows sharing the same ingress/egress edge routers without using sophisticated L3 processing capability. 2.3 Reservation-driven LSP Reservation-driven LSPs are initiated by the reception of L3 resource reservation requests for a specific end-end flow. The granularity levels of the reservation-driven LSPs depends on the flow granularity indicated by the resource reservation messages. In the case of RSVP version 1, for instance, fine granularity such as {L3_src.host, L3_dst.host, dst.protocol/port} is used as a default. In large scale networks which accommodate a large number of hosts, namely a large number of end-end flows with bandwidth request, each router will have to maintain extremely huge amount of states of reservation flows, which may cause some limitation in the size of the networks. This scalability issue may be resolved if the resource reservation protocol is revised to be able to handle aggregation; a reservation for a group of flows. 3. Interoperation of Distinct Type of LSPs According to analyses described above, it can be said that the topology-driven LSP which conveys aggregated flow, the data-driven LSP which is dedicated to a specific end-end flow, and reservation- driven LSP which is also dedicated to a specific end-end flow have Katsube, et al. Expires Dec. 1997 [Page 5] Internet Draft Interoperation Between LSPs June 1997 their own applicable areas. Several possible relationships between topology-driven aggregated LSPs and data-driven more specific LSPs (with/without certain bandwidth) are described in this section. It is assumed, in figure 1, that AS-a and AS-c are capable of establishing Data-driven LSPs for selected end-end flows (specified by {L3_src.host, L3_dst.host}), while AS-b provides topology-driven LSP mesh for aggregated flows. AS-b actually can be multiple ASs, which constitute hierarchically configured LSPs. Note that the topology-driven LSPs can be extended to include AS border router BR-a4 and BR-c4 provided that they can handle topology- driven LSP control protocols. In that case, the topology-driven LSP is originated at BR-a4 and is terminated at BR-c4. The ER denotes Edge Router which accommodates non-LSP capable devices and terminates LSPs. It can be hosts which is capable of handling LSPs also. The IR and BR denote Internal Router and AS Border Router respectively. Three scenarios regarding the operational relationship between these ASs are shown below. [Case 1] L3 Interworking with Optional Merging at Aggregation Point Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are assumed to have capabilities to originate or terminate data-driven LSPs in this case. That means that BR-b1 and BR-b3 should participate in the data-driven LSP control protocol operated in AS-a and AS-c respectively. (As already noted, the termination points of topology-driven LSP can be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4) respectively) As shown in figure 1, the egress router BR-a4 at AS-a and the ingress router BR-c4 at AS-c can switch packets instead of L3 processing if they like. In addition, BR-b1 at the ingress point of the topology-driven AS-b is able to switch packets received from data-driven LSPs (ER-a1 -> IR-a3 -> BR-a4 -> BR-b1, and ER-a2 -> IR-a3 -> BR-a4 -> BR-b1) without L3 processing into the topology-driven LSP (BR-b1 -> IR-b2 -> BR-b3), which is regarded as "merging" of LSPs. This is because the granularity of the data- driven LSPs is finer than the granularity of the topology-driven LSP. Note that the BR-b1 should be able to handle multipoint-to- point merging of LSPs. (e.g., ATM switch should avoid cell level interleaving among distinct packets). Above-mentioned switched forwarding capability does not apply to the Katsube, et al. Expires Dec. 1997 [Page 6] Internet Draft Interoperation Between LSPs June 1997 BR-b3 which is the termination point of the topology-driven aggregated LSP and the origination point of the data-driven LSP with finer flow granularity, but L3 processing is needed. [Case 2] Data-driven LSP over Topology-driven LSP Tunnel Border routers of the topology-driven AS-b (BR-b1 and BR-b3) are assumed to have capabilities to originate, terminate, and relay data-driven LSPs in this case. In addition, BR-b1 is assumed to memorizes that it has a topology-driven aggregated LSP dedicated to the flow specified by {BR-b1, BR-b3} toward BR-b3. (As already noted, the termination points of topology-driven LSP can be shifted to the border routers of AS-a (BR-a4) and AS-c (BR-c4) respectively) When BR-b1 wants to set up a data-driven LSP dedicated to a flow specified by {H1, H3} or {H2, H4}, it exchanges a data-driven LSP control message with BR-b3 which is a logical neighbor with the support of topology-driven LSP from BR-b1 to BR-b3. Then the data-driven LSP is established from ER-a1 (or ER-a2) to ER-c1 (or ER-c2) by passing through the topology-driven aggregated LSP as a tunnel. This can be regarded as a hierarchical LSP configuration with two levels of label; one applied by ER-a1 or ER-a2 for the {H1, H3} or the {H2, H4} flow and the other applied by BR-b1 for the topology- driven tunnel toward BR-b3. This enables configuration of end-to-end data-driven LSPs without having internal routers in topology-driven network be aware of dara-driven LSP control protocol. [Case 3] Data-driven LSP independent of Topology-driven LSP Tunnel Bandwidth allocation for LSPs dedicated to end-end flow may be supported over topology-driven aggregated LSPs, or may be supported independent of topology-driven LSPs. The former case is regarded as an extension of Case 2, and requires topology-driven LSPs to be given a proper amount of bandwidth. Bandwidth of the topology-driven LSP should be managed to avoid overload of itself. Dynamic changes of allocated bandwidth of topology-driven LSPs in response to their usage may be useful if it is possible. In the latter case; Case 3; there is no interoperation between the topology-driven LSP and the data-driven LSP. The topology-driven aggregated LSPs do not have to be given certain bandwidth, although additional number of LSPs for end-end flow with certain bandwidth Katsube, et al. Expires Dec. 1997 [Page 7] Internet Draft Interoperation Between LSPs June 1997 Data-driven Topology-driven Data-driven (AS-a) (AS-b) (AS-c) <--------------> <--------------> <--------------> H1--ER ER--H3 (a1) IR BR BR IR BR BR IR (c1) (a3) (a4) (b1) (b2) (b3) (c4) (c3) H2--ER ER--H4 (a2) (c2) [Case 1] L3 Interworking with Optional Merging at Aggregation Point (for {H1,H3}) (for {H1,H3}) L3-----::-----::----- -----::-----::-----L3 L3=====::=====L3 L3-----::-----::----- (for{b1,b3}) -----::-----::-----L3 (for {H2,H4}) (for {H2,H4}) (for {H1,H3}) (for {H1,H3}) L3-----::-----::-----\ -----::-----::-----L3 ::=====::=====L3 L3-----::-----::-----/ (for{b1,b3}) -----::-----::-----L3 (for {H2,H4}) (for {H2,H4}) [Case 2] Data-driven LSP over Topology-driven LSP Tunnel (for {H1,H3}) (for {H1,H3}) L3-----::-----::-----:: tunnel ::-----::-----::-----L3 =====::===== L3-----::-----::-----::(for{b1,b3})::-----::-----::-----L3 (for {H2,H4}) (for {H2,H4}) [Case 3] Data-driven LSP independent of Topology-driven LSP (for {H1,H3}) (for {H1,H3}) L3-----::-----::-----::-----::-----::-----::-----::-----L3 =====::===== L3-----::-----::-----::-----::-----::-----::-----::-----L3 (for {H2,H4}) (for {H2,H4}) # "::" denotes switched forwarding. # ------::------ Data-driven LSP # ======::====== Topology-driven LSP Figure 1 Katsube, et al. Expires Dec. 1997 [Page 8] Internet Draft Interoperation Between LSPs June 1997 should be controlled in AS-b independent of the existense of the topology-driven aggregated LSPs. (Reservation-driven LSPs will also be controlled independent of the existense of the topology-driven best-effort LSPs) In this case, all the LSRs in AS-b should be able to handle both topology-driven and data-driven LSPs. 5. Security Considerations Security considerations are not addressed in this memo. 6. Acknowledgement I would like to thank Yakov Rekhter and Paul Doolan for their help and suggestions in writing this document. 7. References [ARIS] R.Woundy, A.Wiswanathan, N.Feldman, R.Biovie, "ARIS: Aggregated Route-Based IP Switching", draft-woundy-aris-ipswitching-00.txt, November, 1996. [RFC2098] Y.Katsube, K.Nagami, H.Esaki, "Toshiba's Router Extensions for ATM", IETF RFC2098, February, 1997. [RFC2105] Y.Rekhter, B.Davie, D.Katz, E.Rosen, G.Swallow, "Cisco System's Tag Switching Overview", IETF RFC2105, February, 1997. 8. Authors' Addresses Yasuhiro Katsube R&D Center, Toshiba Corporation, 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki, 210, Japan Email: katsube@isl.rdc.toshiba.co.jp Hiroshi Esaki Computer and Network Division, Toshiba Corporation, 1-1-1 Shibaura, Minato-ku, 105-01, Japan. Email: hiroshi@isl.rdc.toshiba.co.jp Katsube, et al. Expires Dec. 1997 [Page 9]