Network Working Group A. D'Alessandro
Internet-Draft Telecom Italia
Intended status: Standards Track L. Andersson
Expires: June 4, 2016 Huawei Technologies
M. Paul
Deutsche Telekom
S. Ueno
NTT Communications
K. Arai
Y. Koike
NTT
December 2, 2015
Enhanced path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-08.txt
Abstract
The MPLS transport profile (MPLS-TP) has been standardized to enable
carrier-grade packet transport and to complement converged packet
network deployments. The most attractive features of MPLS-TP are the
OAM functions. These functions enable maintenance tools that may be
exploited by network operators and service providers for fault
location, survivability, performance monitoring, in-service and out-
of-service measurements.
One of the most important mechanisms that is common for transport
network operation is fault localisation. A segment monitoring
function of a transport path is effective in terms of extension of
the maintenance work and indispensable, particularly when the OAM
function is activated only between end points. However, the current
approach defined for MPLS-TP of segment monitoring has some
drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provide monitoring of a
segment of a set of transport paths (LSPs or MS-PWs). Based on the
identified problems, this document provides considerations for the
specification of new requirements to consider a new improved
mechanism for hitless transport path segment monitoring to be named
Enhanced Path Segment Monitoring (EPSM).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
D'Alessandro, et al. Expires June 4, 2016 [Page 1]
Internet-Draft Enhanced path segment monitoring December 2015
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 4, 2016.
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as 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 are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network objectives for segment monitoring . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
5. OAM functions supported in segment monitoring . . . . . . . . 8
6. Requirements for enhanced segment monitoring . . . . . . . . 9
6.1. Non-intrusive segment monitoring . . . . . . . . . . . . 9
6.2. Single and multiple level monitoring . . . . . . . . . . 9
6.3. EPSM and end-to-end proactive monitoring independence . . 10
6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 11
6.5. Fault while EPSM is operational . . . . . . . . . . . . . 12
6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
D'Alessandro, et al. Expires June 4, 2016 [Page 2]
Internet-Draft Enhanced path segment monitoring December 2015
1. Introduction
A packet transport network enables carriers and service providers to
use network resources efficiently. It reduces operational complexity
and provides carrier-grade network operation. Appropriate
maintenance functions that support fault location, survivability,
pro-active performance monitoring, pre-service and in-service
measurements, are essential to ensure the quality of service and the
reliability of a network. They are essential in transport networks
and have evolved along with PDH, ATM, SDH and OTN.
Similar to legacy technologies, MPLS-TP does also not scale when an
arbitrary number of OAM functions is enabled.
According to the MPLS-TP OAM requirements RFC 5860 [RFC5860],
mechanisms MUST be available for alerting a service provider of a
fault or defect that affects their services. In addition, to ensure
that faults or service degradation can be localized, operators need a
function to diagnose the detected problem. Using end-to-end
monitoring for this purpose is insufficient. In fact by using end-
to-end OAM monitoring, an operator will not be able to localize a
fault or service degradation accurately.
Thus, a dedicated segment monitoring function that can focus on a
specific segment of a transport path and can provide a detailed
analysis is indispensable to promptly and accurately localize the
fault.
For MPLS-TP, a path segment monitoring function has been defined to
perform this task. However, as noted in the MPLS-TP OAM Framework
RFC 6371 [RFC6371], the current method for segment monitoring of a
transport path has implications that hinder the usage in an operator
network.
This document elaborates on the problem statement for the path
segment monitoring function and proposes to consider a new improved
method for segment monitoring, following up the description in RFC
6371 [RFC6371]. This document also provides additional detailed
requirements for a new temporary and hitless segment monitoring
function which is not covered in RFC 6371 [RFC6371].
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
D'Alessandro, et al. Expires June 4, 2016 [Page 3]
Internet-Draft Enhanced path segment monitoring December 2015
2.1. Terminology
ATM - Asynchronous Transfer Mode
EPSM - Enhanced Path Segment Monitoring
LSP - Label Switched Path
LSR - Label Switching Router
ME - Maintenance Entity
MEG - Maintenance Entity Group
MEP - Maintenance Entity Group End Point
MIP - Maintenance Entity Group Intermediate Point
OTN - Optical Transport Network
PDH - Plesiochronous Digital Hierarchy
PST - Path Segment Tunnel
TCM - Tandem connection monitoring
SDH - Synchronous Digital Hierarchy
SPME - Sub-path Maintenance Element
2.2. Definitions
None.
3. Network objectives for segment monitoring
There are two network objectives for MPLS-TP segment monitoring
described in section 3.8 of RFC 6371 [RFC6371]:
1. The monitoring and maintenance of current transport paths has to
be conducted in-service without traffic disruption.
2. Segment monitoring must not modify the forwarding of the segment
portion of the transport path.
D'Alessandro, et al. Expires June 4, 2016 [Page 4]
Internet-Draft Enhanced path segment monitoring December 2015
4. Problem Statement
The Sub-Path Maintenance Element (SPME) function is defined in RFC
5921 [RFC5921]. It is used to monitor, protect, and/or manage
segments of transport paths, such as LSPs in MPLS-TP networks. The
SPME is defined between the edges of the segment of a transport path
that needs to be monitored, protected, or managed. This SPME is
created by stacking the shim header (MPLS header) according to RFC
3031 [RFC3031] and is defined as the segment where the header is
stacked. OAM messages can be initiated at the edge of the SPME and
sent to the peer edge of the SPME or to a MIP along the SPME by
setting the TTL value of the label stack entry (LSE) and interface
identifier value at the corresponding hierarchical LSP level in case
of a per-node model.
This method has the following drawbacks that impact the operation
costs:
(P-1) It lowers the bandwidth efficiency.
(P-2) It increases network management complexity, because a new
sublayer and new MEPs and MIPs have to be configured for the SPME.
Problem (P-1) is caused by the shim headers stacking that increases
the overhead.
Problem (P-2) is related to an identifier management issue. In the
case of label stacking the identification of each sub-layer is
required for segment monitoring in a MPLS-TP network. When SPME is
applied for on-demand OAM functions in MPLS-TP networks in a similar
manner as Tandem Connection Monitoring (TCM) in the Optical Transport
Networks (OTN) and Ethernet transport networks, a rule for
operationally differentiating those SPME/TCMs will be required; at
least within an administrative domain. This forces operators to
create an additional permanent layer identification policy that will
only be used for temporary path segment monitoring. Additionally,
from the perspective of operation, increasing the number of managed
addresses and managed layers is not desirable in view of keeping the
transport networks as simple as possible. Reducing the number of
managed identifiers and managed sub-layers should be the fundamental
objective in designing the architecture.
The analogy for SPME in legacy transport networks is TCM, which is
on-demand and does not affect the transport path.
Also, using the currently defined methods, temporary setting of SPMEs
causes the following problems due to additional label stacking:
D'Alessandro, et al. Expires June 4, 2016 [Page 5]
Internet-Draft Enhanced path segment monitoring December 2015
(P-3) The original condition of the transport path is affected by
changing the length of MPLS frames and changing the value of
exposed label.
(P-4) The client traffic over a transport path is disrupted when
the SPME is configured on-demand.
Problem (P-3) impacts network objective (2) in Section 3. The
monitoring function should monitor the status without changing any
conditions of the targeted, to be monitored, segment or transport
path. Changing the settings of the original shim header should not
be allowed because this change corresponds to creating a new segment
of the original transport path. And this differs from the original
data plane conditions. When the conditions of the transport path
change, the measured values or observed data will also change and
this may make the monitoring meaningless because the result of the
measurement would no longer reflect the performance of the connection
where the original fault or degradation occurred.
Figure 1 shows an example of SPME settings. In the figure, "X" is
the label value of the original transport path expected at the tail-
end of node D. "210" and "220" are label values allocated for SPME.
The label values of the original path are modified as well as the
values of the stacked labels. As shown in Figure 1, SPME changes
both the length of MPLS frames and the label value(s). This means
that it is no longer monitoring the original transport path but it is
monitoring a different path. In particular, performance monitoring
measurements (e.g. Delay Measurement and Packet Loss Measurement)
are sensitive to these changes.
D'Alessandro, et al. Expires June 4, 2016 [Page 6]
Internet-Draft Enhanced path segment monitoring December 2015
(Before SPME settings)
--- --- --- --- ---
| | | | | | | | | |
| | | | | | | | | |
--- --- --- --- ---
A--100--B--110--C--120--D--130--E <= transport path
MEP MEP
(After SPME settings)
--- --- --- --- ---
| | | | | | | | | |
| | | | | | | | | |
--- --- --- --- ---
A--100--B-----------X---D--130--E <= transport path
MEP \ / MEP
--210--C--220-- <= SPME
MEP' MEP'
Figure 1: An Example of a SPME settings
Problem (P-4) can be avoided if the operator sets SPMEs in advance
and maintains it until the end of life of a transport path, which is
neither temporary nor on-demand. Furthermore SMPEs cannot be set
arbitrarily because overlapping of path segments is limited to
nesting relationships. As a result, possible SPME configurations of
segments of an original transport path are limited due to the
characteristic of SPME shown in Figure 1, even if SPMEs are pre-
configured.
Although the make-before-break procedure in the survivability
document RFC 6372 [RFC6372] seemingly supports the hitless
configuration for monitoring according to the framework document RFC
5921 [RFC5921], the reality is that configuration of an SPME is
impossible without violating network objective (2) in Section 3.
These concerns are described in section 3.8 of RFC 6371 [RFC6371].
Additionally, the make-before-break approach might not be usable in
the static model without a control plane. This is because the make-
before-break is a restoration function based on a control plane.
Consequently the management systems should support SPME creation and
coordinated traffic switching from original transport path to the
SPME.
Other potential risks are also envisaged. Setting up a temporary
SPME will result in the LSRs within the monitoring segment only
looking at the added (stacked) labels and not at the labels of the
original LSP. This means that problems stemming from incorrect (or
D'Alessandro, et al. Expires June 4, 2016 [Page 7]
Internet-Draft Enhanced path segment monitoring December 2015
unexpected) treatment of labels of the original LSP by the nodes
within the monitored segment can not be identified when setting up
SPME. This might include hardware problems during label look-up,
mis-configuration, etc. Therefore operators have to pay extra
attention to correctly setting and checking the label values of the
original LSP in the configuration. Of course, the reverse of this
situation is also possible, e.g., an incorrect or unexpected
treatment of SPME labels can result in false detection of a fault
where no problem existed originally.
The utilisation of SPMEs is basically limited to inter-carrier or
inter-domain segment monitoring where they are typically pre-
configured or pre-instantiated. SPME instantiates a hierarchical
transport path (introducing MPLS label stacking) through which OAM
packets can be sent. The SPME monitoring function is mainly
important for protecting bundles of transport paths and carriers'
carrier solutions within one administrative domain.
To summarize: the problem statement is that the current sub-path
maintenance based on a hierarchical LSP (SPME) is problematic for
pre-configuration in terms of increasing the bandwidth by label
stacking and increasing the number of managing objects by layer
stacking and address management. An on-demand/temporary
configuration of SPME is one of the possible approaches for
minimizing the impact of these issues. However, the current
procedure is unfavorable because the temporary configuration for
monitoring can change the condition of the original monitored
transport path. To avoid or minimize the impact of the drawbacks
discussed above, a more efficient approach is required for the
operation of an MPLS-TP transport network. A monitoring mechanism,
named on-demand Enhanced Path Segment Monitoring (EPSM), supporting
temporary and hitless path segment monitoring is proposed.
5. OAM functions supported in segment monitoring
OAM functions that may usefully be exploited across on-demand EPSM
are basically the on-demand performance monitoring functions which
are defined in OAM framework document RFC 6371 [RFC6371]. Segment
performance monitoring is used to verify the performance and hence
the status of transport path segments. The "on-demand" attribute is
generally temporary for maintenance operation.
Packet Loss and Packet Delay measurement are OAM functions strongly
required in hitless and temporary segment monitoring because these
functions are normally only supported at the end points of a
transport path. If a defect occurs, it might be quite hard to locate
the defect or degradation point without using the segment monitoring
function. If an operator cannot locate or narrow down the cause of
D'Alessandro, et al. Expires June 4, 2016 [Page 8]
Internet-Draft Enhanced path segment monitoring December 2015
the fault, it is quite difficult to take prompt actions to solve the
problem.
Other on-demand monitoring functions, (e.g. Delay Variation
measurement) are desirable but not as necessary as the functions
mentioned above.
Regarding out-of-service on-demand performance management functions
(e.g. Throughput measurement) there seems no need for EPSM.
However, OAM functions specifically designed for segment monitoring
should be developed to satisfy network objective (2) described in
Section 3.
Finally, the solution for EPSM has to cover both the per-node model
and the per-interface model as specified in RFC 6371 [RFC6371].
6. Requirements for enhanced segment monitoring
In the following sections, mandatory (M) and optional (O)
requirements for the enhanced segment monitoring function are listed.
6.1. Non-intrusive segment monitoring
One of the major problems of legacy SPME highlighted in section 4 is
that it may not monitor the original transport path and it could
distrupt service traffic when set-up on demand.
(M1) EPSM must not change the original condition of transport path
(e.g. must not change the length of MPLS frames, the exposed
label values, etc.)
(M2) EPSM must be provisioned on-demand without traffic
disruption.
6.2. Single and multiple level monitoring
The new enhanced segment monitoring function is supposed to be
applied mainly for on-demand diagnostic purposes. We can
differentiate this monitoring from the existing proactive segment
monitoring by referring to is as on-demand multi-level monitoring.
Currently the most serious problem is that there is no way to locate
the degraded segment of a path without changing the conditions of the
original path. Therefore, as a first step, single layer segment
monitoring, not affecting the monitored path, is required for a new
on-demand and hitless segment monitoring function. A combination of
multi-level and simultaneous segment monitoring is the most powerful
tool for accurately diagnosing the performance of a transport path.
However, in the field, a single level approach may be enough.
D'Alessandro, et al. Expires June 4, 2016 [Page 9]
Internet-Draft Enhanced path segment monitoring December 2015
(M3) Single-level segment monitoring is required
(O1) Multi-level segment monitoring is desirable
Figure 2 shows an example of multi-level on-demand segment
monitoring.
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
*-----------------* <=On-demand segm. mon. level 1
*-------------* <=On-demand segm. mon. level 2
*-* <=On-demand segm. mon. level 3
Figure 2: Example of multi-level on-demand segment monitoring
6.3. EPSM and end-to-end proactive monitoring independence
The need for simultaneously using existing end-to-end proactive
monitoring and the enhanced on-demand path segment monitoring is
considered. Normally, the on-demand path segment monitoring is
configured on a segment of a maintenance entity of a transport path.
In such an environment, on-demand single-level monitoring should be
performed without disrupting the pro-active monitoring of the
targeted end-to-end transport path to avoid affecting user traffic
performance monitoring.
Therefore:
(M4) EPSM shall be configured without changing or interfering with
the already in place end-to-end pro-active monitoring of the
transport path.
D'Alessandro, et al. Expires June 4, 2016 [Page 10]
Internet-Draft Enhanced path segment monitoring December 2015
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon.
*------------------* <= On-demand segment mon.
Figure 3: Independency between proactive end-to-end monitoring and
on-demand segment monitoring
6.4. Arbitrary segment monitoring
The main objective for enhanced on-demand segment monitoring is to
diagnose the fault locations. A possible realistic diagnostic
procedure is to fix one end point of a segment at the MEP of the
transport path under observation and change progressively the length
of the segments. This example is shown in Figure 4.
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= 1st on-demand segment mon.
*-------* <= 2nd on-demand segment mon.
*------------* <= 3rd on-demand segment mon.
| |
| |
*-----------------------* <= 6th on-demand segment mon.
*-----------------------------* <= 7th on-demand segment mon.
Figure 4: A procedure to localize a defect by consecutive on-demand
segment monitoring
Another possible scenario is depicted in Figure 5. In this case, the
operator wants to diagnose a transport path starting at a transit
node, because the end nodes(A and E) are located at customer sites
and consist of cost effective small boxes supporting only a subset of
OAM functions. In this case, where the source entities of the
diagnostic packets are limited to the position of MEPs, on-demand
segment monitoring will be ineffective because not all the segments
can be diagnosed (e.g. segment monitoring 3 in Figure 5 is not
D'Alessandro, et al. Expires June 4, 2016 [Page 11]
Internet-Draft Enhanced path segment monitoring December 2015
available and it is not possible to determine the fault location
exactly).
Therefore:
(M5) it shall be possible to provision EPSM on an arbitrary
segment of a transport path and diagnostic packets should be
inserted/terminated at any of intermediate maintenance points of
the original ME.
--- --- ---
--- | | | | | | ---
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Pro-active end-to-end mon.
*-----* <= On-demand segment mon. 1
*-----------------------* <= On-demand segment mon. 2
*---------* <= On-demand segment mon. 3
Figure 5: ESPM configured at arbitrary segments
6.5. Fault while EPSM is operational
Node or link failures may occur while EPSM is active. In this case,
if no resiliency mechanism is set-up on the subtended transport path,
there is no particular requirement for the EPSM function. If the
transport path is protected, the EPSM function should be terminated
to avoid monitoring a new segment when a protection or restoration
path is active.
Therefore:
(M6) the EPSM function should avoid monitoring an unintended
segment when one or more failures occur
The following examples are provided for clarification only and they
are not intended to restrict any solution for meeting the
requirements of EPSM.
Protection scenario A is shown in figure 6. In this scenario a
working LSP and a protection LSP are set-up. EPSM is activated
between nodes A and E. When a fault occurs between nodes B and C,
the operation of EPSM is not affected by the protection switch and
continues on the active LSP path. As a result requirement (M6) is
satisfied.
D'Alessandro, et al. Expires June 4, 2016 [Page 12]
Internet-Draft Enhanced path segment monitoring December 2015
A - B - C - D - E - F
\ /
G - H - I - L
Where:
- end-to-end LSP: A-B-C-D-E-F
- working LSP: A-B-C-D-E-F
- protection LSP: A-B-G-H-I-L-F
- EPSM: A-E
Figure 6: Protection scenario A
Protection scenario B is shown in figure 7. The difference with
scenario A is that only a portion of the transport path is protected.
In this case, when a fault occurs between nodes B and C on the
working sub-path B-C-D, traffic will be switched to protection sub-
path B-G-H-D. Assuming that OAM packet termination depends only on
the TTL value of the MPLS label header, the target node of the EPSM
changes from E to D due to the difference of hop counts between the
working path route (A-B-C-D-E: 4 hops) and protection path route
(A-B-G-H-D-E: 5 hops). As a result requirement (M6) is not
satisfied.
A - B - C - D - E - F
\ /
G - H
- end-to-end LSP: A-B-C-D-E-F
- working sub-path: B-C-D
- protection sub-path: B-G-H-D
- EPSM: A-E
Figure 7: Protection scenario B
6.6. EPSM maintenance points
An intermediate maintenance point supporting the EPSM function has to
be able to generate and inject OAM packets. However, maintenance
points for the EPSM do not necessarily have to coincide with MIPs or
MEPs defined in the architecture.
Therefore:
(M7) The same identifiers for MIPs and/or MEPs should be applied
to EPSM maintenance points
D'Alessandro, et al. Expires June 4, 2016 [Page 13]
Internet-Draft Enhanced path segment monitoring December 2015
7. Summary
An enhanced path segment monitoring (EPSM) mechanism is required to
provide temporary and hitless segment monitoring. It shall meet the
two network objectives described in section 3.8 of RFC 6371 [RFC6371]
and repeated in Section 3 of this document.
The enhancements should minimize the problems described in Section 4,
i.e., (P-1), (P-2), (P-3) and (P-4).
The solution for the temporary and hitless segment monitoring has to
cover both the per-node model and the per-interface model specified
in RFC 6371 [RFC6371].
The temporary and hitless segment monitoring solutions shall support
on-demand Packet Loss Measurement and Packet Delay Measurement
functions and optionally other performance monitoring and fault
management functions (e.g. Throughput measurement, Delay variation
measurement, Diagnostic test, etc.).
8. Security Considerations
The security considerations defined for RFC 6378 apply to this
document as well. As this is simply a re-use of RFC 6378, there are
no new security considerations.
9. IANA Considerations
There are no requests for IANA actions in this document.
Note to the RFC Editor - this section can be removed before
publication.
10. Acknowledgements
The author would like to thank all members (including MPLS-TP
steering committee, the Joint Working Team, the MPLS-TP Ad Hoc Group
in ITU-T) involved in the definition and specification of MPLS
Transport Profile.
The authors would also like to thank Alexander Vainshtein, Dave
Allan, Fei Zhang, Huub van Helvoort, Malcolm Betts, Italo Busi,
Maarten Vissers, Jia He and Nurit Sprecher for their comments and
enhancements to the text.
D'Alessandro, et al. Expires June 4, 2016 [Page 14]
Internet-Draft Enhanced path segment monitoring December 2015
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
"Requirements for Operations, Administration, and
Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
DOI 10.17487/RFC5860, May 2010,
<http://www.rfc-editor.org/info/rfc5860>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<http://www.rfc-editor.org/info/rfc5921>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations,
Administration, and Maintenance Framework for MPLS-Based
Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011,
<http://www.rfc-editor.org/info/rfc6372>.
Authors' Addresses
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Loa Andersson
Huawei Technologies
Email: loa@mail01.huawei.com
D'Alessandro, et al. Expires June 4, 2016 [Page 15]
Internet-Draft Enhanced path segment monitoring December 2015
Manuel Paul
Deutsche Telekom
Email: Manuel.Paul@telekom.de
Satoshi Ueno
NTT Communications
Email: satoshi.ueno@ntt.com
Kaoru Arai
NTT
Email: arai.kaoru@lab.ntt.co.jp
Yoshinori Koike
NTT
Email: y.koike@vcd.nttbiz.com
D'Alessandro, et al. Expires June 4, 2016 [Page 16]