"Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute", Riza Cetin, 19-Nov-07. ( bytes)

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method.

"MPLS Traffic Engineering Soft Preemption", Denver Maddux, Curtis Villamizar, Amir Birjandi, and Swallow, JP Vasseur, 18-Feb-08. ( bytes)

This document details Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/ eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a preemption pending flag helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities.

"Component Link Recording and Resource Control for TE Link Bundles", Anca Zamfir, 2-Apr-08. ( bytes)

Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles.

"MPLS Multicast Encapsulations", Toerless Eckert, Eric Rosen, Rahul Aggarwal, Yakov Rekhter, 1-May-08. ( bytes)

RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the "multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label". RFC 3032 does not specify the destination address to be placed in the "MAC DA" field of an ethernet frame which carries an MPLS multicast packet. This document provides that specification. This document updates RFC 3032 and RFC 4023.

"Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, 22-Feb-08. ( bytes)

This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP without requiring a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/MP2MP LSP is outside the scope of this document.

"MPLS Upstream Label Assignment and Context-Specific Label Space", Rahul Aggarwal, Yakov Rekhter, Eric Rosen, 30-Apr-08. ( bytes)

RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space".

"MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 18-Nov-07. ( bytes)

This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs.

"MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 19-Nov-07. ( bytes)

This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs.

"Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol", Jean-Louis Le Roux, 25-Feb-08. ( bytes)

This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements.

"A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link", JP Vasseur, Matthew Meyer, Kenji Kumaki, Alberto Bonda, 6-Feb-08. ( bytes)

Several Link-type sub-TLVs have been defined for OSPF and IS-IS in the context of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group and so on. By making statistical assumption about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwith (referred to as unconstrained TE LSP in this document), and with the knowledge of the number of unconstrained TE LSPs signalled across a link, algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSP(s) signalled across a link.

"Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, Seisho Yasukawa, Thomas Nadeau, 30-Apr-08. ( bytes)

This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802.

"LDP Typed Wildcard FEC", Bob Thomas, Ina Minei, 26-Mar-08. ( bytes)

The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036.

"Proxy LSP Ping", George Swallow, Vanson Lim, 19-Nov-07. ( bytes)

This document defines a means of remotely initiating Multiprocal Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to root tracing.

"P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", Jean-Louis Le Roux, 27-Feb-08. ( bytes)

This document defines procedures for fast reroute protection of Point-To-MultiPoint (P2MP) Traffic Engineering Label Switched Paths (TE-LSP) in MultiProtocol Label Switching (MPLS) networks, based upon Point-To-MultiPoint Bypass Tunnels. The motivation for using P2MP Bypass Tunnels is to avoid potentially expensive data duplication along the backup path that could occur if Point-To-Point Bypass Tunnels were used, i.e., to optimize the bandwidth usage, during fast reroute protection of a link or a node. During link or node failure the traffic carried onto a protected P2MP TE-LSP is tunnelled within one or several P2MP Bypass Tunnels towards a set of Merge Points. To avoid data duplication, backup labels (i.e., inner labels) are assigned by the Point of Local Repair (PLR) according to the RSVP-TE upstream label assignment procedure.

"LDP Capabilities", Bob Thomas, 26-Mar-08. ( bytes)

A 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. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable enhancements after LDP session establishment.

"Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message", JP Vasseur, George Swallow, Ina Minei, 18-Feb-08. ( bytes)

The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions.

"LDP extension for Inter-Area LSP", Bruno Decraene, 25-Feb-08. ( bytes)

To facilitate the establishment of Label Switched Paths (LSP) that would span multiple IGP areas in a given Autonomous System (AS), this document proposes a new optional label mapping procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the routing table (RIB). Matching is defined by an IP longest match search and does not mandate an exact match.

"Security Framework for MPLS and GMPLS Networks", Luyuan Fang, 25-Feb-08. ( bytes)

This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and [RFC3945]). 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.

"An Analysis of Scaling Issues in MPLS-TE Core Networks", Seisho Yasukawa, Adrian Farrel, Olufemi Komolafe, 24-Apr-08. ( bytes)

Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies, and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document considers only scalability for point-to-point MPLS-TE. Point-to-multipoint MPLS-TE is for future study.

"LDP IGP Synchronization", Markus Jork, Alia Atlas, Luyuan Fang, 24-Mar-08. ( bytes)

In certain networks there is a dependency on edge-to-edge LSPs setup by LDP, e.g. networks that are used for MPLS VPN applications. For such applications it is not possible to rely on IP forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the IGP is operational on a link but LDP is not operational on that link. While the link could still be used for IP forwarding, it is not useful for traffic with packets carrying a label stack of more than one label or when the IP address carried in the packet is out of the RFC1918 space. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes.

Return to Internet-Draft directory.

Return to IETF home page.