RFC 3429

RFC 3429 📜💖 Assignment of the 'OAM Alert Label' for MPLS OAM Functions

Okay bestie, this one is a tiny but iconic little doc 🦋 It's RFC 3429, titled Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions. The author is H. Ohta from NTT, and it was published in the Network Working Group in November 2002. Its category is Informational, so it's sharing info, not setting a standard ✨ The original title block doesn't list anything it obsoletes or updates, so there's no drama there 💅

---

Status of this Memo 🌸

This memo gives info to the Internet community. It is not a standard of any kind, and anyone can share it freely, no limits 🫶

Copyright Notice 💜

Copyright © The Internet Society (2002). All rights reserved. ✨

Abstract 🔥

This doc is all about giving one of the reserved label values from RFC 3032 (MPLS label stack encoding) to the 'Operation and Maintenance (OAM) Alert Label'. That label is used by user-plane MPLS OAM functions to spot MPLS OAM packets, so it's a big deal 💅

1. Introduction 🧚

Same tea as the abstract, just a little more detail. The doc assigns one of the reserved label values from RFC 3032 (MPLS label stack encoding [2]) to the 'OAM Alert Label'. User-plane MPLS OAM uses that label to recognize OAM packets, as described in ITU-T Recommendation Y.1711 [1] (on MPLS OAM functions). It's giving organized 🎀

2. OAM functions 🌈

MPLS OAM (Operation and Maintenance) functions give network operators the tools they need to run and maintain their networks. MPLS OAM functionality is required at the MPLS layer, and more specifically at each MPLS level, and it works independently of any OAM functionality the lower layers (SONET/SDH, etc.) provide. The goals of OAM functions include the following:

• Defect and failure detection 🔍: Defects and failures that affect the transport of user information get caught through continuous or periodic checking. The result is maintenance event information or appropriate alarms.
• Reporting the defect/failure information 📣: Defect info goes to other management entities (for example, an Operation Support System) so maintenance staff get the right indications for keeping the Quality of Service (QoS) level customers are paying for.
• Defect/failure localization 🎯: If the defect info isn't enough, internal or external test systems work out which failed entity is responsible.
• Performance monitoring 📊: The performance of user information transport (packet losses, transfer delay, bit errors, etc.) gets measured so people can estimate how much integrity the transport has.

3. OAM Packet Identification 🦋

The user-plane MPLS OAM mechanisms in ITU-T Recommendation Y.1711 [1] use a special label called the 'OAM Alert Label' to tell OAM packets apart from normal user packets. One of the reserved label values from RFC 3032 (MPLS label stack encoding [2]) gets assigned to the 'OAM Alert Label'. The value used for this is 14 ✨

4. MPLS OAM work in ITU-T SG13 🌸

ITU-T Study Group 13, Question 3/13, is working on user-plane MPLS OAM and has produced the following documents:

• (1) Recommendation Y.1710 (Requirements for OAM functionality for MPLS networks) [3]
• (2) Corrigendum 1 to Recommendation Y.1710 [4]
• (3) Recommendation Y.1711 (OAM mechanisms for MPLS networks) [1]
• (4) Draft Recommendation Y.1720 (Protection switching for MPLS networks) [6] relies on the OAM mechanisms in Y.1711, and it was under last call as of Nov. 2002.

5. Considerations on penultimate hop popping (PHP) 🔥

People raised concerns at IETF meetings and in related discussions, so this section explains how the MPLS OAM functions in ITU-T Recommendation Y.1711 [1] apply to MPLS networks where PHP is in effect. Let's get into it 👑

5.1 Scope of ITU-T Recommendation Y.1711 💅

The scope of Y.1711 covers both the non-PHP and PHP cases, as quoted below [1]:

"1 Scope
This Recommendation provides mechanisms for user-plane OAM (Operation
and Maintenance) functionality in MPLS networks according to the
requirements and principles given in Recommendation Y.1710.  OAM
functions specified in this Recommendation can be applied to both
non-PHP and PHP cases unless otherwise stated.  The current version
of this recommendation is designed primarily to support
point-to-point and multipoint-to-point explicit routed LSPs
(ER-LSPs)."

5.2 Applicability of MPLS OAM to PHP 🧚

There are two cases where PHP is used. ✨

Case 1: The ultimate node is an MPLS LSR that implements both the MPLS control-plane and data-plane, but it can't do 2 lookups at line rate. So it asks the penultimate node to pop the top label instead of swapping it, using the MPLS reserved label 3 (implicit null label) as defined in RFC 3032 [2].

Case 2: The ultimate node has no MPLS label lookup or processing capability and doesn't recognize labeled packets. It asks for PHP using the MPLS reserved label 3 (implicit null label) as defined in RFC 3032 [2].

Right now, the MPLS OAM functions in ITU-T Recommendation Y.1711 [1] can only be applied to Case 1. The next subsection covers how nodes behave in Case 1. Application to Case 2 needs further study, and application to carrier supporting carrier scenarios is for future study too 🫶

5.3 Node behavior when OAM functions are activated 🌈

When the ultimate LSR is an MPLS LSR and PHP is in effect, the penultimate LSR pops the top label and forwards the OAM packet to the ultimate LSR with the OAM label and the OAM payload intact [5].

• If the ultimate LSR supports MPLS OAM, it knows a received packet with an OAM label on top is an OAM packet, because the penultimate LSR already removed the original top label. It also works out which ingress LSR originated the MPLS OAM packet from the TTSI (Trail Termination Source Identifier) value in the packet. The TTSI is a unique identifier for the ingress LSR, carried in MPLS OAM packets (see ITU-T Recommendation Y.1711 [1]) 🔥
• If the ultimate LSR doesn't support MPLS OAM, the OAM packet gets discarded as per section 3.18 of RFC 3031 [5] 💀

6. IANA Considerations 🎀

IANA has reserved the MPLS label value 14 as the 'OAM Alert Label'. See section 3 for more info 🌸

7. Security Considerations 🔐

This document doesn't raise any security issues that aren't already present in either the MPLS architecture or the architecture of the network layer protocol carried inside the encapsulation. ⚠️

OAM functions could actually make MPLS networks more secure, which is wild. For example, the Connectivity Verification (CV) function defined in ITU-T Recommendation Y.1711 [1] can detect mis-connections, and that means it can stop customers' traffic from being exposed to other customers. Please take this one seriously, it's a big deal 😭

8. Acknowledgements 🫶

The author thanks Shahram Davari (PMC-Sierra), Neil Harrison (British Telecom), Monique Morrow, Thomas D. Nadeau, Hari Rakotoranto and Chip Sharp (Cisco Systems), Khalid Ahmad and David Allan (Nortel Networks), and Mina Azad (Azad-Mohtaj Consulting) for their valuable contributions and discussions. Thank you, besties 💖

9. Normative References 📚

• [1] ITU-T Recommendation Y.1711, "OAM mechanism for MPLS networks", November 2002.
• [2] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinaccia, D., Li, T. and A. Conta, "MPLS label stack encoding", RFC 3032, January 2001.
• [3] ITU-T recommendation Y.1710, "Requirements for OAM functionality for MPLS networks" July 2001.
• [4] ITU-T Corrigendum 1 to Recommendation Y.1710, November 2002.
• [5] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.

10. Informative Reference 🧚

• [6] ITU-T Draft Recommendation Y.1720, "Protection switching for MPLS networks", under last call as of November 2002.

11. Author's Address 💌

Hiroshi OHTA
NTT
3-9-11 Midori-Cho, Musashino-Shi
Tokyo 180-8585 Japan

Phone: +81 422 59 3617
Fax:   +81 422 59 3787
EMail: ohta.hiroshi@lab.ntt.co.jp

12. Full Copyright Statement ⚖️

Here's the legal stuff, copied word for word so it stays exact 🙈

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. Periodt ✨