RFC 7060

Using LDP Multipoint Extensions on Targeted LDP Sessions

📅 published November 2013, from ietf

RFC 7060 🎀 Using LDP Multipoint Extensions on Targeted LDP Sessions

Okay bestie, this one is an IETF Standards Track doc, so it's official-official and every word counts 💅

  • Publisher: Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 7060
  • Authors: M. Napierala (AT&T), E. Rosen, and IJ. Wijnands (Cisco Systems, Inc.) 👑
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: November 2013 🍓
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🧚

Abstract

Okay so LDP (Label Distribution Protocol) can set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths 🦋. The tea ☕ is that the Multipoint Extensions to LDP assume the two endpoints of an LDP session are directly connected. The LDP base spec does allow the endpoints to be not directly connected, and that's called a "Targeted LDP" session. This doc is the spec for using the LDP Multipoint Extensions over a Targeted LDP session 💖

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 5741 ✨

Info about the current status of this doc, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc7060 🌈

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, because 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 📜

Table of Contents

1. Introduction ....................................................2
2. Targeted mLDP and the Upstream LSR ..............................3
   2.1. Selecting the Upstream LSR .................................3
   2.2. Sending Data from U to D ...................................4
3. Applicability of Targeted mLDP ..................................4
4. LDP Capabilities ................................................5
5. Targeted mLDP with Unicast Replication ..........................5
6. Targeted mLDP with Multicast Tunneling ..........................6
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. Normative References ............................................8

1. Introduction ✨

So LDP extensions for setting up Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) and Multipoint-to-Multipoint (MP2MP) LSPs are specified in [mLDP]. This whole set of extensions is generally known as "Multipoint LDP" (mLDP) 🦋

A pair of Label Switched Routers (LSRs) that are the endpoints of an LDP session are considered to be "LDP peers". When a pair of LDP peers are "directly connected" (for example, they're linked by a layer 2 medium or are otherwise considered neighbors by the network's interior routing protocol), the LDP session is said to be a "directly connected" LDP session. When the LDP peers are not directly connected, the session between them is said to be a "Targeted" LDP session 💅

The base spec for mLDP doesn't explicitly cover the case where the LDP multipoint extensions are used over a Targeted LDP session. This doc fills that gap 🎀

We'll use the term "Multipoint" to mean "either P2MP or MP2MP" 🌸

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 [RFC2119] 📜

2. Targeted mLDP and the Upstream LSR 👑

2.1. Selecting the Upstream LSR

In mLDP, a multipoint LSP (MP-LSP) has a unique identifier that's an ordered pair of the form <root, opaque value>. The first element of that pair is the IP address of the MP-LSP's "root node". The second element is an identifier that's unique in the context of the root node 🍓

If LSR D is setting up the MP-LSP <R, X>, D must determine the "upstream LSR" for <R, X>. In [mLDP], the upstream LSR for <R, X>, U, is defined to be the "next hop" on D's path to R, and "next hop" is tacitly assumed to mean "IGP next hop". So it's assumed there's a direct LDP session between D and U. In this spec, we stretch the notion of "upstream LSR" to cover these cases:

  • U is the "BGP next hop" on D's path to R, where U and D are not necessarily IGP neighbors, and where there is a Targeted LDP session between U and D. In this case, we allow D to select U as the "upstream LSR" for <R,X> 🦋
  • If the "next-hop interface" on D's path to R is an RSVP Traffic Engineering (RSVP-TE) P2P tunnel whose remote endpoint is U, and if there's known to be an RSVP-TE P2P tunnel from U to D, and if there is a Targeted LDP session between U and D, then we allow D to select U as the "upstream LSR" for <R,X>. This is useful when D and U are part of a network area that's fully meshed via RSVP-TE P2P tunnels 🌈

The particular method used to select an "upstream LSR" is determined by the Service Provider (SP) and must be made known a priori (i.e., by provisioning) to all the LSRs involved 🧚

Other methods than the two specified above MAY be used. However, specifying those other methods is outside the scope of this document 💖

2.2. Sending Data from U to D

By using Targeted mLDP, we can construct an MP-LSP <R,X> containing an LSR U, where U has one or more downstream LSR neighbors (D1, ..., Dn) that it's not directly connected to. For a data packet to travel along this MP-LSP, U has to have some way of transmitting the packet to D1, ..., Dn. We'll cover two methods of transmission 🫶

  • Unicast Replication

In this method, U creates n copies of the packet and unicasts each copy to exactly one of D1, ..., Dn 💅

  • Multicast Tunneling

In this method, U becomes the root node of a multicast tunnel, with D1, ..., Dn as leaf nodes. When a packet traveling along the MP-LSP <R,X> arrives at U, U transmits it through the multicast tunnel, and as a result it arrives at D1, ..., Dn 🔥

When this method is used, it may be desirable to carry traffic of multiple MP-LSPs through a single multicast tunnel. We specify procedures that allow for the proper demultiplexing of the MP-LSPs at the leaf nodes of the multicast tunnel. We don't assume that all the leaf nodes of the tunnel are on all the MP-LSPs traveling through the tunnel, so some of the tunnel leaf nodes may need to discard some of the packets received through the tunnel. For example, suppose MP-LSP <R1,X1> contains node U with downstream LSRs D1 and D2, while MP-LSP <R2,X2> contains node U with downstream LSRs D2 and D3. Suppose also there's a multicast tunnel with U as root and with D1, D2, and D3 as leaf nodes. U can aggregate both MP-LSPs in this one tunnel. However, D1 will have to discard packets that are traveling on <R2,X1>, while D3 will have to discard packets that are traveling on <R1,X2> 🙈

3. Applicability of Targeted mLDP 🌸

When LSR D is setting up MP-LSP <R,X>, it MUST NOT use Targeted mLDP unless D implements a procedure that can select an LSR U that is a Targeted mLDP peer of D as the "upstream LSR" for <R,X>. See Section 2.1 ⚠️

Whether D uses Targeted mLDP when this condition holds is decided by provisioning or by other methods outside the scope of this spec 🍓

When Targeted mLDP is used, the choice between unicast replication and multicast tunneling is determined by provisioning or by other methods outside the scope of this spec. It's presupposed that all nodes will have a priori knowledge of whether to use unicast replication or multicast tunneling. If it's the latter, it's presupposed that all nodes will have a priori knowledge of the type of multicast tunneling to use 👑

4. LDP Capabilities 💖

Per [mLDP], any LSR that needs to set up an MP-LSP must support the procedures of [LDP-CAP], and in particular must send and receive the P2MP Capability and/or the MP2MP Capability. This spec doesn't define any new capabilities. Advertising the P2MP and/or MP2MP Capabilities on a Targeted LDP session just means the advertising LSR can follow the procedures in this document 🧚

Some of the procedures here require the use of upstream-assigned labels [LDP-UP]. To use upstream-assigned labels as part of Targeted mLDP, an LSR must advertise the LDP Upstream-Assigned Label Capability [LDP-UP] on the Targeted LDP session 🦋

⏭️ Part 2 picks up with Section 5 (Targeted mLDP with Unicast Replication) 🌈

5. Targeted mLDP with Unicast Replication 🎀

Okay so when unicast replication is the method, the mLDP procedures are basically the same as what [mLDP] describes 💖, with one exception. If LSR D is setting up MP-LSP <R,X>, its "upstream LSR" gets picked using the procedures in Section 2.1, and it is not necessarily the "IGP next hop" on D's path to R 🧚.

Let's say LSRs D1 and D2 are both setting up the P2MP MP-LSP <R,X>, and LSR U is the upstream LSR on each of their paths to R. D1 and D2 each bind a label to <R,X>, and each one uses a Label Mapping message to tell U about its label binding. Suppose D1 picked L1 for <R,X> and D2 picked L2. (Fun fact: L1 and L2 could be the same value or different values, because D1 and D2 do not coordinate their label assignments 🙈.) When U has a packet to send on the MP-LSP <R,X>, it makes a copy, pushes on L1, and unicasts the result to D1. It also makes a second copy, pushes on L2, and unicasts that one to D2 💅.

This also works when MP-LSP <R,X> is an MP2MP LSP 🔥. Say that on top of L1 and L2, U has assigned L3 for <R,X> traffic received from D1, and L4 for <R,X> traffic received from D2. When U processes a packet with L3 at the top of its label stack, it knows the packet came from D1, so U sends a unicast copy to D2 after swapping L3 for L2. U does not send a copy back to D1 🙅‍♀️.

Note that all labels used in this procedure are downstream-assigned labels 🌸.

How the unicast actually happens is a local matter, outside the scope of this specification 🤷. The only requirement is that D1 receives the copy carrying L1 and processes the packet by looking up L1. (Same energy for D2: it must receive the copy carrying L2 and must process the packet by looking up L2.)

Also, if the method of unicast is MPLS, U will need to push another label on each copy of the packet before transmitting it. That label needs to ensure delivery of the packet to the appropriate LSR, D1 or D2. Penultimate-hop popping for that label is perfectly legitimate ✨.

6. Targeted mLDP with Multicast Tunneling 🦋

Suppose D1 and D2 are both setting up MP-LSP <R,X>, and LSR U is the upstream LSR on each of their paths to R. Since multicast tunneling is in use, when U has a packet to send on this MP-LSP, it does not necessarily send two copies, one to D1 and one to D2 😌. It may send just one copy, which then gets replicated somewhere downstream in the multicast tunnel. So the label that gets bound to the MP-LSP must be an upstream-assigned label assigned by U. This needs a change from the [mLDP] procedures 🔄. D1 and D2 do not send Label Mapping messages to U. Instead, they send Label Request messages to U, following the procedures of Section 4 of [LDP-UP], asking U to assign a label to the MP-LSP <R,X>. U responds with a Label Mapping message containing an upstream-assigned label L (using the procedures specified in [LDP-UP]). As part of that same Label Mapping message, U also sends an Interface TLV (as specified in [LDP-UP]) that identifies the multicast tunnel where data on the MP-LSP will be carried 🚇. When U transmits a packet on this tunnel, it first pushes on the upstream-assigned label L, and then pushes on the label that corresponds to the multicast tunnel.

If the numerical value L of the upstream-assigned label is 3, which [LDP] and [RFC3032] define as "Implicit NULL" 🫣, then the specified multicast tunnel will carry only the specified MP-LSP. In other words, no aggregation of multiple MP-LSPs into a single multicast tunnel is happening. In this case, no upstream-assigned label is pushed onto a packet that goes through the multicast tunnel.

There are various types of multicast tunnel that can be used 🌈. The choice of tunnel type is determined by provisioning, or by some other method that's outside the scope of this document. [LDP-UP] specifies encodings that let U identify an mLDP MP-LSP and an RSVP-TE P2MP LSP, as well as other types of multicast tunnel.

Procedures for tunneling MP2MP LSPs through P2MP or MP2MP LSPs are outside the scope of this document 🙃.

If the multicast tunnel is an mLDP MP-LSP or an RSVP-TE P2MP LSP, then when U transmits a packet on MP-LSP <R,X>, the upstream-assigned label L will be the second label in the label stack. Penultimate-hop popping MUST NOT be done, because the top label provides the context in which the second label is to be interpreted. See [RFC5331].

When LSR U uses these procedures to tell LSR D that a particular MP-LSP is carried in a particular multicast tunnel, U and D MUST take appropriate steps to make sure the packets U sends into this tunnel will be received by D 🚨. The exact steps depend on the tunnel type. As long as U is D's upstream LSR for any MP-LSP that has been assigned to this tunnel, D must remain joined to the tunnel.

Note that U MAY assign the same multicast tunnel to multiple different MP-LSPs. However, U MUST assign a distinct upstream-assigned label to each MP-LSP 🏷️. This is what lets the packets traveling through the tunnel get demultiplexed into the proper MP-LSPs.

Here's an example with some drama 🎭. If U has an MP-LSP <R1,X1> with downstream LSRs D1 and D2, and an MP-LSP <R2,X2> with downstream LSRs D2 and D3, U may assign both MP-LSPs to the same multicast tunnel. In that case, D3 will receive packets traveling on <R1,X1>. However, the upstream-assigned label carried by those packets won't be recognized by D3, so D3 will discard them. Similarly, D1 will discard the <R2,X2> packets 💀.

This document doesn't specify any rules for deciding whether to aggregate two or more MP-LSPs into a single multicast tunnel. Those rules are outside the scope of this document 🤐.

Except for the procedures explicitly detailed in this document, the procedures of [mLDP] and [LDP-UP] apply unchanged 🫶.

7. Security Considerations 🔐

This document raises no new security considerations beyond those discussed in [LDP], [LDP-UP], and [RFC5331]. No new drama on this one, bestie, the serious security stuff lives in those other documents 😤.

8. Acknowledgments 💌

The authors wish to thank Lizhong Jin and Lizhen Bin for their comments. Thank you, queens 👑.

9. Normative References 📚

[LDP]      Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
           "LDP Specification", RFC 5036, October 2007.

[LDP-CAP]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
           Le Roux, "LDP Capabilities", RFC 5561, July 2009.

[mLDP]     Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
           Thomas, "Label Distribution Protocol Extensions for
           Point-to-Multipoint and Multipoint-to-Multipoint Label
           Switched Paths", RFC 6388, November 2011.

[LDP-UP]   Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
           Assignment for LDP", RFC 6389, November 2011.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
           Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
           Encoding", RFC 3032, January 2001.

[RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
           Label Assignment and Context-Specific Label Space", RFC
           5331, August 2008.

Authors' Addresses 💖

Maria Napierala
AT&T Labs
200 Laurel Avenue
Middletown, NJ 07748
USA

EMail: mnapierala@att.com


Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA, 01719
USA

EMail: erosen@cisco.com


IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a Diegem 1831
Belgium

EMail: ice@cisco.com
📦 where this page comes from