RFC 8339

Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms

📅 published March 2018, from ietf

RFC 8339: Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms ✨

Internet Engineering Task Force (IETF) 🌸 Request for Comments: 8339 💖 Category: Standards Track 🎀 ISSN: 2070-1721 Date: March 2018 📅

Okay bestie, this one was written by P. Jain, Ed. (Cisco Systems, Inc.), S. Boutros (VMWare, Inc.), and S. Aldrin (Google Inc.) 🫶. It's on the Standards Track, so it's an official Internet standard, not just a suggestion 💅. It doesn't have any Obsoletes or Updates lines in the header, so it isn't replacing or changing another RFC 🦋.

Abstract ✨

LSP Ping is a seriously popular Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks 💜. This document is all about using LSP Ping to check that Point-to-Multipoint (P2MP) Pseudowires (PWs) are actually connected 🧚.

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 give feedback on it can be found at https://www.rfc-editor.org/info/rfc8339 🔗.

Copyright (c) 2018 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 (https://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 they are provided without warranty as described in the Simplified BSD License 😭.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Specification of Requirements . . . . . . . . . . . . . .   3
  2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   4
3.  Identifying a P2MP PW . . . . . . . . . . . . . . . . . . . .   5
  3.1.  P2MP Pseudowire Sub-TLV . . . . . . . . . . . . . . . . .   5
4.  Encapsulation of OAM Ping Packets . . . . . . . . . . . . . .   6
5.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .   6
6.  Controlling Echo Responses  . . . . . . . . . . . . . . . . .   7
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1. Introduction 🦋

A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential attributes of a unidirectional P2MP Telecommunications service, like P2MP ATM over a Public Switched Network (PSN) 🌸. The requirements for P2MP PWs are described in [RFC7338] ✨. P2MP PWs are carried over a P2MP MPLS LSP 🚀. The procedures for P2MP PW signaling using BGP are described in [RFC7117], and LDP for single segment P2MP PWs is described in [RFC8338] 💜.

Lots of P2MP PWs can share the same P2MP MPLS LSP, and this setup is called an "Aggregate P2MP Tree" 🫧. An Aggregate P2MP Tree needs an upstream-assigned label so that, on the Leaf PE (L-PE), the traffic can be linked to a Virtual Private Network (VPN) or a Virtual Private LAN Service (VPLS) instance 👑. When a P2MP MPLS LSP only carries one VPN or VPLS service instance, the setup is called an "Inclusive P2MP Tree" 🎀. For an Inclusive P2MP Tree, the P2MP MPLS LSP label itself can uniquely identify the VPN or VPLS service being carried over the P2MP MPLS LSP 🧚. The P2MP MPLS LSP can also be used in the Selective P2MP Tree setup to carry multicast traffic 🌈. In a Selective P2MP Tree setup, traffic to each multicast group in a VPN or VPLS instance is carried by a separate unique P2MP LSP 💅. In an Aggregate Selective P2MP Tree setup, traffic to a set of multicast groups from different VPN or VPLS instances is carried over the same shared P2MP LSP 🍓.

The P2MP MPLS LSPs are set up using either P2MP RSVP-TE [RFC4875] or Multipoint LDP (mDLP) [RFC6388] 🔥. Mechanisms for fault detection and isolation for data-plane failures for P2MP MPLS LSPs are specified in [RFC6425] 🙈. This document describes a mechanism to detect data-plane failures for P2MP PWs carried over P2MP MPLS LSPs 💖.

This document defines a new P2MP Pseudowire sub-TLV for the Target Forwarding Equivalence Class (FEC) Stack for P2MP PWs ✨. The P2MP Pseudowire sub-TLV gets added in the Target FEC Stack TLV by the originator of the echo request at the Root PE (R-PE) 🫶. Its job is to tell the receiver at the Leaf PE (L-PE) which P2MP PW is being tested 🦋.

Support for multi-segment PWs is out of scope of this document 🙅‍♀️.

2. Terminology 📚

2.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

2.2. Abbreviations 🔤

ACH:        Associated Channel Header

AGI:        Attachment Group Identifier

ATM:        Asynchronous Transfer Mode

CE:         Customer Edge

FEC:        Forwarding Equivalence Class

GAL:        Generic Associated Channel Label

LDP:        Label Distribution Protocol

L-PE:       Leaf PE (one of many destinations of the P2MP MPLS LSP,
            i.e., egress PE)

LSP:        Label Switched Path

LSR:        Label Switching Router

mLDP:       Multipoint LDP

MPLS-OAM:   MPLS Operations, Administration, and Maintenance

P2MP:       Point-to-Multipoint

P2MP-PW:    Point-to-Multipoint Pseudowire

PE:         Provider Edge

PSN:        Public Switched Network

PW:         Pseudowire

R-PE:       Root PE (ingress PE, PE initiating P2MP PW setup)

RSVP:       Resource Reservation Protocol

TE:         Traffic Engineering

TLV:        Type, Length, Value

VPLS:       Virtual Private LAN Service

3. Identifying a P2MP PW 🔍

This document introduces a new LSP Ping Target FEC Stack sub-TLV, the P2MP Pseudowire sub-TLV 🌸. Its job is to identify the P2MP PW under test at the P2MP Leaf PE (L-PE) 🧚.

3.1. P2MP Pseudowire Sub-TLV 💖

The P2MP Pseudowire sub-TLV has the format shown in Figure 1 ✨. This TLV is included in the echo request sent over the P2MP PW by the originator of the request 🫶.

The Attachment Group Identifier (AGI), as described in Section 3.4.2 of [RFC4446], in the P2MP Pseudowire sub-TLV identifies the VPLS instance 👑. The Originating Router's IP address is the IPv4 or IPv6 address of the P2MP PW root 🌈. The address family of the IP address is determined by the IP Addr Len field 🦋.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | AGI Type    |   AGI Length  |                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
    ~                          AGI Value                            ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IP Addr Len |                                                 |
    +-+-+-+-+-+-+-+                                                 |
    ~               Originating Routers IP Addr                     ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: P2MP Pseudowire Sub-TLV Format

For Inclusive and Selective P2MP Trees, the echo request is sent using the P2MP MPLS LSP label 💅.

For Aggregate Inclusive and Aggregate Selective P2MP Trees, the echo request is sent using a label stack of [P2MP MPLS LSP label, upstream assigned P2MP PW label] 🍓. The P2MP MPLS LSP label is the outer label, and the upstream assigned P2MP PW label is the inner label 🔥.

4. Encapsulation of OAM Ping Packets 🎁

The LSP Ping echo request packet is encapsulated with the MPLS label stack as described in the previous sections, followed by one of two encapsulation options 💜:

  • GAL [RFC6426] followed by an IPv4 (0x0021) or IPv6 (0x0057) type Associated Channel Header (ACH) [RFC4385]
  • PW ACH [RFC4385]

To make sure things work together nicely, implementations of this document MUST support both encapsulations 🫶💖.

Part 2 is coming next, bestie, so stay tuned 🧚✨

5. Operations 💅

okay so this is where we actually watch LSP Ping work over a P2MP PW 🦋 Figure 2 shows a P2MP PW called PW1 set up from Root PE R-PE1 to the Leaf PEs (L-PE2, L-PE3, and L-PE4). The transport LSP for PW1 can be either an mLDP P2MP MPLS LSP or a P2MP TE tunnel 🌸

                 |<--------------P2MP PW---------------->|
          Native |                                       |  Native
         Service |     |<--PSN1->|      |<--PSN2->|      |  Service
          (AC)   V     V         V      V         V      V   (AC)
            |    +-----+         +------+         +------+    |
            |    |     |         |   P1 |=========|L-PE2 |AC3 |    +---+
            |    |     |         |   .......PW1.........>|-------->|CE3|
            |    |R-PE1|=========|   .  |=========|      |    |    +---+
            |    |  .......PW1........  |         +------+    |
            |    |  .  |=========|   .  |         +------+    |
            |    |  .  |         |   .  |=========|L-PE3 |AC4 |    +---+
    +---+   |AC1 |  .  |         |   .......PW1.........>|-------->|CE4|
    |CE1|------->|...  |         |      |=========|      |    |    +---+
    +---+   |    |  .  |         +------+         +------+    |
            |    |  .  |         +------+         +------+    |
            |    |  .  |=========|   P2 |=========|L-PE4 |AC5 |    +---+
            |    |  .......PW1..............PW1.........>|-------->|CE5|
            |    |     |=========|      |=========|      |    |    +---+
            |    +-----+         +------+         +------+    |

Figure 2: P2MP PW

When an operator wants to run a connectivity check on P2MP PW1, they kick off an LSP Ping echo request from Root PE R-PE1. The Target FEC Stack TLV in that echo request packet carries the P2MP Pseudowire sub-TLV ✨ For an Inclusive P2MP Tree arrangement, the echo request rides the P2MP MPLS LSP with one of these two encapsulation options:

  • {P2MP LSP label, GAL} MPLS label stack and IPv4 or IPv6 ACH.
  • {P2MP LSP label} MPLS label stack and PW ACH.

For an Aggregate Inclusive Tree arrangement, the echo request rides the P2MP MPLS LSP with one of these two encapsulation options:

  • {P2MP LSP label, P2MP PW upstream assigned label, GAL} MPLS label stack and IPv4 or IPv6 ACH.
  • {P2MP LSP label, P2MP PW upstream assigned label} MPLS label stack and PW ACH.

The intermediate P routers do the MPLS label swap and replication based on the incoming MPLS LSP label 🔥 Once the echo request packet reaches the L-PEs, they use the GAL and the IPv4/IPv6 ACH Channel header or the PW ACH (whichever one applies) to recognise that the packet is an OAM Packet 👀 The L-PEs then process the packet and check the P2MP Pseudowire sub-TLV present in the Target FEC Stack TLV, as described in Section 4.4 in [RFC8029], and respond according to the processing rules in that document 💖

6. Controlling Echo Responses

the procedures in [RFC6425] for stopping Echo Responses from congesting the network (the Echo Jitter TLV in Section 3.3 of [RFC6425]) and for limiting the echo reply to a single L-PE (the Node Address P2MP Responder Identifier TLV in Section 3.2 of [RFC6425]) should be applied to P2MP PW LSP Ping 🎀

7. Security Considerations 🔒

The proposal introduced in this document does not introduce any new security considerations beyond those that already apply to [RFC6425]. Bestie, this is a big deal: nothing new to worry about here beyond what [RFC6425] already covers 😭

8. IANA Considerations 🧚

This document defines a new sub-TLV type included in the Target FEC Stack TLV (TLV Type 1) [RFC8029] in LSP Ping ✨

IANA has assigned the following sub-TLV type value from the "Sub-TLVs for TLV Types 1, 16, and 21" sub-registry within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry:

   37 P2MP Pseudowire

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

The authors would like to thank Shaleen Saxena, Greg Mirsky, Andrew G. Malis, and Danny Prairie for their valuable input and comments 💜

Authors' Addresses 🎀

   Parag Jain (editor)
   Cisco Systems, Inc.
   2000 Innovation Drive
   Kanata, ON  K2K-3E8
   Canada

   Email: paragj@cisco.com


   Sami Boutros
   VMWare, Inc.
   United States of America

   Email: sboutros@vmware.com


   Sam Aldrin
   Google Inc.
   United States of America

   Email: aldrin.ietf@gmail.com
📦 where this page comes from