Internet DRAFT - draft-alvarez-mpls-ldp-color-lsp
draft-alvarez-mpls-ldp-color-lsp
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
Abstract
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.
Status of This Memo
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 Notice
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
Alvarez, et al. Expires January 12, 2014 [Page 1]
Internet-Draft LDP Color LSP Signaling July 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Applicability of Colors to FEC Elements . . . . . . . . . . . 3
3. Establishing Color LSPs . . . . . . . . . . . . . . . . . . . 3
4. LDP Color LSP Capability . . . . . . . . . . . . . . . . . . 5
5. Color Lists . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Color List TLV . . . . . . . . . . . . . . . . . . . . . 6
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 7
6. Color Address Families . . . . . . . . . . . . . . . . . . . 8
6.1. Color IP Address Family . . . . . . . . . . . . . . . . . 9
6.2. Color IPv6 Address Family . . . . . . . . . . . . . . . . 9
7. Color FECs . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Color Prefix FEC Element . . . . . . . . . . . . . . . . 10
7.2. Color Multipoint FEC Elements . . . . . . . . . . . . . . 10
7.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10
8. Other FEC-based Features . . . . . . . . . . . . . . . . . . 10
8.1. Typed Wildcard Forward Equivalence Class . . . . . . . . 10
8.2. Signaling Convergence (End-of-LIB) . . . . . . . . . . . 11
8.3. LSP Ping Extensions . . . . . . . . . . . . . . . . . . . 11
8.3.1. Color Prefix FEC . . . . . . . . . . . . . . . . . . 11
8.3.2. Color Multipoint FEC . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
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.
Alvarez, et al. Expires January 12, 2014 [Page 2]
Internet-Draft LDP Color LSP Signaling July 2013
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.
1.1. Requirements Language
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].
2. Applicability of Colors to FEC Elements
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)
3. Establishing Color LSPs
Three LSR roles can be involved in establishing a color LSP:
Color LSR:
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.
Alvarez, et al. Expires January 12, 2014 [Page 3]
Internet-Draft LDP Color LSP Signaling July 2013
Ingress LSR:
Selects between color paths associated with a given FEC to
influence the forwarding by downstream color LSRs.
Egress LSR:
May signal interest in particular colors towards upstream LSRs in
order to influence the signaling behavior of color LSRs.
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
Alvarez, et al. Expires January 12, 2014 [Page 4]
Internet-Draft LDP Color LSP Signaling July 2013
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.
4. LDP Color LSP Capability
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
U/F-bits:
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.
Length:
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.
S-bit:
Set to 1 or 0 to advertise or withdraw the capability respectively
as specified in [RFC5561].
Alvarez, et al. Expires January 12, 2014 [Page 5]
Internet-Draft LDP Color LSP Signaling July 2013
Reserved:
Must be set to zero on transmission and ignored on receipt
Color LSP Capability Data:
This is capability-specific data that is defined for Color LSPs.
It consists of a Typed Wildcard FEC Element [RFC5918] 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 Section 2. If a receiver receives this TLV with a
Typed Wildcard FEC of type other than those defined in Section 2,
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 [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.
5. Color Lists
5.1. Color List TLV
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Alvarez, et al. Expires January 12, 2014 [Page 6]
Internet-Draft LDP Color LSP Signaling July 2013
| Color Ids |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color List" TLV
Figure 3
U/F-bits:
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.
Length:
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.
Color Ids:
List of color identifiers associated with the FEC encoded in the
message.
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
Color Id:
(non-zero) unsigned color identifier. Color Id 0xFFFF refers to
the "wildcard color" (i.e. all colors).
5.2. Procedures
Alvarez, et al. Expires January 12, 2014 [Page 7]
Internet-Draft LDP Color LSP Signaling July 2013
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.
6. Color Address Families
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:
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
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.
Alvarez, et al. Expires January 12, 2014 [Page 8]
Internet-Draft LDP Color LSP Signaling July 2013
6.1. Color IP Address Family
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
Prefix:
IPv4 prefix for "Color IP (version 4)" address family
Color Id:
Color identifiers associated with IP (version 4) address
The address length for Color IP address family is 8 octets.
6.2. Color IPv6 Address Family
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
Prefix:
IPv6 prefix for "Color IPv6" address family
Alvarez, et al. Expires January 12, 2014 [Page 9]
Internet-Draft LDP Color LSP Signaling July 2013
Color Id:
Color identifiers associated with IPv6 address
The address length for Color IP address family is 20 octets.
7. Color FECs
The following subsection defines the format of the LDP Color FEC
elements (Section 2) as well as their Typed wildcard [RFC5918]
counterparts.
7.1. Color Prefix FEC Element
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.
7.2. Color Multipoint FEC Elements
EDITOR NOTE: To be included in a later version.
7.3. Procedures
EDITOR NOTE: To be included in a later version.
8. Other FEC-based Features
8.1. Typed Wildcard Forward Equivalence Class
[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].
Alvarez, et al. Expires January 12, 2014 [Page 10]
Internet-Draft LDP Color LSP Signaling July 2013
The encoding for a Color Prefix Typed Wildcard FEC element is as
follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"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.
8.2. Signaling Convergence (End-of-LIB)
[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.
8.3. LSP Ping Extensions
8.3.1. Color Prefix FEC
[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]:
New FEC types: Color LDP IPv4 FEC, and Color LDP IPv6 FEC
Alvarez, et al. Expires January 12, 2014 [Page 11]
Internet-Draft LDP Color LSP Signaling July 2013
New sub-types: for sub-TLVs to specify these FECs in the "Target
FEC Stack" TLV of [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.
The encoding for a Color LDP IP (version 4) and IPv6 FEC sub-TLVs is
as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"Color LDP IP (version 4)" FEC sub-TLV for LSP ping
Figure 9
Alvarez, et al. Expires January 12, 2014 [Page 12]
Internet-Draft LDP Color LSP Signaling July 2013
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
The Color Id value MUST NOT be the "Wildcard Color".
8.3.2. Color Multipoint FEC
EDITOR NOTE: To be included in a later version.
9. IANA Considerations
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.
Sub-Type Value Field
-------- ------ --------------------
TBA1 5 Color LDP IPv4 prefix
TBA2 17 Color LDP IPv6 prefix
Alvarez, et al. Expires January 12, 2014 [Page 13]
Internet-Draft LDP Color LSP Signaling July 2013
IANA is requested to assign the LDP capability code point and the
type values of these TLVs.
10. Security Considerations
The MPLS security framework [RFC5920] and the security considerations
in the LDP specification [RFC5036] apply to this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, August 2010.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919,
August 2010.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
11.2. Informative References
[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.
Alvarez, et al. Expires January 12, 2014 [Page 14]
Internet-Draft LDP Color LSP Signaling July 2013
Authors' Addresses
Santiago Alvarez
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: saalvare@cisco.com
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, ON K2K-3E8
Canada
Email: skraza@cisco.com
Sami Boutros
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sboutros@cisco.com
Alvarez, et al. Expires January 12, 2014 [Page 15]
