Multipoint LDP Extensions for Multi-Topology RoutingIndividualice@braindump.beCisco Systems, Inc.821 Alder DriveMilpitas95035CAUnited States of Americamankamis@cisco.comCisco Systems, Inc.2000 Innovation DriveKanataK2K-3E8ONCanadaskraza@cisco.comJuniper Networks10 Technology Park Dr.WestfordMA01886United States of Americazzhang@juniper.netEdward Jones Wealth ManagementUnited States of AmericaArkadiy.gulko@edwardjones.com
RTG
mplsMPLSmLDPMulti-topology
Multi-Topology Routing (MTR) is a technology that enables service
differentiation within an IP network. The Flexible Algorithm (FA) is
another mechanism for creating a sub-topology within a topology using
defined topology constraints and computation algorithms. In order to
deploy Multipoint LDP (mLDP) in a network
that supports MTR, FA, or other methods of signaling non-default
IGP Algorithms (IPAs), mLDP is required to become topology and
algorithm aware. This document specifies extensions to mLDP to support the use of
MTR/IPAs such that, when building multipoint Label Switched Paths (LSPs), the LSPs can follow a
particular topology and algorithm.
This document updates RFC 7307 by allocating
eight bits from a previously reserved field to be used as the "IPA" field.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2024 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
() 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Abbreviations
. Specification of Requirements
. MT-Scoped mLDP FECs
. MP FEC Extensions for MT
. MP FEC Element
. MT IP Address Families
. MT MP FEC Element
. Topology IDs
. MT Multipoint Capability
. MT Applicability on FEC-Based Features
. Typed Wildcard MP FEC Elements
. End-of-LIB
. Topology-Scoped Signaling and Forwarding
. Upstream LSR Selection
. Downstream Forwarding Interface Selection
. LSP Ping Extensions
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Contributors
Acknowledgments
Authors' Addresses
IntroductionMulti-Topology Routing (MTR) is a technology that enables service differentiation within an IP network. IGPs (e.g., OSPF and IS-IS) and LDP have already been extended to support MTR. To support MTR, an IGP maintains distinct IP topologies referred to as "Multi-Topologies" (or "MTs"), and computes and installs routes specific to each topology. OSPF extensions (see ) and IS-IS extensions (see ) specify the MT extensions under respective IGPs. To support IGP MT, similar LDP extensions (see ) have been specified to make LDP be MT aware and to be able to set up unicast Label Switched Paths (LSPs) along IGP MT routing paths.
A more lightweight mechanism to define constraint-based topologies is
the Flexible Algorithm (FA) (see ).
The FA is
another mechanism for creating a sub-topology within a topology using
defined topology constraints and computation algorithms.
This can be done within an MTR topology or
the default topology. An instance of such a sub-topology is
identified by a 1-octet value (Flexible Algorithm) as documented in
. At the time of writing, an FA is a mechanism to create a sub-topology; in
the future, different algorithms might be defined for this purpose. Therefore, in the remainder of this
document, we'll refer to this as the "IGP Algorithm" or "IPA". The "IPA"
field (see Sections and ) is an 8-bit identifier for the algorithm.
The permissible values are tracked in the "IGP Algorithm Types"
registry .
Throughout this document, the term "Flexible Algorithm" (or "FA") shall denote the process of generating a sub-topology and signaling it through the IGP. However, it is essential to note that the procedures outlined in this document are not exclusively applicable to the FA: they are extendable to any non-default algorithm as well.
"Multipoint LDP" (or "mLDP") refers to extensions in LDP to set up multipoint LSPs (i.e., point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) LSPs) by means of a set of extensions and procedures defined in . In order to deploy mLDP in a network that supports MTR and the FA, mLDP is required to become topology and algorithm aware. This document specifies extensions to mLDP to support the use of
MTR/IPAs such that, when building multipoint LSPs, it can follow a
particular topology and algorithm. Therefore, the identifier for the particular topology to be used by mLDP has to become a 2-tuple {MTR Topology Id, IPA}.
TerminologyAbbreviations
FA:
Flexible Algorithm
FEC:
Forwarding Equivalence Class
IGP:
Interior Gateway Protocol
IPA:
IGP Algorithm
LDP:
Label Distribution Protocol
LSP:
Label Switched Path
mLDP:
Multipoint LDP
MP:
Multipoint
MP2MP:
Multipoint-to-Multipoint
MT:
Multi-Topology
MT-ID:
Multi-Topology Identifier
MTR:
Multi-Topology Routing
MVPN:
Multicast VPN in
P2MP:
Point-to-Multipoint
PMSI:
Provider Multicast Service Interfaces
Specification of Requirements
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in all capitals, as
shown here.
MT-Scoped mLDP FECsAs defined in , an MPLS Multi-Topology Identifier (MT-ID) is used to associate an LSP with a certain MTR topology. In the context of MP LSPs, this identifier is part of the mLDP FEC encoding; this is so that LDP peers are able to set up an MP LSP via their own defined MTR policy. In order to avoid conflicting MTR policies for the same mLDP FEC, the
MT-ID needs to be a part of the FEC. This ensures that different MT-ID values
will result in unique MP-LSP FEC elements.
The same applies to the IPA. The IPA needs to be encoded as part of the mLDP FEC to create unique MP LSPs. The IPA is also used to signal to the mLDP (hop-by-hop) which algorithm needs to be used to create the MP LSP.
Since the MT-ID and IPA are part of the FEC, they apply to all the LDP messages that potentially include an mLDP FEC element.
MP FEC Extensions for MT
The following subsections define the extensions to bind an mLDP FEC to
a topology. These mLDP MT extensions reuse some of the extensions
specified in .
MP FEC Element
The base mLDP specification () defines the MP FEC element as follows:
MP FEC Element Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | Address Family | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where the "Root Node Address" field encoding is defined according to the given "Address
Family" field with its length (in octets) specified by the "AF Length" field.
To extend MP FEC elements for MT, the {MT-ID, IPA} tuple is relevant in the
context of the root address of the MP LSP. This tuple determines the
(sub-)topology in which the root address needs to be resolved. As the {MT-ID,
IPA} tuple should be considered part of the mLDP FEC, it is most naturally
encoded as part of the root address.
MT IP Address Families specifies new address families, named "MT IP" and "MT IPv6," to
allow for the specification of an IP prefix within a topology scope. In addition
to using these address families for mLDP, 8 bits of the 16-bit "Reserved" field that was described in RFC 7307
are utilized to encode the IPA. The resulting format
of the data associated with these new address families is as follows:
Modified Format for MT IP Address Families
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
IPv4 Address and IPv6 Address:
An IP address corresponding to the "MT IP" and "MT IPv6" address families, respectively.
IPA:
The IGP Algorithm.
Reserved:
This 8-bit field MUST be zero on transmission and MUST be ignored on receipt.
MT MP FEC Element
When using the extended "MT IP" address family, the resulting MT-Scoped MP
FEC element should be encoded as follows:
Format for an IP MT-Scoped MP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MP FEC type | AF (MT IP/ MT IPv6) | AF Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Node Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the context of this document, the applicable LDP FECs for MT mLDP ()
include:
MP FEC elements:
P2MP (type 0x6)
MP2MP-up (type 0x7)
MP2MP-down (type 0x8)
Typed Wildcard FEC Element (type 0x5 defined in )
In the case of the Typed Wildcard FEC Element, the FEC element type
MUST be one of the MP FECs listed above.
This specification allows the use of topology-scoped mLDP FECs in
LDP labels and notification messages, as applicable.
defines the PMSI tunnel
attribute for MVPN and specifies that:
when the Tunnel Type is set
to mLDP P2MP LSP, the Tunnel Identifier is a P2MP FEC element, and
when the Tunnel Type is set to mLDP MP2MP LSP, the Tunnel Identifier is an MP2MP FEC element.
When
the extension defined in this specification is in use, the IP
MT-Scoped MP FEC element form of the respective FEC
elements MUST be used in these two cases.
Topology IDs
This document assumes the same definitions and procedures associated
with MPLS MT-ID as specified in .
MT Multipoint Capability
The "MT Multipoint" capability is a new LDP capability, defined in
accordance with the LDP capability definition guidelines outlined in
. An mLDP speaker advertises
this capability to its peers to announce its support for MTR and the
procedures specified in this document. This capability
MAY be sent either in an Initialization message at
session establishment or dynamically during the session's lifetime via
a Capability message, provided that the "Dynamic Announcement"
capability from has been
successfully negotiated with the peer.
The format of this capability is as follows:
Format for the MT Multipoint 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MT Multipoint Capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Where:
U and F bits:
MUST be 1 and 0, respectively, as per .
MT Multipoint Capability:
The TLV type.
Length:
This field specifies the length of the TLV in
octets. The value of this field MUST be 1, as there
is no capability-specific data following the TLV.
S bit:
Set to 1 to announce and 0 to withdraw the capability (as per
).
An mLDP speaker that has successfully advertised and negotiated the "MT
Multipoint" capability MUST support the following:
Topology-scoped mLDP FECs in LDP messages ()
Topology-scoped mLDP forwarding setup ()
MT Applicability on FEC-Based FeaturesTyped Wildcard MP FEC Elements extends the base LDP and defines the Typed Wildcard FEC Element
framework. A Typed Wildcard FEC Element can be used in any LDP message
to specify a wildcard operation for a given type of FEC.
The MT extensions defined in this document do not require any
extension to procedures for support of the Typed Wildcard FEC Element , and these procedures apply as is
to Multipoint MT FEC wildcarding. Similar to the Typed Wildcard MT Prefix
FEC element, as defined in ,
the MT extensions allow the use of "MT IP" or "MT IPv6" in the
"Address Family" field of the Typed Wildcard MP FEC Element. This is
done in order to use wildcard operations for MP FECs in the context
of a given (sub-)topology as identified by the "MT-ID" and "IPA" fields.
This document defines the following format and encoding for a Typed
Wildcard MP FEC Element:
Format for the Typed Wildcard MT MP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Typed Wcard (5)| Type = MP FEC | Len = 6 | AF = MT IP ..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|... or MT IPv6 | Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MT-ID (cont.) |
+-+-+-+-+-+-+-+-+
Where:
Type:
One of the MP FEC element types (P2MP, MP2MP-up, or MP2MP-down)
MT-ID:
MPLS MT-ID
IPA:
The IGP Algorithm
The defined format allows a Label Switching Router (LSR) to perform wildcard MP FEC
operations under the scope of a (sub-)topology.
End-of-LIB specifies extensions and
procedures that allow an LDP speaker to signal its End-of-LIB (Label Information Base) for a
given FEC type to a peer. By leveraging the End-of-LIB message, LDP
ensures that label distribution remains consistent and reliable,
even during network disruptions or maintenance activities. The MT
extensions for MP FEC do not require any modifications to these
procedures and apply as they are to MT MP FEC elements. Consequently, an
MT mLDP speaker MAY signal its convergence per
(sub-)topology using the MT Typed Wildcard MP FEC Element.
Topology-Scoped Signaling and Forwarding
Since the {MT-ID, IPA} tuple is part of an mLDP FEC, there is no need to support
the concept of multiple (sub-)topology forwarding tables in mLDP. Each MP LSP will be
unique due to the tuple being part of the FEC. There is also no need
to have specific label forwarding tables per topology, and each MP
LSP will have its own unique local label in the table. However, in
order to implement MTR in an mLDP network, the selection procedures
for an upstream LSR and a downstream forwarding interface need to be
changed.
Upstream LSR Selection
The procedures described in depend on
the best path to reach the root. When the {MT-ID, IPA} tuple is signaled as part
of the FEC, the tuple is also used to select the (sub-)topology that must be
used to find the best path to the root address. Using the next-hop
from this best path, an LDP peer is selected following the procedures
defined in .
Downstream Forwarding Interface Selection describes the procedures for how
a downstream forwarding interface is selected. In these procedures,
any interface leading to the downstream LDP neighbor can be
considered to be a candidate forwarding interface. When the {MT-ID, IPA} tuple is part
of the FEC, this is no longer true. An interface must only be
selected if it is part of the same (sub-)topology that was signaled in the
mLDP FEC element. Besides this restriction, the other procedures in
apply.
LSP Ping Extensions defines procedures to detect data plane failures in
multipoint MPLS LSPs. defines new sub-types and sub-TLVs for Multipoint LDP FECs to be sent in the "Target FEC
Stack" TLV of an MPLS Echo Request message .
To support LSP ping for MT MP LSPs, this document uses
existing sub-types "P2MP LDP FEC Stack" and "MP2MP LDP FEC Stack"
defined in . The LSP ping extension is to specify "MT IP"
or "MT IPv6" in the "Address Family" field, set the "Address Length"
field to 8 (for MT IP) or 20 (for MT IPv6), and encode the sub-TLV
with additional {MT-ID, IPA} information as an extension to the "Root LSR
Address" field. The resultant format of sub-TLV is as follows:
Multipoint LDP FEC Stack Sub-TLV Format for MT
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Family (MT IP/MT IPv6) | Address Length| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Root LSR Address (Cont.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | IPA | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The rules and procedures of using this new sub-TLV in an MPLS Echo
Request message are the same as defined for the P2MP/MP2MP LDP FEC Stack
sub-TLV in . The only
difference is that the "Root LSR Address" field is now (sub-)topology scoped.
Security Considerations
This extension to mLDP does not introduce any new security
considerations beyond what is already applied to the base LDP
specification , the LDP
extensions for Multi-Topology specification , the base mLDP specification , and the MPLS security framework specification .
IANA Considerations
This document defines a new LDP capability parameter TLV called the "MT Multipoint Capability". IANA has assigned the value 0x0510 from the
"TLV Type Name Space" registry in the "Label Distribution Protocol (LDP)
Parameters" group as the new code point.
MT Multipoint Capability
Value
Description
Reference
Notes/Registration Date
0x0510
MT Multipoint Capability
RFC 9658
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Multi-Topology (MT) Routing in OSPFThis document describes an extension to Open Shortest Path First (OSPF) in order to define independent IP topologies called Multi- Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.An optional extension to exclude selected links from the default topology is also described. [STANDARDS-TRACK]M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched PathsThis document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK]Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP PingRecent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs.The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.This document updates RFC 4379. [STANDARDS-TRACK]Multicast in MPLS/BGP IP VPNsIn order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK]BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNsThis document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK]LDP Extensions for Multi-TopologyMulti-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks, new extensions are required.This document describes the LDP protocol extensions required to support MT routing in an MPLS environment.Detecting Multiprotocol Label Switched (MPLS) Data-Plane FailuresThis document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.IGP Flexible AlgorithmIGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths.Informative ReferencesIGP Algorithm TypesIANALDP SpecificationThe architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK]LDP CapabilitiesA number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment. [STANDARDS-TRACK]Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)The Label Distribution Protocol (LDP) specification for the Wildcard Forward Equivalence Class (FEC) element has several limitations. This document addresses those limitations by defining a Typed Wildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. [STANDARDS-TRACK]Signaling LDP Label Advertisement CompletionThere are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. [STANDARDS-TRACK]Security Framework for MPLS and GMPLS NetworksThis document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes.ContributorsCisco SystemsAcknowledgments
The authors would like to acknowledge for his input on
this specification.
Authors' AddressesIndividualice@braindump.beCisco Systems, Inc.821 Alder DriveMilpitas95035CAUnited States of Americamankamis@cisco.comCisco Systems, Inc.2000 Innovation DriveKanataK2K-3E8ONCanadaskraza@cisco.comJuniper Networks10 Technology Park Dr.WestfordMA01886United States of Americazzhang@juniper.netEdward Jones Wealth ManagementUnited States of AmericaArkadiy.gulko@edwardjones.com