draft-ietf-mpls-bundle-03.txt   draft-ietf-mpls-bundle-04.txt 
Network Working Group Kireeti Kompella Network Working Group Kireeti Kompella
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: November 2002 Yakov Rekhter Expiration Date: January 2003 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-03.txt draft-ietf-mpls-bundle-04.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
For the purpose of GMPLS signaling in certain cases a combination of For the purpose of Generalized Multi-Protocol Label Switching (GMPLS)
<link identifier, label> is not sufficient to unambiguously identify signaling in certain cases a combination of <link identifier, label>
the appropriate resource used by an LSP. Such cases are handled by is not sufficient to unambiguously identify the appropriate resource
using the link bundling construct which is described in this used by a Label Switched Path (LSP). Such cases are handled by using
document. the link bundling construct which is described in this document.
3. Link Bundling 3. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
4. Link Bundling
As defined in [GMPLS-ROUTING], a TE link is a logical construct that As defined in [GMPLS-ROUTING], a TE link is a logical construct that
represents a way to group/map the information about certain physical represents a way to group/map the information about certain physical
resources (and their properties) that interconnect LSRs into the resources (and their properties) that interconnect LSRs into the
information that is used by Constrained SPF for the purpose of path information that is used by Constrained SPF for the purpose of path
computation, and by GMPLS signaling. computation, and by GMPLS signaling.
As further stated in [GMPLS-ROUTING], depending on the nature of As further stated in [GMPLS-ROUTING], depending on the nature of
resources that form a particular TE link, for the purpose of GMPLS resources that form a particular TE link, for the purpose of GMPLS
signaling in some cases a combination of <link identifier, label> is signaling in some cases a combination of <link identifier, label> is
skipping to change at page 3, line 5 skipping to change at page 3, line 8
links has to be done consistently at both ends of the bundled link. 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 4.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. resource classes at each end of the links.
A Forwarding Adjacency may be a component link; in fact, a bundle can A Forwarding Adjacency may be a component link; in fact, a bundle can
consist of a mix of point-to-point links and FAs. 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 4.2. Routing Considerations
A component link may be either numbered or unnumbered. A bundled link A component link may be either numbered or unnumbered. A bundled link
may itself be numbered or unnumbered independent of whether the may itself be numbered or unnumbered independent of whether the
component links of that bundled link are numbered or not. component links of that bundled link are numbered or not.
Handling identifiers for unnumbered component links, including the Handling identifiers for unnumbered component links, including the
case where a link is formed by a Forwarding Adjacency, follows the case where a link is formed by a Forwarding Adjacency, follows the
same rules as for an unnumbered TE link (see Section 4 of [RSVP- same rules as for an unnumbered TE link (see Section "Link
UNNUM]/[CRLDP-UNNUM]). Furthermore, link local identifiers for all Identifiers" of [RSVP-UNNUM]/[CRLDP-UNNUM]). Furthermore, link local
unnumbered links of a given LSR (whether component links, Forwarding identifiers for all unnumbered links of a given LSR (whether
Adjacencies or bundled links) MUST be unique in the context of that component links, Forwarding Adjacencies or bundled links) MUST be
LSR. unique in the context of that LSR.
The "liveness" of the bundled link is determined by the liveness of The "liveness" of the bundled link is determined by the liveness of
each of the component links within the bundled link - a bundled link 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 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 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 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 Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2
indications. 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. Procedures for doing restricted to just one of the component links. Procedures for doing
this are outside the scope of this document. this are outside the scope of this document.
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 4.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, 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 link by means outside the scope not. If the ERO chooses the component link by means outside the scope
of this document, this section does not apply. Otherwise, the choice of this document, this section does not apply. Otherwise, the choice
of the component link for the LSP is a local matter between the two of the component link for the LSP is a local matter between 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
skipping to change at page 4, line 41 skipping to change at page 4, line 46
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]). The address carried in the TLV address) TLVs (see [GMPLS-SIG]). The address carried in the TLV
identifies the link for which label allocation must be done. identifies the link for which label allocation must be done.
If the component link is unnumbered, the IF_ID RSVP_HOP object, or If the component link is unnumbered, the IF_ID RSVP_HOP object, or
IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value
carried in Type 3 TLV contains the identifier of the selected carried in Type 3 TLV contains the identifier of the selected
component link assigned to the link by the sender of the Path/REQUEST component link assigned to the link by the sender of the Path/REQUEST
message. Processing this object is the same as specified in Section message. Processing this object is the same as specified in Section
6.1 of [RSVP-UNNUM]/[CRLDP-UNNUM]. "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" of
[RSVP-UNNUM]/[CRLDP-UNNUM].
For the purpose of processing the IF_ID RSVP_HOP object or IF_ID TLV, For the purpose of processing the IF_ID RSVP_HOP object or IF_ID TLV,
an unnumbered component link formed by a Forwarding Adjacency is an unnumbered component link formed by a Forwarding Adjacency is
treated the same way as an unnumbered TE link formed by a Forwarding treated the same way as an unnumbered TE link formed by a Forwarding
Adjacency (see Section 5 of [RSVP-UNNUM]/[CDLDP-UNNUM]). Adjacency (see Section "Unnumbered Forwarding Adjacencies" of [RSVP-
UNNUM]/[CDLDP-UNNUM]).
4. Traffic Engineering Parameters for Bundled Links 5. 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 5.1. OSPF Link Type
The Link Type of a bundled link is the (unique) Link Type of the The Link Type of a bundled link is the (unique) Link Type of the
component links. (Note: this parameter is not present in IS-IS.) component links. (Note: this parameter is not present in IS-IS.)
4.2. OSPF Link ID 5.2. OSPF Link ID
For point-to-point links, the Link ID of a bundled link is the For point-to-point links, the Link ID of a bundled link is the
(unique) Router ID of the neighbor. For multi-access links, this is (unique) Router ID of the neighbor. For multi-access links, this is
the interface address of the (unique) Designated Router. (Note: this the interface address of the (unique) Designated Router. (Note: this
parameter is not present in IS-IS.) parameter is not present in IS-IS.)
4.3. Local and Remote Interface IP Address 5.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. Local and Remote Identifiers 5.4. Local and Remote Identifiers
If the bundled link is unnumbered, the link local identifier is set If the bundled link is unnumbered, the link local identifier is set
to the identifier chosen for the bundle by the advertising LSR. The to the identifier chosen for the bundle by the advertising LSR. The
link remote identifier is set to the identifier chosen by the link remote identifier is set to the identifier chosen by the
neighboring LSR for the reverse link corresponding to this bundle, if neighboring LSR for the reverse link corresponding to this bundle, if
known; otherwise, this is set to 0. known; otherwise, this is set to 0.
4.5. Traffic Engineering Metric 5.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 Bandwidth 5.6. Maximum Bandwidth
This parameter is not used. The maximum LSP Bandwidth (as described This parameter is not used. The maximum LSP Bandwidth (as described
below) replaces the Maximum Bandwidth for bundled links. below) replaces the Maximum Bandwidth for bundled links.
4.7. Maximum Reservable Bandwidth 5.7. Maximum Reservable Bandwidth
We assume that for a given bundled link either each of its component We assume that for a given bundled link either each of its component
links is configured with the Maximum Reservable Bandwidth, or the links is configured with the Maximum Reservable Bandwidth, or the
bundled link is configured with the Maximum Reservable Bandwidth. In bundled link is configured with the Maximum Reservable Bandwidth. In
the former case, the Maximum Reservable Bandwidth of the bundled link the former case, the Maximum Reservable Bandwidth of the bundled link
is set to the sum of the Maximum Reservable Bandwidths of all is set to the sum of the Maximum Reservable Bandwidths of all
component links associated with the bundled link. component links associated with the bundled link.
4.8. Unreserved Bandwidth 5.8. Unreserved Bandwidth
The unreserved bandwidth of a bundled link at priority p is the sum The unreserved bandwidth of a bundled link at priority p is the sum
of the unreserved bandwidths at priority p of all the component links of the unreserved bandwidths at priority p of all the component links
associated with the bundled link. associated with the bundled link.
4.9. Resource Classes (Administrative Groups) 5.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 5.10. Maximum LSP Bandwidth
The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth.
For an unbundled link the Maximum Bandwidth is is defined in [GMPLS- For an unbundled link the Maximum Bandwidth is defined in [GMPLS-
ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p
is defined to be the maximum of the Maximum LSP Bandwidth at priority is defined to be the maximum of the Maximum LSP Bandwidth at priority
p of all of its component links. p of all of its component links.
The details of how Maximum LSP Bandwidth is carried in IS-IS is given The details of how Maximum LSP Bandwidth is carried in IS-IS is given
in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried
in OSPF is given in [GMPLS-OSPF]. in OSPF is given in [GMPLS-OSPF].
5. Bandwidth Accounting 6. 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.
In order to know the maximum LSP bandwidth (per priority) of each In order to know the maximum LSP bandwidth (per priority) of each
skipping to change at page 7, line 33 skipping to change at page 7, line 33
If one of the component links goes down, the associated bundled link If one of the component links goes down, the associated bundled link
remains up and continues to be advertised, provided that at least one remains up and continues to be advertised, provided that at least one
component link associated with the bundled link is up. The component link associated with the bundled link is up. The
unreserved bandwidth of the component link that is down is set to unreserved bandwidth of the component link that is down is set to
zero, and the unreserved bandwidth and maximum LSP bandwidth of the zero, and the unreserved bandwidth and maximum LSP bandwidth of the
bundle must be recomputed. If all the component links associated with bundle must be recomputed. If all the component links associated with
a given bundled link are down, the bundled link MUST not be a given bundled link are down, the bundled link MUST not be
advertised into OSPF/IS-IS. advertised into OSPF/IS-IS.
6. Security Considerations 7. Security Considerations
This document raises no new security issues for RSVP-TE or CR-LDP. This document defines ways of utilizing procedures defined in other
documents referenced herein. Any security issues related to those
procedures are addressed in the referenced drafts. This document
thus raises no new security issues for RSVP-TE [RSVP-TE] or CR-LDP
[CR-LDP].
7. References 8. References
7.1. Normative References 8.1. Normative References
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
extensions-11.txt (work in progress) extensions-11.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-
gmpls-extensions-08.txt (work in progress) gmpls-extensions-08.txt (work in progress)
[GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al, [GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al,
skipping to change at page 8, line 30 skipping to change at page 8, line 44
[OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to
OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress)
[UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling
Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work
in progress) in progress)
[UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links
in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress) in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress)
7.2. Non-normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC3209, December 2001
[CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using
LDP", RFC3212, December 2001
8.2. Non-normative References
[LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-03.txt (work in progress) draft-ietf-ccamp-lmp-03.txt (work in progress)
8. Author Information 9. Author Information
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
 End of changes. 

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