Technical Summary
In traditional transport networks, circuits such as T1 lines are
typically provisioned on multiple switches. When an event that
causes disruption occurs on any link or node along the path of
such a transport circuit, Operations, Administration, and
Maintenance (OAM) indications are generated which may
suppress alarms and/or activate a backup circuit. These OAM
messages are called Fault Management (FM) messages.
The MPLS-TP requirements demand mechanisms equivalent
to traditional transport circuits. Therefore an FM capability is
needed in MPLS. This capability must meet the MPLS-TP
requirements set out in RFC 5654, and the MPLS-TP OAM
requirements in RFC 5860.
This document specifies OAM messages to indicate service
disruptive conditions for MPLS transport Network Label Switched
Paths. The notification mechanism employs a generic method for a
service disruptive condition to be communicated to a Maintenance
Entity Group End Point. This document defines an MPLS OAM
channel, along with messages to communicate various types of
service disruptive conditions.
These mechanisms are intended to be applicable to other
aspects of MPLS (beyond MPLS-TP), however, this is beyond
the scope of this document.
Working Group Summary
This document is a MPLS working group document, and part of the joint
IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations
and there is a solid support for the document.
There has been robust discussion about the technical solution and that
has resulted in plenty of revisions to the text, but all changes were
confirmed with the WG before the publication request was made. Changes
as a result of AD review were plentiful, but editorial in nature.
The IPR disclosure was notified to the mailing list and did not result in
any suggestions to change the content of the document.
Document Quality
The document has been carefuly reviewed in the MPLS working group and
the ITU-T. The last call was brought to the notice of SG15 in ITU-T who
reviewed the document. It has also passed a working group call to verify
that LC comments were correctly with minor comments.
Several vendors are implementing this document.
Personnel
Ross Callon (rcallon@juniper.net) is the Document Shepherd.
Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD
RFC Editor Note
Section 2.1
The primary purpose of the AIS message is to suppress alarms in the
layer network above the level at which the fault occurs. When the
Link Down Indication is set, the AIS message MAY be used to trigger
recovery mechanisms.
s/MAY/can/
---
Section 2.2
While the primary purpose
of the LKR message is to suppress alarms, similar to AIS with the LDI
(L-flag set), the receipt of an LKR message MAY be treated as the
equivalent of loss of continuity at the client layer.
s/MAY/can/
---
Section 8.1
Please remove the note from the end of this section before publication.
---
Section 8.4 para 1
s/"Private Use"/"Experimental Use"/
IANA Note
Please also note the Note in Section 8.1. IANA is requested to make the temporary allocation permanent.
Please see RFC Editor Note for Section 8.4