Technical Summary
This document provides an overview of the OAM toolset for MPLS based Transport
Networks. The toolset consists of a comprehensive set of fault management and
performance monitoring capabilities (operating in the data-plane) which are
appropriate for transport networks as required in RFC 5860 and support the
network and services at different nested levels. This overview includes a brief
recap of MPLS-TP OAM requirements and functions, and of generic mechanisms
created in the MPLS data plane to allow the OAM packets run in-band and share
their fate with data packets. The protocol definitions for each of the MPLS-TP
OAM tools are defined in separate documents (RFCs or Working Group drafts) which
are referenced by this document.
Working Group Summary
This informational document has passed working group last call with clear
consensus in favor of publication.
Document Quality
This is an informational document which is not subject to be implemented. It
provides description of and pointers to other documents, for which there are
multiple current implementations and/or implementations in progress.
Personnel
Ross Callon (rcallon@juniper.net) is the Document Shepherd
Adrian Farrel (adrian@olddog.co.uk) is the Responsible AD
RFC Editor Note
Section 1.1
OLD
o The OAM toolset developed for MPLS based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as
documented in [RFC 5860].
NEW
o The OAM toolset developed for MPLS based transport networks needs
to be fully inter-operable with existing MPLS OAM tools as
documented in section 2.1.5. of [RFC 5860].
END
---
Section 1.1
OLD
However, compatibility with the existing tools has been maintained.
NEW
However, compatibility with the existing MPLS tools has been maintained.
END
---
Section 4 Table 2
OLD
+------------------------+---------------------------------+--------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+--------+
| Connectivity | LSP Ping | [RFC |
| Verification | | 6426] |
+------------------------+---------------------------------+--------+
| Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC |
| and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] |
+------------------------+---------------------------------+--------+
+------------------------+---------------------------------+--------+
| Lock Instruct(LI) | Flag in AIS message | [RFC |
| | | 6427] |
+------------------------+---------------------------------+--------+
NEW
+------------------------+---------------------------------+--------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+--------+
| Connectivity | LSP Ping | [RFC |
| Verification | | 6426] |
+------------------------+---------------------------------+--------+
| Lock Instruct (LI) | (1) G-ACh based Loopback, | [RFC |
| | (2) Lock Instruct (LI) | 6435] |
+------------------------+---------------------------------+--------+
| Lock Report (LKR) | Flag in AIS message | [RFC |
| | | 6427] |
+------------------------+---------------------------------+--------+
END
---
Section 5.2, third paragraph
OLD
The Lock operation instruction is carried in an MPLS Loopback request
message sent from a MEP to a trail-end MEP of the LSP to request that
the LSP be taken out of service. In response, the Lock operation
reply is carried in a Loopback response message sent from the trail-
end MEP back to the originating MEP to report the result.
NEW
[RFC6435] defines a mechanism where a lock instruction is sent by a
management application to both ends of a point-to-point LSP requesting
them to take the LSP out-of-service. When an endpoint gets the
management request, it locks the LSP and sends a Lock Instruct message
to the other end of the LSP. The Lock Instruct message is carried in a
Generic ACH message and is sent periodically. The time between
successive messages is no longer than the value set in the Refresh
Timer field of the Lock Instruct message. An LSP end point keeps the
LSP locked while it is either receiving the periodic Lock Instruct
messages or has an in-force lock instruction from the management
application.
Note that since the management application will receive a management
plane response from both ends of the LSP confirming that the LSP has
been locked, there is no requirement for the Lock Instruct message to
have a response. Therefore, [RFC6435] does not define a Lock Instruct
response message.
END
---
Section 7,paragraph 3
OLD
OAM in general is always an area where the security risk is high,
e.g. confidential information may be intercepted for attackers to
again access to the networks, therefore authentication, authorization,
and encryption need to be enforced for prevent security breach.
NEW
OAM in general is always an area where the security risk is high. For
example, confidential information may be intercepted by attackers to
gain access to networks, therefore authentication, authorization, and
encryption need to be enforced to prevent security breaches.
END
---
Section 7, paragraph 4:
OLD
In addition to implement security protocol, tools, and mechanisms,
following strict operation security procedures is very important,
especially MPSL-TP static provisioning processes involve operator
direct interactions with NMS and devices, its critical to prevent
human errors and malicious attacks.
NEW
It is also important to strictly follow operational security
procedures. For example, in the case of MPLS-TP static provisioning,
the operator interacts directly with the NMS and devices, and it is
critical to prevent human errors as well as malicious attacks.
END
---
Section 7, final paragraph
OLD
Since MPLS-TP OAM uses G-ACh, the security risks and mitigation
described in [RFC 5085] apply here. In short, the G-ACh could be
intercepted, or false G-ACh packets could be inserted. DoS attack
could happen by flooding G-ACh messages to peer devices. To mitigate
this type of attacks, throttling mechanisms can be used. For more
details, please see [RFC 5085].
NEW
Since MPLS-TP OAM uses G-ACh, the security risks and mitigations
described in [RFC 5085] also apply here. In short, messages on the
G-ACh could be intercepted, or false G-ACh packets could be inserted.
Additionally DoS attacks can be mounted by flooding G-ACh messages to
peer devices. To mitigate this type of attack, throttling mechanisms
or rate limits can be used. For more details, please see [RFC 5085].
END
---
Section 8., paragraph 3:
s/doecument/document/
---
Section 9.2
OLD
ID draft-ietf-mpls-tp-security-framework-02, May 2011.
NEW
draft-ietf-mpls-tp-security-framework-03, October 2011.
END
---
Spaces in reference tags.Please feel free to change any and all reference
tags so that they do not contain space characters.