One document matched: draft-katsube-interop-between-lsps-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 06:42:20 |