Internet Draft 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]