Network Working Group A. D'Alessandro
Internet-Draft Telecom Italia
Intended status: Standards Track L. Andersson
Expires: January 21, 2016 Huawei Technologies
M. Paul
Deutsche Telekom
S. Ueno
NTT Communications
K. Arai
Y. Koike
NTT
July 20, 2015
Enhanced path segment monitoring
draft-ietf-mpls-tp-temporal-hitless-psm-07.txt
Abstract
The MPLS transport profile (MPLS-TP) has been standardized to enable
carrier-grade packet transport and complement converged packet
network deployments. Among the most attractive features of MPLS-TP
there are OAM functions, which enable network operators or service
providers to provide various maintenance characteristics, such as
fault location, survivability, performance monitoring and in-service/
out of service measurements.
One of the most important mechanisms which is common for transport
network operation is fault location. 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 effective only between end points. However, the current approach
defined for MPLS-TP for the segment monitoring (SPME) has some
drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provides monitoring of a
portion of a set of transport paths (LSPs or MS-PWs). Based on the
problems, this document specifies new requirements to consider a new
improved mechanism of hitless transport path segment monitoring 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 January 21, 2016 [Page 1]
Internet-Draft Enhanced path segment monitoring July 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 January 21, 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 . . . . . . . . . . . . . . . . . . . . . . 4
5. OAM functions supported in segment monitoring . . . . . . . . 8
6. Requirements for enhanced segment monitoring . . . . . . . . 8
6.1. Non intrusive segment monitoring . . . . . . . . . . . . 9
6.2. Single and multiple levels monitoring . . . . . . . . . . 9
6.3. EPSM and end-to-end proactive monitoring independence . . 10
6.4. Arbitrary segment monitoring . . . . . . . . . . . . . . 10
6.5. Fault while EPSM is in place . . . . . . . . . . . . . . 12
6.6. EPSM maintenance points . . . . . . . . . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
D'Alessandro, et al. Expires January 21, 2016 [Page 2]
Internet-Draft Enhanced path segment monitoring July 2015
1. Introduction
A packet transport network enables carriers or service providers to
use network resources efficiently, reduces operational complexity and
provides carrier-grade network operation. Appropriate maintenance
functions, supporting fault location, survivability, performance
monitoring and preliminary or in-service measurements, are essential
to ensure quality and reliability of a network. They are essential
in transport networks and have evolved along with TDM, ATM, SDH and
OTN.
As legacy technologies, also MPLS-TP does not scale when an arbitrary
number of OAM functions are 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 affecting services. In addition, to ensure that
faults or degradations can be localized, operators need a method to
analyze or investigate the problem being end-to-end monitoring
insufficient. In fact using end-to-end OAM monitoring, an operator
is not able to localize a fault or degrade.
Thus, a specific segment monitoring function for detailed analysis,
by selecting and focusing on a specific portion of a transport path,
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
function 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 work done in RFC 6371
[RFC6371]. Moreover, this document explains detailed requirements on
the new temporal and hitless segment monitoring function which are
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 January 21, 2016 [Page 3]
Internet-Draft Enhanced path segment monitoring July 2015
2.1. Terminology
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
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 required network objectives for MPLS-TP segment
monitoring as 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.
4. Problem Statement
Sub-Path Maintenance Element (SPME) is defined in RFC 5921 [RFC5921]
to monitor, protect, or manage portions of transport paths, such as
LSPs in MPLS-TP networks. The SPME is defined between the edges of
the portion of the transport path that needs to be monitored,
protected, or managed. This SPME is created by stacking the shim
D'Alessandro, et al. Expires January 21, 2016 [Page 4]
Internet-Draft Enhanced path segment monitoring July 2015
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 per-node model.
This method has the following drawbacks, which impact on operation
costs:
(P-1) Lowering the bandwidth efficiency by increasing the overhead
by shim headers stacking
(P-2) Increasing network management complexity, as a new sublayer
and new MEPs and MIPs need to be configured for the SPME
Problem (P-1) comes from shim headers stacking that increase the
overhead.
Problem (P-2) is related to identifiers management issue. The
identification of each sub-layer in case of label stacking is
required for the segment monitoring in a MPLS-TP network. When SPME
is applied for on-demand OAM functions in MPLS-TP networks in a
similar manner to TCM for OTN or Ethernet transport networks, a
possible rule of differentiating those SPME/TCMs operationally will
be necessary at least within an administrative domain. This enforces
operators to create an additional permanent layer identification
policy only for temporal path segment monitoring. Moreover, from the
perspective of operation, increasing the managed addresses and the
managed layers is not desirable to keep transport networks as simple
as possible. Reducing the managed identifiers and managed sub-layers
should be the fundamental direction in designing the architecture.
The analogy for SPME in legacy transport networks is Tandem
Connection Monitoring (TCM), which is on-demand and does not change
the transport path.
Moreover, using currently defined methods, the temporal setting of
SPMEs also causes the following problems due to label stacking:
(P-3) Changing the original condition of transport path by
changing the length of MPLS frames and changing the value of
exposed label
(P-4) Disrupting client traffic over a transport path, if the SPME
is configured on demand.
D'Alessandro, et al. Expires January 21, 2016 [Page 5]
Internet-Draft Enhanced path segment monitoring July 2015
Problem (P-3) has impacts on network objective (2). The monitoring
function should monitor the status without changing any conditions of
the targeted monitored segment or transport path. Changing the
settings of the original shim header should not be allowed because
those changes correspond to creating a new portion of the original
transport path, which differs from the original data plane
conditions. If the conditions of the transport path change, the
measured value or observed data will also change. This may make the
monitoring meaningless because the result of the monitoring would no
longer reflect the reality of the connection where the original fault
or degradation occurred.
Figure 1 shows an example of SPME setting. In the figure, X means
the label value expected on the tail-end node D of the original
transport path. "210" and "220" are label allocated for SPME. The
label values of the original path are modified as well as the values
of stacked label. As shown in Figure 1, SPME changes both the length
of MPLS frames and label value(s). This is no longer the monitoring
of the original transport path but the monitoring of a different
path. Particularly, performance monitoring measurement (e.g. Delay
measurement and packet loss measurement) are sensitive to those
changes.
(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 setting
D'Alessandro, et al. Expires January 21, 2016 [Page 6]
Internet-Draft Enhanced path segment monitoring July 2015
Problem (P-4) can be avoided if the operator sets SPMEs in advance
until the end of life of a transport path, which is neither temporal
nor on demand. Furthermore SMPEs cannot be set arbitrarly because
overlapping of path segments is limited to nesting relationship. As
a result, possible SPME patterns of portions 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 configurating an SPME is
impossible without violating network objective (2). These concerns
are reported in section 3.8 of RFC 6371 [RFC6371].
Moreover, make-before-break approach might not be effective under the
static model without a control plane because the make-before-break is
a restoration application based on the control plane. So management
systems should provide support for SPME creation and for coordinated
traffic switching from original transport path to the SPME.
Other potential risks are also envisaged. Setting up a temporal 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 unexpected)
treatment of labels of the original LSP by the nodes within the
monitored segment could not be found 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 inversion of this situation
is also possible, e.g., incorrect or unexpected treatment of SPME
labels can result in false detection of a fault where none of the
problem originally existed.
The utility 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. SPME construct monitoring function is particularly important
mainly for protecting bundles of transport paths and carriers'
carrier solutions. SPME is expected to be mainly used for protection
purpose 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 bandwidth by label stacking
and managing objects by layer stacking and address management. A on-
D'Alessandro, et al. Expires January 21, 2016 [Page 7]
Internet-Draft Enhanced path segment monitoring July 2015
demand/temporal configuration of SPME is one of the possible
approaches for minimizing the impact of these issues. However, the
current method is unfavorable because the temporal configuration for
monitoring can change the condition of the original monitored
transport path. To avoid the drawbacks discussed above, a more
efficient approach is required for MPLS-TP transport network
operation to overcome or minimize the impact of the above described
drawbacks. A monitoring mechanism, named on-demand Enhanced Path
Segment Monitoring (EPSM), supporting temporal and hitless path
segment monitoring is proposed.
5. OAM functions supported in segment monitoring
OAM functions that may useful exploited across on-demand EPSM are
basically limited to on-demand performance monitoring functions which
are defined in OAM framework document RFC 6371 [RFC6371]. Segment
performance monitoring is used to evaluate the performance and hence
the status of transport path segments. The "on-demand" attribute is
generally temporal for maintenance operation.
Packet loss and packet delay are OAM functions strongly required in
hitless and temporal segment monitoring because these functions are
supported only between 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 the cause of the fault, it is quite difficult
to take prompt actions to solve the problem.
Other on-demand monitoring functions, (e.g. and Delay variation
measurement) are desirable but not as necessary as the previous
mentioned functions.
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 per-node model and
per- interface model which are specified in RFC 6371 [RFC6371].
6. Requirements for enhanced segment monitoring
In the following clauses, mandatory (M) and optional (O) requirements
are for the new segment monitoring function are listed.
D'Alessandro, et al. Expires January 21, 2016 [Page 8]
Internet-Draft Enhanced path segment monitoring July 2015
6.1. Non intrusive segment monitoring
One of the major problem of legacy SPME that has been highlighted in
Sec. 4 is that it does 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 lenght of MPLS frames, the exposed label
values, etc.)
(M2) EPSM must be set on demand without traffic dispruption
6.2. Single and multiple levels monitoring
The new segment monitoring function is supposed to be applied mainly
for on-demand diagnostic purpose. We can differentiate this
monitoring from the proactive segment monitoring as on-demand multi-
level monitoring. The most serious problem at the moment is that
there is no way to localize the degraded portion 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, on field, a single level
approach may be enough.
(M3) Single-level segment monitoring is required
(O1) Multi-level segment monitoring is desirable
Figure 2 shows an example of a multi-level on-demand segment
monitoring.
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
*------------------* <=On-demand segm. monit. level 1
*-------------* <=On-demand segm. monit. level 2
*-* <=On-demand segm. monit. level 3
Figure 2: Example of multi-level on-demand segment monitoring
D'Alessandro, et al. Expires January 21, 2016 [Page 9]
Internet-Draft Enhanced path segment monitoring July 2015
6.3. EPSM and end-to-end proactive monitoring independence
The necessity of simultaneous monitoring of current end-to-end
proactive monitoring and new on-demand path segment monitoring is
here below considered. Normally, the on-demand path segment
monitoring is configured in a segment of a maintenance entity of a
transport path. In such an environment, on-demand single-level
monitoring should be done without disrupting pro-active monitoring of
the targeted end- to-end transport path to avoid missing user traffic
performance monitoring.
Accordingly,
(M4) EPSM shall be established without changing or interfering
with the already in place end-to-end pro-active monitoring of
transport path
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive E2E monitoring
*------------------* <= On-demand segment monitoring
Figure 3: Independency between proactive end-to-end monitoring and
on-demand segment monitoring
6.4. Arbitrary segment monitoring
The main objective of on-demand segment monitoring is to diagnose the
fault points. One 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.
D'Alessandro, et al. Expires January 21, 2016 [Page 10]
Internet-Draft Enhanced path segment monitoring July 2015
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive E2E monitoring
*-----* <= 1st on-demand segment monitoring
*-------* <= 2nd on-demand segment monitoring
*------------* <= 3rd on-demand segment monitoring
| |
| |
*-----------------------* <= 6th on-demand segment monitoring
*-----------------------------*<= 7th on-demand segment monitoring
Figure 4: A procedure to localize a defect by consecutive on-demand
segments monitoring
Another possible scenario is depicted in Figure 5. In this case, the
operators want to diagnose a transport path from a transit node that
is located at the middle, because the end nodes(A and E) are located
at customer sites and consist of cost effective small box supporting
only a subset of OAM functions. In that case, if 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 available and it is not possible to precisely localize the fault
point).
Accordingly,
(M5) EPSM shall be set in an arbitrary segment of a transport path
and diagnostic packets should be inserted/terminated at any of
intermediate maintenance points of the original ME.
D'Alessandro, et al. Expires January 21, 2016 [Page 11]
Internet-Draft Enhanced path segment monitoring July 2015
--- --- ---
--- | | | | | | ---
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP <= ME of a transport path
+-----------------------------+ <= Proactive E2E monitoring
*-----* <= On-demand segment monitoring 1
*-----------------------*<= On-demand segment monitoring 2
*---------* <= On-demand segment monitoring 3
Figure 5: HSPM is configured at arbitrary segments
6.5. Fault while EPSM is in place
Node or link failures may occur while EPSM is active. In that case,
if no resiliency mechanism is set-up on the subtended transport path,
there is no particular requirement for EPSM while if the trasport
path is protected, EPSM function should be terminated to avoid
monitoring a new segment when a protection or restoration path is in
place. Therefore
(M5) EPSM function should avoid monitoring an unintended segment
when failures occur
The folowing examples are reported for clarification only and shall
not be intended to restrict any solution for meeting the requirements
of EPSM. A Protection scenario A is shown in figure 6. In this
scenario, a working LSP and a protection LSP are set. EPSM is set
between A and E. Considering a fault happens between nodes B and C,
the EPSM is not affected by protection and continues in the working
LSP path. As a result, requirement (M5) is satisfied.
A - B - C - D - E - F
\ /
G - H - I - L
Where:
- e2e 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
D'Alessandro, et al. Expires January 21, 2016 [Page 12]
Internet-Draft Enhanced path segment monitoring July 2015
Differently, figure 7 shows a scenario where only a portion of a
transport path is protected. In this case, when a fault happen
between node B and C along the working sub-path, traffic is switched
to protection sub-path B-G-H-D. In the hypotesis that OAM packets
termination depend only on TTL value of MPLS label header, the target
node of EPSM changes from E to D due to the difference of hop counts
between the working path route (ABCDE: 4 hops) and protection path
route (ABGHDE: 5 hops). As a result, requirement (M5) is not
satisfied.
A - B - C - D - E - F
\ /
G - H
- e2e 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 has to be able
to generate and inject OAM packets. Although maintenance points for
the EPSM do not necessarily have to coincide with MIPs or MEPs in
terms of the architecture definition,
(M7) The same identifiers for MIPs and/or MEPs should be applied
to EPSM maintenance points
7. Summary
An enhanced monitoring mechanism is required to support temporal and
hitless segment monitoring which meets the two network objectives
described in section 3.8 of RFC 6371 [RFC6371] and reported in
Section 3 of this document.
The enhancements should minimize the issues described in Section 4,
i.e., P-1, P-2, P-3 and P-4.
The solution for the temporal and hitless segment monitoring has to
cover both per-node model and per-interface model which are specified
in RFC 6371 [RFC6371].
D'Alessandro, et al. Expires January 21, 2016 [Page 13]
Internet-Draft Enhanced path segment monitoring July 2015
The temporal and hitless segment monitoring solutions shall support
on-demand Packet Loss Measurement and Packet Delay Measurement
functions and optionally other performance monitoring /fault
management functions (e.g. Throughput measurement, Delay variation
measurement, Diagnostic test measurement, 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, Italo Busi, Maarten Vissers,
Malcolm Betts, Nurit Sprecher and Jia He for their comments and
enhancements to the text.
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>.
D'Alessandro, et al. Expires January 21, 2016 [Page 14]
Internet-Draft Enhanced path segment monitoring July 2015
[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
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
D'Alessandro, et al. Expires January 21, 2016 [Page 15]
Internet-Draft Enhanced path segment monitoring July 2015
Yoshinori Koike
NTT
Email: koike.yoshinori@lab.ntt.co.jp
D'Alessandro, et al. Expires January 21, 2016 [Page 16]