draft-ietf-mpls-bundle-00.txt   draft-ietf-mpls-bundle-01.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: March 2002 Yakov Rekhter Expiration Date: May 2002 Yakov Rekhter
Juniper Networks Juniper Networks
Lou Berger Lou Berger
Movaz Networks Movaz Networks
Link Bundling in MPLS Traffic Engineering Link Bundling in MPLS Traffic Engineering
draft-ietf-mpls-bundle-00.txt draft-ietf-mpls-bundle-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract 2. Abstract
In some cases a pair of Label Switching Routers (LSRs) may be For the purpose of GMPLS signaling in certain cases a combination of
connected by several (parallel) links. From the MPLS Traffic <link identifier, label> is not sufficient to unambiguously identify
Engineering point of view for reasons of scalability it may be the appropriate resource used by an LSP. Such cases are handled by
desirable to advertise all these links as a single link into OSPF using the link bundling construct which is described in this
and/or IS-IS. This document describes a mechanism to accomplish this. document.
3. Link Bundling 3. Link Bundling
When a pair of LSRs are connected by multiple links, then for the As defined in [GMPLS-ROUTING], a TE link is a logical construct that
purpose of MPLS Traffic Engineering it is possible to advertise represents a way to group/map the information about certain physical
several (or all) of these links as a single link into OSPF and/or IS- resources (and their properties) that interconnect LSRs into the
IS. We refer to this process as "link bundling", or just "bundling". information that is used by Constrained SPF for the purpose of path
We refer to the link that is advertised into OSPF/IS-IS as a "bundled computation, and by GMPLS signaling.
link". We refer to the links associated with that bundled link as
"component links".
Link bundling can be applied recursively. That is, a bundled link As further stated in [GMPLS-ROUTING], depending on the nature of
that consists of multiple component links may itself be a component resources that form a particular TE link, for the purpose of GMPLS
link of some other bundled link. signaling in some cases a combination of <link identifier, label> is
sufficient to unambiguously identify the appropriate resource used by
an LSP. In other cases, a combination of <link identifier, label> is
not sufficient. Such cases are handled by using the link bundling
construct which is described in this document.
Consider a TE link such that for the purpose of GMPLS signaling a
combination of <link identifier, label> is not sufficient to
unambiguously identify the appropriate resources used by an LSP. In
this situation the link bundling construct assumes that the set of
resources that form the TE link could be partitioned into disjoint
subsets, such that (a) the partition is minimal, and (b) within each
subset a label is sufficient to unambiguously identify the
appropriate resources used by an LSP. We refer to such subsets as
"component links", and to the whole TE link as a "bundled link". On
a bundled link a combination of <(bundled) link identifier, component
link identifier, label> is sufficient to unambiguously identify the
appropriate resources used by an LSP.
Since within each component link a label is sufficient to
unambiguously identify the resources used by an LSP, one could also
say that a component link is a TE link, and a bundled link is a
collection of TE links.
The partition of resources that form a bundled link into component
links has to be done consistently at both ends of the bundled link.
The purpose of link bundling is to improve routing scalability by The purpose of link bundling is to improve routing scalability by
reducing the amount of information that has to be handled by OSPF reducing the amount of information that has to be handled by OSPF
and/or IS-IS. This reduction is accomplished by performing and/or IS-IS. This reduction is accomplished by performing
information aggregation/abstraction. As with any other information information aggregation/abstraction. As with any other information
aggregation/abstraction, this results in losing some of the aggregation/abstraction, this results in losing some of the
information. To limit the amount of losses one need to restrict the information. To limit the amount of losses one need to restrict the
type of the information that can be aggregated/abstracted. type of the information that can be aggregated/abstracted.
3.1. Restrictions on Bundling 3.1. Restrictions on Bundling
All component links in a bundle must begin and end on the same pair All component links in a bundle must begin and end on the same pair
of LSRs, have the same Link Type (i.e., point-to-point or multi- of LSRs, have the same Link Type (i.e., point-to-point or multi-
access), the same Traffic Engineering metric, and the same set of access), the same Traffic Engineering metric, and the same set of
resource classes at each end of the links. A Forwarding Adjacency may resource classes at each end of the links.
be a component link; in fact, a bundle can consist of a mix of point-
to-point links and FAs. A Forwarding Adjacency may be a component link; in fact, a bundle can
consist of a mix of point-to-point links and FAs.
If the component links are all multi-access links, the set of IS-IS If the component links are all multi-access links, the set of IS-IS
or OSPF routers connected to each component link must be the same, or OSPF routers connected to each component link must be the same,
and the Designated Router for each component link must be the same. and the Designated Router for each component link must be the same.
If these conditions cannot be enforced, multi-access links must not If these conditions cannot be enforced, multi-access links must not
be bundled. be bundled.
3.2. Routing Considerations 3.2. Routing Considerations
A bundled link is just another kind of Traffic Engineering (TE) link A component link may be either numbered or unnumbered. A bundled link
(see [GMPLS-ROUTING]). The "liveness" of the bundled link is may itself be numbered or unnumbered independent of whether the
determined by the liveness of each of the component links within the component links of that bundled link are numbered or not.
bundled link - a bundled link is alive when at least one its
component links is determined to be alive. The liveness of a Handling identifiers for unnumbered component links, including the
component link can be determined by any of several means: IS-IS or case where a link is formed by a Forwarding Adjacency, follows the
OSPF hellos over the component link, or RSVP Hello, or LMP hellos same rules as for an unnumbered TE link (see Section 4 of [RSVP-
(see [LMP]), or from layer 1 or layer 2 indications. UNNUM]/[CRLDP-UNNUM]). Furthermore, link local identifiers for all
unnumbered links of a given LSR (whether component links, Forwarding
Adjacencies or bundled links) MUST be unique in the context of that
LSR.
The "liveness" of the bundled link is determined by the liveness of
each of the component links within the bundled link - a bundled link
is alive when at least one its component links is determined to be
alive. The liveness of a component link can be determined by any of
several means: IS-IS or OSPF hellos over the component link, or RSVP
Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2
indications.
Once a bundled link is determined to be alive, it can be advertised Once a bundled link is determined to be alive, it can be advertised
as a TE link and the TE information can be flooded. If IS-IS/OSPF as a TE link and the TE information can be flooded. If IS-IS/OSPF
hellos are run over the component links, IS-IS/OSPF flooding can be hellos are run over the component links, IS-IS/OSPF flooding can be
restricted to just one of the component links [ZININ] [MOY]. restricted to just one of the component links [ZININ] [MOY].
Note that advertising a (bundled) TE link between a pair of LSRs
doesn't imply that there is an IGP adjacency between these LSRs that
is associated with just that link. In fact, in certain cases a TE
link between a pair of LSRs could be advertised even if there is no
IGP adjacency at all between the LSRs (e.g., when the TE link is an
FA).
A component link may be either numbered or unnumbered. A bundled link
may itself be numbered or unnumbered independent of whether the
component links are numbered or not. This affects how the bundled
link is advertised in IS-IS/OSPF, and the format of LSP EROs that
traverse the bundled link. Furthermore, unnumbered Interface
Identifiers for all unnumbered outgoing links of a given LSR (whether
component links, Forwarding Adjacencies or bundled links) MUST be
unique in the context of that LSR.
In the future, as new Traffic Engineering parameters are added to IS- In the future, as new Traffic Engineering parameters are added to IS-
IS and OSPF, they should be accompanied by descriptions as to how IS and OSPF, they should be accompanied by descriptions as to how
they can be bundled, and possible restrictions on bundling. they can be bundled, and possible restrictions on bundling.
3.3. Signaling Considerations 3.3. Signaling Considerations
Typically, an LSP's ERO will choose the bundled link to be used for Typically, an LSP's ERO will choose the bundled link to be used for
the LSP, but not the component link(s), since information about the the LSP, but not the component link, since information about the
bundled link is flooded, but information about the component links is bundled link is flooded, but information about the component links is
not. If the ERO chooses the component links by means outside the not. If the ERO chooses the component link by means outside the scope
scope of this document, this section does not apply. Otherwise, the of this document, this section does not apply. Otherwise, the choice
choice of the component link(s) for the LSP is a local matter between of the component link for the LSP is a local matter between the two
the two LSRs at each end of the bundled link. LSRs at each end of the bundled link.
Signaling must identify both the component link to use and the label Signaling must identify both the component link to use and the label
to use. The choice of the component link to use is always made by the to use. The choice of the component link to use is always made by the
sender of the Path/REQUEST message (if an LSP is bidirectional sender of the Path/REQUEST message (if an LSP is bidirectional
[GMPLS-SIG], the sender chooses a component link in each direction). [GMPLS-SIG], the sender chooses a component link in each direction).
For unidirectional LSPs, and the forward direction of bidirectional For unidirectional LSPs, and the forward direction of bidirectional
LSPs, the sender of a Resv/MAPPING message chooses the label. For the LSPs, the sender of a Resv/MAPPING message chooses the label. For the
reverse direction of a bidirectional LSP, the sender of the reverse direction of a bidirectional LSP, the sender of the
Path/REQUEST message selects the upstream label. Path/REQUEST message selects the upstream label.
Two mechanisms for identifying the component link to the receiver of
the Path/REQUEST message are described below; which of these
mechanisms is used SHOULD be configurable by the user, preferably on
a per-bundle basis. Both mechanisms work with either numbered or
unnumbered component links.
3.3.1. Mechanism 1: Implicit Indication
This mechanism requires that each component link has a dedicated
signaling channel (for example, the link is packet-switch capable; or
the link is a SONET link with an in-band channel for signaling). The
sender of the Path/REQUEST message tells the receiver which component
link to use by sending the message over the chosen component link's
dedicated signaling channel.
3.3.2. Mechanism 2: Explicit Indication by Interface ID
With RSVP the choice of the component link is indicated by the sender With RSVP the choice of the component link is indicated by the sender
of the Path message by including the IF_ID RSVP_HOP object in the of the Path message by including the IF_ID RSVP_HOP object in the
Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP
the choice of the component link is indicated by the sender of the the choice of the component link is indicated by the sender of the
REQUEST message by including the IF_ID TLV in the REQUEST message, as REQUEST message by including the IF_ID TLV in the REQUEST message, as
described in section 8 of [GMPLS-CRLDP]. described in section 8 of [GMPLS-CRLDP].
If the component link is numbered, the IF_ID RSVP_HOP object, or If the component link is numbered, the IF_ID RSVP_HOP object, or
IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6 IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6
address) TLVs (see [GMPLS-SIG]). If the component link is unnumbered, address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
the IF_ID RSVP_HOP object, or IF_ID TLV carries Type 4 identifies the link for which label allocation must be done.
(COMPONENT_IF_DOWNSTREAM) TLV, and in the case of a bidirectional LSP
also Type 5 (COMPONENT_IF_UPSTREAM) TLV (see [GMPLS-SIG]). The value
carried in Type 4 and Type 5 TLVs contains the outgoing interface
identifier (from the point of view of the sender of the Path/REQUEST
message) of the selected component link.
When the IF_ID RSVP_HOP or IF_ID TLV carries the IPv4 or IPv6 address
(component link is numbered), this address identifies the link for
which label allocation must be done.
When a component link is unnumbered, this mechanism requires that
each component link is assigned a unique Interface Identifier per
[UNNUM-RSVP] or [UNNUM-CRLDP], and that the assigned identifiers be
exchanged by the two LSRs at each end of the bundled link.
Exchanging the identifiers may be accomplished by configuration, by
means of a protocol such as LMP ([LMP]), by means of RSVP/CR-LDP
(especially in the case where a component link is a Forwarding
Adjacency), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS],
[OSPF-GMPLS]).
When the IF_ID RSVP_HOP or IF_ID TLV carries the
COMPONENT_IF_DOWNSTREAM TLV (component link is unnumbered), the LSR
that receives the Path/REQUEST message determines the component link
for which label allocation must be done as follows. First the LSR
checks whether the tuple <IP Address, Interface ID> carried in
COMPONENT_IF_DOWNSTREAM matches the tuple <Router ID, Forwarding
Interface ID> (see [RSVP-UNNUM], [CRLDP-UNNUM]) of any LSPs for which
the LSR is a tail-end. If the match is found, the match identifies
the Forwarding Adjacency for which the LSR has to perform label
allocation.
Otherwise, the LSR must check whether the tuple <IP Address,
Interface ID> carried in COMPONENT_IF_DOWNSTREAM matches the tuple
<Router ID, Reverse Interface ID> (see [RSVP-UNNUM], [CRLDP-UNNUM])
of any of the bidirectional LSPs for which the LSR is the head-end.
If a match is found, the match identifies the Forwarding Adjacency
for which the LSR has to perform label allocation, namely, the
reverse Forwarding Adjacency for the LSP identified by the match.
Otherwise, the LSR must have information about the identifiers If the component link is unnumbered, the IF_ID RSVP_HOP object, or
assigned by its neighbors to the component links (i.e., incoming IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value
interface identifiers from LSR's point of view). The LSR uses this carried in Type 3 TLV contains the identifier of the selected
information to find a (component) link with tuple <Router ID, component link assigned to the link by the sender of the Path/REQUEST
incoming interface identifier> matching the tuple <IP Address, message. Processing this object is the same as specified in Section
Interface ID> carried in COMPONENT_IF_DOWNSTREAM. If the matching 6.1 of [RSVP-UNNUM]/[CRLDP-UNNUM].
tuple is found, the match identifies the (component) link for which
the LSR has to perform label allocation.
In both RSVP and CR-LDP, if the Interface ID field of For the purpose of processing the IF_ID RSVP_HOP object or IF_ID TLV,
COMPONENT_IF_DOWNSTREAM has the special value of 0xffffffff, this an unnumbered component link formed by a Forwarding Adjacency is
means that the same label is to be valid across all component links treated the same way as an unnumbered TE link formed by a Forwarding
in the downstream direction. Likewise, if the Interface ID field of Adjacency (see Section 5 of [RSVP-UNNUM]/[CDLDP-UNNUM]).
COMPONENT_IF_UPSTREAM has the special value of 0xffffffff, this means
that the same label is to be valid across all component links in the
upstream direction.
4. Traffic Engineering Parameters for Bundled Links 4. Traffic Engineering Parameters for Bundled Links
In this section, we define the Traffic Engineering parameters to be In this section, we define the Traffic Engineering parameters to be
advertised for a bundled link, based on the configuration of the advertised for a bundled link, based on the configuration of the
component links and of the bundled link. The definition of these component links and of the bundled link. The definition of these
parameters for component links was undertaken in [ISIS-TE] and [OSPF- parameters for component links was undertaken in [ISIS-TE] and [OSPF-
TE]; we use the terminology from [OSPF-TE]. TE]; we use the terminology from [OSPF-TE].
4.1. OSPF Link Type 4.1. OSPF Link Type
skipping to change at page 6, line 34 skipping to change at page 5, line 34
4.3. Local and Remote Interface IP Address 4.3. Local and Remote Interface IP Address
(Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4
Neighbor Address, respectively.) Neighbor Address, respectively.)
If the bundled link is numbered, the Local Interface IP Address is If the bundled link is numbered, the Local Interface IP Address is
the local address of the bundled link; similarly, the Remote the local address of the bundled link; similarly, the Remote
Interface IP Address is the remote address of the bundled link. Interface IP Address is the remote address of the bundled link.
4.4. Outgoing and Incoming Interface Identifiers 4.4. Local and Remote Identifiers
If the bundled link is unnumbered, the Outgoing Interface Identifier If the bundled link is unnumbered, the link local identifier is set
is set to the outgoing interface identifier chosen for the bundle by to the identifier chosen for the bundle by the advertising LSR. The
the advertising LSR. The Incoming Interface Identifier is set to the link remote identifier is set to the identifier chosen by the
outgoing interface identifier chosen by the neighboring LSR for the neighboring LSR for the reverse link corresponding to this bundle, if
reverse link corresponding to this bundle, if known; otherwise, this known; otherwise, this is set to 0.
is set to 0.
4.5. Traffic Engineering Metric 4.5. Traffic Engineering Metric
The Traffic Engineering Metric for a bundled link is that of the The Traffic Engineering Metric for a bundled link is that of the
component links. component links.
4.6. Maximum Link Bandwidth 4.6. Maximum Link Bandwidth
This TLV is not used. The maximum LSP Bandwidth (as described below) This TLV is not used. The maximum LSP Bandwidth (as described below)
replaces the maximum link bandwidth for bundled links. replaces the maximum link bandwidth for bundled links.
skipping to change at page 7, line 38 skipping to change at page 6, line 33
associated with the bundled link. associated with the bundled link.
4.9. Resource Classes (Administrative Groups) 4.9. Resource Classes (Administrative Groups)
The Resource Classes for a bundled link are the same as those of the The Resource Classes for a bundled link are the same as those of the
component links. component links.
4.10. Maximum LSP Bandwidth 4.10. Maximum LSP Bandwidth
The Maximum LSP Bandwidth takes the place of the Maximum Link The Maximum LSP Bandwidth takes the place of the Maximum Link
Bandwidth. It is defined in [GMPLS-ROUTING]. The details of how Bandwidth. For an unbundled link the Maximum Link Bandwidth is is
Maximum LPS Bandwidth is carried in IS-IS is given in [GMPLS-ISIS]. defined in [GMPLS-ROUTING]. The Maximum LSP Bandwidth of a bundled
The details of how Maximum LSP Bandwidth is carried in OSPF is given link at priority p is defined to be the maximum of the Maximum LSP
in [GMPLS-OSPF]. Bandwidth at priority p of all of its component links.
Maximum LSP Bandwidth of a bundled link is equal to the maximum of
Maximum LSP Bandwidth of all of its component links.
Since bundling may be applied recursively, a component link may The details of how Maximum LSP Bandwidth is carried in IS-IS is given
itself be a bundled link. In this case, its Maximum LSP Bandwidth as in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried
a component link is the same as its Maximum LSP Bandwidth as a in OSPF is given in [GMPLS-OSPF].
bundled link.
5. Bandwidth Accounting 5. Bandwidth Accounting
The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an
LSR with bundled links must apply admission control on a per- LSR with bundled links must apply admission control on a per-
component link basis. An LSP with a bandwidth requirement b and setup component link basis. An LSP with a bandwidth requirement b and setup
priority p fits in a bundled link if at least one component link has priority p fits in a bundled link if at least one component link has
maximum LSP bandwidth >= b at priority p. If there are several such maximum LSP bandwidth >= b at priority p. If there are several such
links, the choice of which link is used for the LSP is up to the links, the choice of which link is used for the LSP is up to the
implementation. implementation.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/