| Internet Engineering Task Force | S. Alvarez |
| Internet-Draft | K. Raza |
| Intended status: Standards Track | S. Boutros |
| Expires: January 12, 2014 | Cisco Systems, Inc. |
| July 11, 2013 |
Signaling Color Label Switched Paths Using LDP
draft-alvarez-mpls-ldp-color-lsp-00
This document describes extensions to the Label Distribution Protocol (LDP) to signal a switching preference in the presence of multiple paths. A label switched router (LSR) can associate locally a color with one or more downstream paths or links, and signal a label path per color to upstream LSRs. Based on local policy, LSRs can select between these color LSPs to implement a forwarding preference on a downstream LSR. An egress LSR may influence the signaling decision of other LSRs by signaling interest in specific colors.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 12, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119].
A color LSP can be defined for the following types of LDP FEC elements:
and for the following address families:
Three LSR roles can be involved in establishing a color LSP:
Figure 1 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.
P1
------
/ \
/ P2 \
LSRa --- LSRb ---- LSRc
\ /
\ /
------
P3
Example of a color LSP scenario
Figure 1
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 (Section 2). The capability follows the format and procedures defined in [RFC5561] and may be signaled in LDP Initialization or Capability messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Color LSP Capability(IANA)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ |
~ Color LSP Capability Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color LSP Capability" TLV
Figure 2
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 [RFC5918]). 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[RFC5036]. The list includes one or more color identifiers that LSRs may use to signal interest in a forwarding preference.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Color List (IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Ids |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color List" TLV
Figure 3
A Color Id is a two octet field defined as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color identifier" field
Figure 4
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 (Section 4) 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 (Section 2) 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:
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 Section 6.1 and Section 6.2. 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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color IP (version 4)" Address Family Format
Figure 5
The address length for Color IP address family is 8 octets.
The format of data associated with Color IPv6 address family is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color IPv6" Address Family Format
Figure 6
The address length for Color IP address family is 20 octets.
The following subsection defines the format of the LDP Color FEC elements (Section 2) as well as their Typed wildcard [RFC5918] counterparts.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | AF (Color IP/Color IPv6) | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Prefix ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color Prefix" FEC element
Figure 7
The definition of these fields follows Section 6 and [RFC5036]. The Prefix field can be either an IP (version 4) or an IPv6 address.
EDITOR NOTE: To be included in a later version.
EDITOR NOTE: To be included in a later version.
[RFC5918] 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 [RFC5918].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| FEC Type (2) | Len = 6 | AF=Color IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|. or Color IPv6| Color Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The encoding for a Color Prefix Typed Wildcard FEC element is as follows:
"Color Prefix Typed Wildcard" FEC element
Figure 8
The definition of these fields follows [RFC5918] and Section 5.1.
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.
[RFC5919] 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.
[RFC4379] defines procedures to detect MPLS LSP data-plane failures via LSP ping. The section 3.2 of [RFC4379] 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]:
Sub-Type Length Value Field
-------- ------ --------------------
TBA1 5 Color LDP IPv4 prefix
TBA2 17 Color LDP IPv6 prefix
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Color LDP IPv4 FEC (TBA1) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | Color Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Figure 9
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=Color LDP IPv6 FEC (TBA2) | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | MBZ | Color Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color LDP IPv6" FEC sub-TLV for LSP ping
Figure 10
EDITOR NOTE: To be included in a later version.
This document defines the following new LDP extensions:
Sub-Type Value Field
-------- ------ --------------------
TBA1 5 Color LDP IPv4 prefix
TBA2 17 Color LDP IPv6 prefix
IANA is requested to assign the LDP capability code point and the type values of these TLVs.
The MPLS security framework [RFC5920] and the security considerations in the LDP specification [RFC5036] apply to this document.
| [RFC3031] | Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. |
| [RFC5920] | Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. |