Signaling Color Label Switched Paths Using LDP

The extensions in this document allow LSRs to implement a forwarding preference between different paths available to downstream LSRs. While multiple paths between two LSR may have the same cost from an routing perspective, individual paths may have intrinsic characteristics that an LSR may prefer. As an example, some paths may have a significant difference in terms of latency, reliability, protection, bandwidth or path diversity among other characteristics. An LSR may want to allow upstream LSRs to determine what traffic is forwarded down specific paths. A sample deployment scenario for color LSPs involves an LDP network using targeted LDP over RSVP-TE LSPs. A given head-end provider (P) device can establish multiple TE LSPs to another tail-end P device. One TE LSP can be engineered for low latency while the other TE LSPs can be engineered for high bandwidth. The head-end P device can associate locally the low-latency TE LSP with one color and the other TE LSPs with a second color. This device can signal two paths (one per color) to upstream LDP peers. With these two paths, a provider edge (PE) device can implement local policies to implement a forwarding preference for low latency or high bandwidth at the downstream P device.

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.

A color LSP can be defined for the following types of LDP FEC elements: Prefix (0x2) P2MP (0x6) MP2MP upstream (0x7) MP2MP downstream (0x8) and for the following address families: IP (version 4) (0x1) IPv6 (0x2)

Three LSR roles can be involved in establishing a color LSP: A transit node with multiple paths towards a destination. It advertises color paths to other upstream LSRs according to a local forwarding association between colors and downstream paths. Advertisement may occur as response to an egress LSR interest in specific color paths. Selects between color paths associated with a given FEC to influence the forwarding by downstream color LSRs. May signal interest in particular colors towards upstream LSRs in order to influence the signaling behavior of color LSRs. illustrates an example of a network implemententing a forwarding preference policy for a prefix FEC. In this example, LSRa is an ingress LSR, LSRb is a color LSR and LSRc is an egress LSR. There are three paths (P1, P2 and P3) between LSRb and LSRc. Path P1 and P2 have unique characteristics with respect to p3. LSRb associates P1 and P2 with a color value C1, and P3 with a different color value C2. This color-to-path association is a local decision on LSRb, and colors are globally significant within the LDP domain.

Example of a color LSP scenario LSRb signals two color LSPs towards LSRa in response to LSRc interest in color LSPs. LSRc advertises a label for a prefix for which it is an egress LSR. The advertisement includes a label mapping for the prefix and a list of colors (C1 and C2) in which LSRc is interested. LSRb matches the colors in the local color-path association with the color list that LSRc advertised. After finding a match for both C1 and C2, LSRb signals labels for two paths towards LSRa with colors C1 and C2. In addition, it programs an MPLS forwarding entry that associates color C1 with P1 and P2 as next hops, and color label C2 with P3 as next hop for the prefix advertised by LSRc. Ultimately, LSRa receives two label mappings for the prefix, one associated with C1 and the second one associated with C2. LSRa can make a local decision to forward traffic towards LSRc using the LSP with color C1 (via paths P1 and P2) or the LSP with color C2 (via P3). While both color paths overlap between LSRa and LSRb, the latter differentiates the forwarding of color labels towards LSRc per its local policy. LSRb may implement different policies for the signaling of color LSPs. In the scenario above, LSRb can be provisioned to advertise color labels for C1 and and C2 without requiring explicit indication from LSRc of interest in those two colors. Such configuration may be desirable for interoperability with legacy egress LSRs that cannot signal a color interest. It may also be desirable in deployment scenarios where color LSPs should be signaled for all egress LSRs and there is no need to provide control for individual egress LSRs.

This new capability parameter allows an LSR to advertise its ability to signal a color LSP for a given FEC type (). The capability follows the format and procedures defined in and may be signaled in LDP Initialization or Capability messages.

"Color LSP Capability" TLV MUST be set to 1 and 0 respectively so that a receiver silently ignores this TLV if unknown, continues processing the rest of the message and does not forward the TLV if unknown. The length (in octets) of the TLV following this length field. The value of this field is variable and is dependent on capability-specific data. Set to 1 or 0 to advertise or withdraw the capability respectively as specified in . Must be set to zero on transmission and ignored on receipt This is capability-specific data that is defined for Color LSPs. It consists of a Typed Wildcard FEC Element identifying the FEC for which this capability is being signaled. In the context of this document, the Typed Wildcard FEC element MUST correspond to one of the FEC types applicable to Color LSP as defined in . If a receiver receives this TLV with a Typed Wildcard FEC of type other than those defined in , it SHOULD silently discard the TLV and continue processing rest of the message. In order to announce or withdraw this capability for more than one type of FEC elements, an LDP speaker MUST announce/withdraw them separately using the same "Color LSP Capability" TLV. A receiver MUST keep record of the color LSP capabilities of its peer on per-FEC basis. For example, consider an LSR that supports color LSPs for both IPv4 Prefixes and IPv6 Prefixes. The LSR will announce these capabilities in different Capability TLVs (either as part of the same LDP Initialization/Capability message or separate message) by setting the TLV S-bit to 1 and capability data to Typed Wildcard IPv4 Prefix FEC and Typed Wildcard IPv6 Prefix FEC (as defined in ). The receiver will keep track of the LSR capability and note it to be Color LSP capable for IPv4-Prefix and IPv6-Prefix FEC types. Later, if the LSR withdraws its capability for one of these FEC elements, it will send a Capability TLV (in a Capability message) with S-bit set to 0 and FEC's Typed Wildcard as the capability data. On receipt of this message, the peer will update accordingly to remove the corresponding FEC from LSR's color LSP capability list.

The Color List TLV is a new optional parameter in the LDP Label Mapping and Label Request messages. The list includes one or more color identifiers that LSRs may use to signal interest in a forwarding preference.

"Color List" TLV MUST be set to 1 and 1 respectively so that a receiver silently ignores this TLV if unknown, continues processing the rest of the message and forwards the TLV. The length (in octets) of the TLV following this length field. The value of this field is variable and is dependent on number of Color Ids that follow in the TLV. List of color identifiers associated with the FEC encoded in the message. A Color Id is a two octet field defined as follows:

"Color identifier" field (non-zero) unsigned color identifier. Color Id 0xFFFF refers to the "wildcard color" (i.e. all colors).

An egress LSR MAY include the Color List TLV in a Label Mapping Message if using Downstream Unsolicited mode. An LSR may include the TLV in Label Request Messages if using Downstream on Demand mode. An LSR MUST NOT include this TLV in any other LDP message except the Label Mapping and Label Request messages. LSRs SHOULD silently discard this TLV if received in other messages and continue processing the rest of the message. A Color List TLV MUST only be used in downstream signaled paths. An LSR MAY include a Color List TLV List TLV whether the neighbor has previously advertised the LDP Color LSP Capability () or not. The TLV MUST be forwarded to other neighbors as defined by the U/F flags. This behavior allows LSRs that do not support the Color LSP extensions to not preclude the signaling of Color LSPs if they are downstream from a Color LSR. On receipt of a Color List TLV, a Color LSR with multiple downstream paths SHOULD match the list of color identifiers with its local association between forwarding paths and colors. At least one path MUST be defined as the "default" path. This path SHOULD be used as a second best match in the absence of an exact color match. If the Color LSR does not have an association between colors and paths or is a legacy LSR not supporting the Color LSP extensions, all paths SHOULD be treated as default paths.

To setup LSPs corresponding to FECs under a given color scope, the applicable LDP FEC elements () must be extended to include the color information. The Color Id becomes an attribute of such LDP FEC elements, and all FEC-Label binding operations are performed under the context of the given color. To be able to associate a color with a FEC, we define new "color" address families as follows: Color IP (version 4) Color IPv6 These address families just extend the format of their base address family by including color information. The format of data associated with these new address families is described later in sections and . The proposed new address families can be used in any LDP message and procedures defined for Color LSPs. If a receiver does not support these address families received in a message, it SHOULD send "Unknown Address Family" notification back to the sender and discard the message.

The format of data associated with Color IP (version 4) address family is:

"Color IP (version 4)" Address Family Format IPv4 prefix for "Color IP (version 4)" address family Color identifiers associated with IP (version 4) address The address length for Color IP address family is 8 octets.

The format of data associated with Color IPv6 address family is:

"Color IPv6" Address Family Format IPv6 prefix for "Color IPv6" address family Color identifiers associated with IPv6 address The address length for Color IP address family is 20 octets.

The following subsection defines the format of the LDP Color FEC elements () as well as their Typed wildcard counterparts.

"Color Prefix" FEC element The definition of these fields follows and . The Prefix field can be either an IP (version 4) or an IPv6 address.

EDITOR NOTE: To be included in a later version.

extends base LDP and defines Typed Wildcard FEC Element framework. Typed Wildcard FEC element can be used in any LDP message to specify a wildcard operation for the given type of FEC. The Color LSP extensions proposed in this document do not require any extension in the procedures for Typed Wildcard FEC Element support in . The encoding for a Color Prefix Typed Wildcard FEC element is as follows:

"Color Prefix Typed Wildcard" FEC element The definition of these fields follows and . The Color Prefix Typed Wildcard FEC allows an LSR to perform wildcard FEC operations under the scope of a specific color. For example, upon local configuration of color LSP feature for a color C, an LSR may send a wildcard label request with Color Id C to learn all its labels from the peer under the scope of that color. If an LSR wishes to perform a wildcard operation that applies to all colors, it can use the "wildcard color" Color Id.

specifies extensions and procedures that allows an LDP speaker to signal its convergence for a given FEC type towards a peer using the corresponding Typed Wildcard FEC element. Color LSP extensions for FECs do not require any change in these procedures and they apply as-is to these extended FEC elements. For instance, an LDP speaker MAY signal its LIB convergence per color (or for all colors) using a Color Prefix Typed Wildcard FEC element.

defines procedures to detect MPLS LSP data-plane failures via LSP ping. The section 3.2 of defines Sub-Types and formats for Sub-TLVs corresponding to FECs. For "Prefix" FEC, it defines "LDP IPv4 prefix" and "LDP IPv6 prefix" sub-types and TLVs. To support LSP ping for Color LDP LSPs, this document proposes following extensions to [RFC4379]: New FEC types: Color LDP IPv4 FEC, and Color LDP IPv6 FEC New sub-types: for sub-TLVs to specify these FECs in the "Target FEC Stack" TLV of [RFC4379]

The format of these new FEC types is defined as an extension to the format of LDP IPv4 prefix and LDP IPv6 prefix sub-TLV by adding color information. The encoding for a Color LDP IP (version 4) and IPv6 FEC sub-TLVs is as follows:

"Color LDP IP (version 4)" FEC sub-TLV for LSP ping

"Color LDP IPv6" FEC sub-TLV for LSP ping The Color Id value MUST NOT be the "Wildcard Color".

EDITOR NOTE: To be included in a later version.

This document defines the following new LDP extensions: "Color LSP Capability" (codepoint to be allocated from LDP registry "TLV Type Name Space") Color List TLV (codepoint to be allocated from LDP registry "TLV Type Name Space") Color Address Families (from registry "Address Familiy Numbers") Color IP (version 4) Color IPv6 New Sub-TLV Types under TLV type 1 (Target FEC Stack) from "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry, and "TLVs and sub-TLVs" sub-registry.

IANA is requested to assign the LDP capability code point and the type values of these TLVs.

The MPLS security framework and the security considerations in the LDP specification apply to this document.