MPLS OAM alert label: Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions
The MPLS label that marks a packet as an operation and maintenance test packet
Ohta, H., "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions", RFC 3429, DOI 10.17487/RFC3429, November 2002, <https://www.rfc-editor.org/info/rfc3429>.
@misc{rfc3429,
series = {Request for Comments},
number = 3429,
howpublished = {RFC 3429},
publisher = {RFC Editor},
doi = {10.17487/RFC3429},
url = {https://www.rfc-editor.org/info/rfc3429},
author = {H. Ohta},
title = {{Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions}},
pagetotal = 6,
year = 2002,
month = nov,
} RFC text
Contents
Network Working Group H. Ohta
Request for Comments: 3429 NTT
Category: Informational November 2002
Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes the assignment of one of the reserved label
values defined in RFC 3032 (MPLS label stack encoding) to the
'Operation and Maintenance (OAM) Alert Label' that is used by user-
plane Multiprotocol Label Switching Architecture (MPLS) OAM functions
for identification of MPLS OAM packets.
1. Introduction
This document describes the assignment of one of the reserved label
values defined in RFC 3032 (MPLS label stack encoding [2]) to the
'OAM Alert Label' that is used by user-plane MPLS OAM functions for
identification of MPLS OAM packets as described in the ITU-T
Recommendation Y.1711 [1] (on MPLS OAM functions).
2. OAM functions
MPLS OAM (Operation and Maintenance) functions provide necessary
tools for network operators to operate and maintain the networks.
MPLS OAM functionality is required at the MPLS layer, and more
specifically at each MPLS level, independent of OAM functionality
provided by the lower layers (SONET/SDH, etc.). The objectives of
the OAM functions include the following:
- Defect and failure detection: Defect/failures affecting the
transport of user information are detected by continuous or
periodic checking. As a result, maintenance event information or
appropriate alarms will be produced.
- Reporting the defect/failure information: Defect information is
given to other management entities (e.g., Operation Support
System) in order to provide the appropriate indications to the
maintenance staff for maintaining the Quality of Service (QoS)
level offered to customers.
- Defect/failure localization: Determination by internal or external
test systems of a failed entity is performed if defect information
is insufficient.
- Performance monitoring: Performance (packet losses, transfer
delay, bit errors, etc.) of the user information transport is
measured in order to estimate the transport integrity.
3. OAM Packet Identification
The user-plane MPLS OAM mechanisms as described in the ITU-T
Recommendation Y.1711 [1] uses a special label called 'OAM Alert
Label' to differentiate OAM packets from the normal user packets.
One of the reserved label values defined in RFC 3032 (MPLS label
stack encoding [2]) is assigned to 'OAM Alert Label'. A value of 14
is used for this purpose.
4. MPLS OAM work in ITU-T SG13
ITU-T Study Group 13, Question 3/13 is progressing work 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 OAM mechanisms in Y.1711, under last call
as of Nov. 2002.
5. Considerations on penultimate hop popping (PHP)
In response to concerns raised during IETF meetings and in related
discussions, this section provides an explanation on how MPLS OAM
functions defined in ITU-T Recommendation Y.1711 [1] are applied to
MPLS networks where PHP is in effect.
5.1 Scope of ITU-T Recommendation Y.1711
The scope of ITU-T Recommendation Y.1711 includes application to both
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, and implements both MPLS
control-plane and data-plane, but is not able to perform 2 lookups at
line rate. So it asks the penultimate node to pop the top label
(rather than swapping it), using the MPLS reserved label 3 (implicit
null label) as per defined in RFC 3032 [2].
Case 2: The ultimate node has no MPLS label look up and processing
capability and does not recognize labeled packets. This node asks
for PHP, using the MPLS reserved label 3 (implicit null label) as
defined in RFC 3032 [2].
Currently, MPLS OAM functions defined in ITU-T Recommendation Y.1711
[1] can only be applied to Case 1. The next subsection describes the
node behavior in Case 1. Application for Case 2 needs further study.
Also, application to carrier supporting carrier scenarios is for
future study.
5.3 Node behavior when OAM functions are activated
Where the ultimate LSR is an MPLS LSR and PHP is in effect, the
penultimate LSR pops the top label and forwards the OAM packet (with
the OAM label and the OAM payload intact) to the ultimate LSR [5].
- If the ultimate LSR supports MPLS OAM, it understands that a
received packet with an OAM label on top is an OAM packet, since
the original top label has been removed by the penultimate LSR.
It also knows the ingress LSR that originated the MPLS OAM packet
from the TTSI (Trail Termination Source Identifier) value of the
received MPLS OAM packet. TTSI is a unique identifier for ingress
LSR that is contained in MPLS OAM packets (see ITU-T
Recommendation Y.1711 [1]).
- If the ultimate LSR does not support MPLS OAM, the OAM packet is
discarded as per section 3.18 of RFC 3031 [5].
6. IANA Considerations
The IANA has reserved the use of the MPLS label value of 14 as the
'OAM Alert Label'. See section 3 for additional information.
7. Security Considerations
This document does not raise any security issues that are not already
present in either the MPLS architecture or in the architecture of the
network layer protocol contained within the encapsulation.
OAM functions could enhance the security of MPLS networks. For
example, Connectivity Verification (CV) function defined in ITU-T
Recommendation Y.1711 [1] can detect mis-connections, and therefore
can prevent customers' traffic being exposed to other customers.
8. Acknowledgements
The author wishes to thank Shahram Davari with PMC-Sierra, Neil
Harrison with British Telecom, Monique Morrow, Thomas D. Nadeau, Hari
Rakotoranto and Chip Sharp with Cisco Systems, Khalid Ahmad and David
Allan with Nortel Networks, and Mina Azad with Azad-Mohtaj Consulting
for their valuable contributions and discussions.
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
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.
ISO Plain Language
On this page
§1What the Document Assigns
RFC 3429 describes the assignment of one of the reserved label values defined in RFC 3032, the MPLS label stack encoding, to the OAM Alert Label. The label is used by the user-plane Multiprotocol Label Switching operation and maintenance functions to identify MPLS OAM packets, in the way described by ITU-T Recommendation Y.1711 on MPLS OAM functions.
The document is short and factual. It explains what the MPLS OAM functions are for, records the assignment of the label value, notes the related work in ITU-T Study Group 13, and answers the questions that were raised about how the OAM packets behave when penultimate hop popping is in effect.
This document gives a reserved MPLS label a name and a value. Routers use that label to recognise a network test packet so they do not treat it as customer traffic.
§2What the OAM Functions Do
MPLS OAM functions give network operators the tools to operate and maintain their networks. The functionality is required at the MPLS layer, and more specifically at each MPLS level, independent of the OAM functionality provided by lower layers such as SONET/SDH. The objectives are four.
- Defect and failure detection. Defects and failures that affect the transport of user information are detected by continuous or periodic checking, and maintenance event information or appropriate alarms are produced as a result.
- Reporting the defect and failure information. The information is given to other management entities, such as an Operation Support System, so that maintenance staff get the indications they need to maintain the Quality of Service level offered to customers.
- Defect and failure localisation. Determination by internal or external test systems of a failed entity is performed when the defect information is not sufficient.
- Performance monitoring. The performance of the user information transport, including packet losses, transfer delay and bit errors, is measured so that the integrity of the transport can be estimated.
The OAM functions are the network's own checks: they spot faults, report them to the operator, find which piece of equipment failed, and measure how well traffic is being carried.
§3The OAM Alert Label
The user-plane MPLS OAM mechanisms described in ITU-T Recommendation Y.1711 use a special label, the OAM Alert Label, to tell OAM packets apart from normal user packets. One of the reserved label values defined in the MPLS label stack encoding is assigned to it, and the value used is 14.
The IANA has reserved the use of the MPLS label value 14 as the OAM Alert Label. The document also lists the related ITU-T Study Group 13 Question 3/13 documents: Recommendation Y.1710 on the requirements for OAM functionality for MPLS networks, Corrigendum 1 to Y.1710, Recommendation Y.1711 on OAM mechanisms for MPLS networks, and Draft Recommendation Y.1720 on protection switching for MPLS networks, which relies on the mechanisms in Y.1711 and was under last call as of November 2002.
The label value 14 is the marker. A router that pops the top label and sees 14 underneath knows the packet is an OAM test packet, not customer traffic.
- 14OAM Alert Label — The reserved label value used to identify user-plane MPLS OAM packets.
- 3Implicit null label — The reserved label a node uses to ask the penultimate node to pop the top label.
§5.3Node Behaviour with Penultimate Hop Popping
Penultimate hop popping, or PHP, is where the node before the destination removes the top label from the label stack instead of swapping it. There are two cases. In the first, the ultimate node is an MPLS Label Switching Router that implements both the control plane and the data plane but cannot perform two lookups at line rate, so it asks the penultimate node to pop the top label, using the MPLS reserved label 3, the implicit null label. In the second, the ultimate node has no MPLS label look-up or processing capability at all and does not recognise labelled packets, so it also asks for PHP using the implicit null label.
At present the MPLS OAM functions defined in Y.1711 can only be applied to the first case. Application to the second case needs further study, and application to carrier supporting carrier scenarios is for future study.
Where the ultimate node is an MPLS LSR and PHP is in effect, the penultimate node pops the top label and forwards the OAM packet, with the OAM label and the OAM payload intact, to the ultimate node. If that node supports MPLS OAM, it understands that the packet it received with an OAM label on top is an OAM packet, since the original top label was removed by the penultimate node. It also knows which node started the OAM packet, from the TTSI, the Trail Termination Source Identifier, value carried in the packet. If the ultimate node does not support MPLS OAM, the OAM packet is discarded, as specified in section 3.18 of RFC 3031.
Sometimes the router before the destination removes the top label instead of forwarding it. The OAM packet then arrives with the alert label on top, so the destination router knows it is a test packet and knows which node sent it.
§7Security Considerations
The document does not raise any security issues that are not already present in either the MPLS architecture or in the architecture of the network layer protocol contained within the encapsulation.
It adds that OAM functions could enhance the security of MPLS networks. The Connectivity Verification function defined in ITU-T Recommendation Y.1711 can detect mis-connections, and therefore can prevent customers' traffic being exposed to other customers.
The label assignment adds no new security risk. The document notes one benefit: a connectivity check can spot a wrongly connected path and stop one customer's traffic reaching another customer.