Network Working Group James R. Leu
INTERNET-DRAFT Robert Rennison
Expiration Date: January 2001 Steve Vogelsang
Laurel Networks, Inc.
July 2000
Label Aggregation Technique for LDP
draft-leu-mpls-ldp-label-aggregation-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
The label distribution protocol specified in [1] describes a
mechanism whereby one label switched router informs another of the
meaning of labels used to forward traffic between and through them.
This draft proposes a label aggregation technique to reduce the
number of labels that need to be exchanged between two LSRs running
LDP.
This includes a method of signalling that LSRs are capable of label
aggregation, determining when a label request can be aggregated on to
an existing LSP and a method of signalling to upstream LSRs that the
resulting label mapping is an aggregate.
Leu, et al. [Page 1]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
3. Table of Contents
Page
1 Status of this Memo ................................ 1
2 Abstract ........................................... 1
3 Table of Contents .................................. 2
4 Overview ........................................... 2
5 Requirements for Label Aggregation ................. 3
6 Aggregation Capability TLV ......................... 3
7 Aggregation Capability Detection .................... 3
8 Label Request Message with Aggregation ............. 3
8.1 Label Request Message - Ingress Processing ......... 4
8.2 Label Request Message - Transit processing ......... 4
8.3 Label Request Message - Egress Processing .......... 4
9 Aggregate Mapping Detection ........................ 5
10 Label Mapping Message with Aggregation ............. 5
10.1 Label Mapping Message - Egress Processing .......... 5
10.2 Label Mapping Message - Transit Processing ......... 6
10.3 Label Mapping Message - Ingress Processing ......... 6
11 Label Release and Label Withdraw Messages .......... 7
12 Handling Error Conditions .......................... 7
13 References ......................................... 7
14 Author Information ................................. 7
4. Overview
In the current version of LDP when a network with N LSRs and M FECs
(where N << M) runs in Downstream on Demand mode:
-without label merge the result is at least N * M LSPs in the network
-with label merge the result is at least M multi-point-to-point LSPs
-with label aggregation (as defined in this draft) the results can be
as low as N^2
-with label aggregation AND label merge the result is theorized to be
as low as N multi-point-to-point LSPs. (this specific use of label
aggregation and label merge is for further study)
By lowering the number of LSPs created when running an LDP network,
LDP becomes a feasible, if not even attractive, means to establish a
full mesh of LSPs from ingress to egress LSRs. This near optimal
usage of LSPs could result in ease of LSP management and trouble
shooting and simplified LSP accounting. The resulting full mesh will
also represent a simplified view of reachability across an MPLS
domain.
To achieve this though, LDP needs to be given the ability to
recognize when a new label request can be mapped to an existing LSP.
This draft proposes a mean to accomplish label aggregation for LDP.
Leu, et al. [Page 2]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
5. Requirements for Label Aggregation
For aggregation to occur all LSRs in the path must be running in DoD
mode with ordered control, support loop detection via a Path Vector
List, and be running in global repair mode. Forwarding of the
Aggregation Capability TLV transparently by peers that cannot or do
not participate in label aggregation relies on correct handling of
the F bit in a TLV. The correct procedures for handling the F bit in
a TLV are outlined in [1].
6. Aggregation Capability TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Aggr. Capability (0x0105) | Length(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Aggregation Capable LSR ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Last Aggregation Capable LSR ID
The LSR ID of the previous Aggregation Capable LSR.
7. Aggregation Capability Detection
When a LSR receives a Label Request Message that contains an
Aggregation Capability TLV it needs to determine if the upstream
peer (sender of the message) supports label aggregation. To do this
it compares the LSR ID in the message header to the Last Aggregation
Capable LSR ID field in the Aggregation Capability TLV. If these
values match this implies that the sender of this message supports
label aggregation. If these two values do not match this implies
that the sender of this message does not support label aggregation or
does not understand the Aggregation Capability TLV.
(see "Type-Length-Value Encoding" in [LPD-07])
8. Label Request Message with Aggregation
When a Label Request Message is received that contains an Aggregation
Capability TLV, the Aggregation Capability TLV is saved along with
the rest of the received TLVs. This is used for propagating the
request and for originating or handling a Label Mapping Message
should one appear for this LSP.
If the LSR supports the Aggregation Capability TLV it determines
if the upstream neighbor (sender of this message) supports label
aggregation using the method outlined in "Aggregation Capability
Detection."
Leu, et al. [Page 3]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
8.1 Label Request Message - Ingress Processing
When a Label Request Message is generated at an ingress LSR
the LSR MAY include an Aggregation Capability TLV. If the
Aggregation Capability TLV is included, the LSR MUST set the Last
Aggregation Capable LSR ID field to its LSR ID and the F and U bits
in the TLV to 1 (one).
8.2 Label Request Message - Transit processing
A transit LSR MUST propagate the Label Request Message to
the next hop as described in [1]. The message is prepared
according to [1] with the exception of Aggregation Capability
TLV which is handled as follows:
- IF this LSR does not support the TLV type or does not support label
aggregation then the LSR MUST propagate the Aggregation Capability
TLV unchanged (see "Type-Length-Value Encoding" in [1]).
- ELSE IF the upstream neighbor supports label aggregation then the
LSR overwrites the Last Aggregation Capable LSR ID field with its
LSR ID.
- ELSE IF the upstream neighbor does not support label aggregation
and this LSR supports label merge and wants to merge to an
aggregate label then the LSR MUST overwrite the the Last
Aggregation Capable LSR ID with its LSR ID.
- ELSE the LSR MUST propagate the Aggregation Capability TLV
unchanged
8.3 Label Request Message - Egress Processing
When a Label Request Message is received by the egress LSR (for a
particular FEC) and the Label Request Message contains an
Aggregation Capability TLV it MUST decide whether or not to
aggregate this label request (and the corresponding mapping) to an
existing LSP.
If the egress LSR supports label aggregation and the upstream
neighbor supports label aggregation (as determined by "Aggregation
Capability Detection") the egress LSR searches its list of LSPs it is
egress for and compares the TLVs saved for the existing LSPs and the
TLVs from the Label Request Message. The following TLVs should be
considered when making its decision about label aggregation.
-Path TLV - The path TLVs value MUST match EXACTLY
-Hop Count TLV - The hop count TLVs values MUST match EXACTLY
-FEC TLV - address family MUST match
If a matching LSP is found, a Label Mapping Message is sent as
Leu, et al. [Page 4]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
described in ("Label Mapping Message - Egress Processing"),
otherwise, the LSR discards the Aggregation Capability TLV and
handles the label request as described in [1]
If the egress LSR does not support label aggregation or the upstream
neighbor does not support label aggregation (as determined by
"Aggregation Capability Detection") the LSR discards the Aggregation
Capability TLV and handles the label request as described in [1].
9. Aggregate Mapping Detection
When a LSR receives an LDP Label Mapping Message that contains an
Aggregation Capability TLV it needs to determine if the downstream
peer (sender of the message) is sending an aggregate label mapping.
To do this it compares the LSR ID in the message header to the Last
Aggregation Capable LSR ID field in the Aggregation Capability TLV.
If these values match this implies that the label mapping contained
in this Label Mapping Message is an aggregate label mapping. If
these two values do not match this implies that this label mapping
is part of an LSP which is merged to an aggregate LSP downstream.
10. Label Mapping Message with Aggregation
When a Label Mapping Message is received that contains an
Aggregation Capability TLV, the Aggregation Capability TLV is
saved along with the rest of the received TLVs.
If the LSR supports the Aggregation Capability TLV it MUST
determine if this message contains an aggregate mapping by using
the method outlined in "Aggregate Mapping Detection". If the
mapping is to be propagated then corresponding label request
MUST have included an Aggregation Capability TLV, otherwise an
error condition has occurred (see "Handling Error Conditions").
10.1 Label Mapping Message - Egress Processing
When an egress LSR decides it can aggregate a label request to an
existing LSP it prepares the Label Mapping Message as described in
[1] with the following changes:
-The label is not generated, it is copied from the matching (now
Aggregate) LSP.
-The Aggregation Capability TLV is included in the Label Mapping
message. The Last Aggregation Capable LSR ID field is filled
with the LSR ID of this Egress LSR. The U and F bits in the TLV
are set to 1 (one).
Leu, et al. [Page 5]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
10.2 Label Mapping Message - Transit processing
If a LSR receives an aggregate label mapping (see "Aggregate Mapping
Detection") it must determine if the upstream peer supports label
aggregation by looking at the TLVs that were stored for the
corresponding label request (see "Aggregation Capability Detection").
The Label Mapping Message is processed according to the procedures
from [1] with the following additions:
-IF there does not exist an upstream peer then this LSR is ingress
for this LSP and MUST process the message according to "Label
Mapping Message - Ingress Processing".
-ELSE IF this is not an aggregate label mapping the Aggregation
Capability TLV is passed to the upstream neighbor unchanged.
-ELSE IF the upstream LSR supports label aggregation, the label from
the Label Mapping Message is used to lookup the matching LSP. The
upstream label from the LSP is copied into the Label TLV in the
outgoing Label Mapping Message. The Last Aggregation Capable LSR
ID is replaces with this LSRs ID. The Label Mapping Message is
propagated upstream.
-ELSE IF the transit LSR supports LSP merge then it generates
a new upstream label, merges the upstream label to the LSP indicated
in the Label Mapping Message, and propagates the Aggregation
Capability TLV unchanged.
-ELSE an error condition has occurred (see "Handling Error
Conditions").
10.3 Label Mapping Message - Ingress Processing
-IF the ingress LSR does not support label aggregation or did not
include a Aggregation Capability TLV in the corresponding Label
Request Message, and receives a Label Mapping Message mapping with
an Aggregation Capability TLV an error condition has occurred.
(see "Handling Error Conditions")
-ELSE IF this is an aggregate mapping (see "Aggregate Mapping
Detection") the LSR MUST associate the FEC to the existing LSP
indicated by the label mapping.
-ELSE the LSR MAY note that is has received a label mapping which is
merged somewhere downstream.
Leu, et al. [Page 6]
Internet Draft draft-leu-mpls-ldp-label-aggregation July 2000
11. Label Release and Label Withdraw Messages for Aggregate Labels
The processing of these messages is done according to [1]
with the additions of:
-IF the Label Release Message or Label Withdraw Message indicate a
FEC that is attached to a aggregate label and this is the only
FEC currently associated to this label, then the label is removed
from switching.
-ELSE the association between the FEC and this label is removed without
removing the label for switching.
12. Handling Error Conditions related to Label Aggregation
If the error condition occurred during label request procedures or
during label mapping procedures then a Notification Message with
the status of "Label Aggregation Error" is send upstream. The
contents of the Label Request or Label Mapping Message MAY be
included by adding a Returned Message or Returned PDU TLV.
In addition, if this error occurred during label mapping procedures
then a Label Release Message is sent downstream. Optionally a
Status TLV with a status of "Label Aggregation Error" can be
sent with the Label Release Message.
Status Code E Status Data
Label Aggregation Error 0 0x00000020
13. References
[1] - "LDP Specification", Andersson, Doolan, Feldman,
Fredette, Thomas, work in progress, June 2000.
"draft-ietf-mpls-ldp-08"
14. Author Information
James R. Leu Robert Rennison
Laurel Networks, Inc. Laurel Networks, Inc.
2607 Nicholson Road 2607 Nicholson Road
Sewickley, PA 15143 Sewickley, PA 15143
USA USA
Phone: +1 (724)933-7330 x274 Phone: +1 (724)933-7330
email: jleu@laurelnetworks.com email:robren@laurelnetworks.com
Stephen Vogelsang
Laurel Networks, Inc.
2607 Nicholson Road
Sewickley, PA 15143
USA
Phone: +1 (724)933-7330
email: sjv@laurelnetworks.com
Leu, et al. [Page 7]