Internet DRAFT - draft-koike-mpls-tp-temporal-hitless-psm
draft-koike-mpls-tp-temporal-hitless-psm
MPLS Working Group A. D'Alessandro
Internet Draft Telecom Italia
M.Paul
Deutsche Telekom
Intended status: Informational S. Ueno
NTT Communications
Y.Koike
NTT
Expires: April 30, 2012 October 31, 2011
Temporal and hitless path segment monitoring
draft-koike-mpls-tp-temporal-hitless-psm-04.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 30, 2011.
Copyright Notice
Copyright (c) 2011 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
Koike Expires April 30, 2012 [Page 1]
Internet-Draft Temporal and hitless PSM October 2011
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.
Abstract
The MPLS transport profile (MPLS-TP) is being standardized to enable
carrier-grade packet transport and complement converged packet
network deployments. Among the most attractive features of MPLS-TP
are OAM functions, which enable network operators or service
providers to provide various maintenance characteristics, such as
fault location, survivability, performance monitoring, and
preliminary or in-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 fatal
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.
This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network.
Table of Contents
1. Introduction ................................................ 4
2. Conventions used in this document............................ 4
2.1. Terminology ............................................ 5
2.2. Definitions ............................................ 5
3. Network objectives for monitoring............................ 5
Koike Expires April 30, 2012 [Page 2]
Internet-Draft Temporal and hitless PSM October 2011
4. Problem statement ........................................... 5
5. OAM functions for segment monitoring ......................... 9
6. Further consideration of requirements for enhanced segment
monitoring .................................................... 10
6.1. Necessity of on-demand single-layer monitoring.......... 10
6.2. Necessity of on-demand monitoring independent from proactive
monitoring ................................................. 11
6.3. On-demand diagnostic procedures ........................ 12
7. Conclusion ................................................. 13
8. Security Considerations..................................... 14
9. IANA Considerations ........................................ 14
10. References ................................................ 14
10.1. Normative References.................................. 14
10.2. Informative References................................ 15
11. Acknowledgments ........................................... 15
Koike Expires April 30, 2012 [Page 3]
Internet-Draft Temporal and hitless PSM October 2011
1. Introduction
A packet transport network will enable carriers or service providers
to use network resources efficiently, reduce operational complexity
and provide 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.
Unlike in SDH or OTN networks, where OAM is an inherent part of every
frame and frames are also transmitted in idle mode, it is not per se
possible to constantly monitor the status of individual connections
in packet networks. Packet-based OAM functions are flexible and
selectively configurable according to operators' needs.
According to the MPLS-TP OAM requirements [1], mechanisms MUST be
available for alerting a service provider of a fault or defect
affecting the service(s) provided. In addition, to ensure that faults
or degradations can be localized, operators need a method to analyze
or investigate the problem. From the fault localization perspective,
end-to-end monitoring is insufficient. Using end-to-end OAM
monitoring, when one problem occurs in an MPLS-TP network, the
operator can detect the fault, but is not able to localize it.
Thus, a specific segment monitoring function for detailed analysis,
by focusing on and selecting 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[5],
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 of the segment monitoring, following up the work done in [5].
Moreover, this document explains detailed requirements on the new
temporal and hitless segment monitoring function which are not
covered in [5].
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 [1].
Koike Expires April 30, 2012 [Page 4]
Internet-Draft Temporal and hitless PSM October 2011
2.1. Terminology
HSPM Hitless Path Segment Monitoring
LSP Label Switched Path
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 monitoring
There are two indispensable network objectives for MPLS-TP networks
as described in section 3.8 of [5].
(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.
It is common in transport networks that network objective (1) is
mandatory and that regarding network objective (2) the monitoring
shall not change the forwarding behavior.
4. Problem statement
To monitor, protect, or manage portions of transport paths, such as
LSPs in MPLS-TP networks, the Sub-Path Maintenance Element (SPME) is
defined in [2]. 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 header (MPLS
header)[3] 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.
Koike Expires April 30, 2012 [Page 5]
Internet-Draft Temporal and hitless PSM October 2011
This method has the following general issues, which are fatal in
terms of cost and operation.
(P-1) Increasing the overhead by the stacking of shim header(s)
(P-2) Increasing the address management complexity, as new MEPs and
MIPs need to be configured for the SPME in the old MEG
Problem (P-1) leads to decreased efficiency as bandwidth is wasted
only for maintenance purposes. As the size of monitored segments
increases, the size of the label stack grows. Moreover, if the
operator wants to monitor the portion of a transport path without
service disruption, one or more SPMEs have to be set in advance until
the end of life of a transport path, which is not temporal or on-
demand. Consuming additional bandwidth permanently for only the
monitoring purpose should be avoided to maximize the available
bandwidth.
Problem (P-2) is related to an identifier-management issue. The
identification of each layer in case of LSP label stacking is
required in terms of strict sub-layer management for the segment
monitoring in a MPLS-TP network. There is no standardized way to
identify a layer, however a possible rule of differentiating layers
will be necessary at least within an administrative domain, if SPME
is applied for on-demand OAM functions. 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 layer is
not desirable in terms of simplified operation featured by current
transport networks. Reducing the managed identifiers and managed
layers should be the fundamental direction in designing the
architecture.
The most familiar example for SPME in transport networks is Tandem
Connection Monitoring (TCM), which can for example be used for a
carrier's carrier solution, as shown in Fig. 17 of the framework
document[2]. However, in this case, the SPMEs have to be pre-
configured. If this solution is applied to specific segment
monitoring within one operator domain, all the necessary specific
segments have to be pre-configured. This setting increases the
managed objects as well as the necessary bandwidth, shown as Problem
(P-1) and (P-2). Moreover, as a result of these pre-configurations,
they impose operators to pre-design the structure of sub-path
maintenance elements, which is not preferable in terms of operators'
increased burden. These concerns are summarized in section 3.8 of [5].
Koike Expires April 30, 2012 [Page 6]
Internet-Draft Temporal and hitless PSM October 2011
Furthermore, in reality, all the possible patterns of path segment
cannot be set in SPME, 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. This restriction is inconvenient when operators have to
fix issues in an on-demand manner.To avoid these issues, the temporal
and on-demand setting of the SPME(s) is needed and more efficient for
monitoring in MPLS-TP transport network operation.
However, using currently defined methods, the temporal setting of
SPMEs also causes the following problems due to label stacking, which
are fatal in terms of intrinsic monitoring and service disruption.
(P'-1) Changing the condition of the original transport path by
changing the length of all the MPLS frames and changing label
value(s)
(P'-2) Disrupting client traffic over a transport path, if the SPME
is temporally configured.
Problem (P'-1) is a fatal problem in terms of intrinsic monitoring.
As shown in network objective (2), the monitoring function needs to
monitor the status without changing any conditions of the targeted
monitored segment or the transport path. If the conditions of the
transport path change, the measured value or observed data will also
change. This can 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.
Another aspect is that 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.
Figure 1 shows an example of SPME setting. In the figure, X means the
one label 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 Fig.1, SPME changes the length of all the MPLS
frames and changes 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 (Delay measurement
and loss measurement) are sensitive to those changes.
Koike Expires April 30, 2012 [Page 7]
Internet-Draft Temporal and hitless PSM October 2011
(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
MEP \ / MEP <= transport path
--210--C--220-- <= SPME
MEP' MEP'
Figure 1 : An Example of a SPME setting
Problem (P'-2) was not fully discussed, although the make-before-
break procedure in the survivability document [4] seemingly supports
the hitless configuration for monitoring according to the framework
document [2]. The reality is the hitless configuration of SPME is
impossible without affecting the conditions of the targeted transport
path, because the make-before-break procedure is premised on the
change of the inner label value. This means changing one of the
settings in MPLS shim header.
Moreover, this 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. The removal of SPME whose
segment is monitored could have the same impact (disruption of client
traffic) as the creation of an SPME on the same LSP.
Note: (P'-2) will be removed when non-disruptive make-before-break
(in both with and without C-plane environment) is specified in other
MPLS-TP documents. However, (P'-2) could be replaced with the
following issue. ''Non-disruptive MBB, in other words, taking an
action similar to switching just for monitoring is not an ideal
operation in transport networks.
The 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
Koike Expires April 30, 2012 [Page 8]
Internet-Draft Temporal and hitless PSM October 2011
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-
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( and disrupt the in-service customer traffic). From
the perspective of monitoring in transport network operation, a
solution avoiding those issues or minimizing their impact is required.
Another monitoring mechanism is therefore required that supports
temporal and hitless path segment monitoring. Hereafter it is called
on-demand hitless path segment monitoring (HPSM).
Note: The above sentence ''and disrupt the in-service customer
traffic'' might need to be modified depending on the result of future
discussion about (P'-2).
5. OAM functions using segment monitoring
OAM functions in which on-demand HPSM is required are basically
limited to on-demand monitoring which are defined in OAM framework
document [5], because those segment monitoring functions are used to
locate the fault/degraded point or to diagnose the status for
detailed analyses, especially when a problem occurred. In other words,
the characteristic of "on-demand" is generally temporal for
maintenance operation. Conversely, this could be a good reason that
operations should not be based on pre-configuration and pre-design.
Koike Expires April 30, 2012 [Page 9]
Internet-Draft Temporal and hitless PSM October 2011
Packet loss and packet delay measurements are OAM functions in which
hitless and temporal segment monitoring are strongly required because
these functions are supported only between end points of a transport
path. If a fault or defect occurs, there is no way 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 action to solve the
problem. Therefore, on-demand HPSM for packet loss and packet delay
measurements are indispensable for transport network operation.
Regarding other on-demand monitoring functions path segment
monitoring is desirable, but not as urgent as for packet loss and
packet delay measurements.
Regarding out-of-service on-demand monitoring functions, such as
diagnostic tests, there seems no need for HPSM. However, specific
segment monitoring should be applied to the OAM function of
diagnostic test, because SPME doesn't meet network objective (2) in
section 3. See section 6.3.
Note:
The solution for temporal and hitless segment monitoring should not
be limited to label stacking mechanisms based on pre-configuration,
such as PST/TCM(label stacking), which can cause the issues (P-1)
and (P-2) described in Section 4.
The solution for HPSM has to cover both per-node model and per-
interface model which are specified in [5].
6. Further consideration of requirements for enhanced segment monitoring
6.1. Necessity of on-demand single-level monitoring
The new segment monitoring function is supposed to be applied mainly
for diagnostic purpose on-demand. 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 degradation point on 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.
Koike Expires April 30, 2012 [Page 10]
Internet-Draft Temporal and hitless PSM October 2011
A combination of multi-level and simultaneous monitoring is the most
powerful tool for accurately diagnosing the performance of a
transport path. However, considering the substantial benefits to
operators, a strict monitoring function which is required in such as
a test environment of a laboratory does not seem to be necessary in
the field. To summarize, on-demand and in-service (hitless) single-
level segment monitoring is required, on-demand and in-service multi-
level segment monitoring isdesirable. 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
+-----------------------------+ <= End-to-end monitoring
*------------------* <= segment monitoring level1
*-------------* <= segment monitoring level2
*-* <= segment monitoring level3
Figure 2 : An Example of a multi-level on-demand segment monitoring
6.2. Necessity of on-demand monitoring independent from end-to-end
proactive monitoring
As multi-level simultaneous monitoring only for on-demand new path
segment monitoring was already discussed in section6.1, next we
consider the necessity of simultaneous monitoring of end-to-end
current proactive monitoring and new on-demand path segment
monitoring. Normally, the on-demand path segment monitoring is
configured in a segment of a maintenance entity of a transport path.
In this environment, on-demand single-level monitoring should be done
without disrupting pro-active monitoring of the targeted end-to-end
transport path.
If operators have to disable the pro-active monitoring during the on-
demand hitless path segment monitoring, the network operation system
might miss any performance degradation of user traffic. This kind of
inconvenience should be avoided in the network operations.
Accordingly, the on-demand single lavel path segment monitoring is
required without changing or interfering the proactive monitoring of
the original end-to-end transport path.
Koike Expires April 30, 2012 [Page 11]
Internet-Draft Temporal and hitless PSM October 2011
--- --- --- --- ---
| | | | | | | | | |
| 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.3. Necessity of arbitrary segment monitoring
The main objective of on-demand segment monitoring is to diagnose the
fault points. One possible diagnostic procedure is to fix one end
point of a segment at the MEP of a transport path and change
progressively the length of the segment in order. This example is
shown in Fig. 4. This approach is considered as a common and
realistic diagnostic procedure. In this case, one end point of a
segment can be anchored at MEP at any time.
Other scenarios are also considered, one shown in Fig. 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
in which a subset of OAM functions are supported. In this case, if
one end point and an originator of the diagnostic packet are limited
to the position of MEP, on-demand segment monitoring will be
ineffective because all the segments cannot be diagnosed (For example,
segment monitoring 3 in Fig.5 is not available and it is not possible
to localize the fault point).
Koike Expires April 30, 2012 [Page 12]
Internet-Draft Temporal and hitless PSM October 2011
--- --- --- --- ---
| | | | | | | | | |
| 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 : One possible procedure to localize a fault point by
sequential on-demand segment monitoring
Accordingly, on-demand monitoring of arbitrary segments is mandatory
in the case in Fig. 5. As a result, on-demand HSPM should be set in
an arbitrary segment of a transport path and diagnostic packets
should be inserted from at least any of intermediate maintenance
points of the original ME.
--- --- ---
--- | | | | | | ---
| 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 : Example where on-demand monitoring has to be configured in
arbitrary segments
7. Conclusion
It is requested that another monitoring mechanism is required to
support temporal and hitless segment monitoring which meets the two
network objectives mentioned in Section 3 of this draftthat are
described also in section 3.8 of [5].
The enhancements should minimize the issues described in Section 4,,
i.e., P-1, P-2, P'-1( and P'-2,) to meet those two network objectives.
Koike Expires April 30, 2012 [Page 13]
Internet-Draft Temporal and hitless PSM October 2011
The solution for the temporal and hitless segment monitoring has to
cover both per-node model and per-interface model which are specified
in [5]. In addition, the following requirements should be considered
for an enhanced temporal and hitless path segment monitoring function.
Note: (P'-2) needs to be reconsidered.- An on-demand and in-service
''single-level'' segment monitoring ismandatory. Multi-level segment
monitoring is optional.
- ''On-demand and in-service'' single level segment should be done
without changing or interfering any condition of pro-active
monitoring of an original ME of a transport path.
- On-demand and in-service segment monitoring should be able to be
set in an arbitrary segment of a transport path.
The followings are specific requirements on each on-demand OAM
function.Mandatory: Packet Loss Measurement and Packet Delay
Measurement
Option: Connectivity verification, Diagnostic Tests (Throughput test),
Route tracing
8. Security Considerations
This document does not by itself raise any particular security
considerations.
9. IANA Considerations
There are no IANA actions required by this draft.
10. References
10.1. Normative References
[1] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC5860, May 2010
[2] Bocci, M., et al., "A Framework for MPLS in Transport Networks",
RFC5921, July 2010
[3] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
January 2001
Koike Expires April 30, 2012 [Page 14]
Internet-Draft Temporal and hitless PSM October 2011
[4] Sprecher, N., Farrel, A. , ''Multiprotocol Label Switching
Transport Profile Survivability Framework'', draft-ietf-mpls-tp-
survive-fwk-06.txt(work in progress), June 2010
[5] Busi, I., Dave, A. , "Operations, Administration and
Maintenance Framework for MPLS-based Transport Networks ",
draft-ietf-mpls-tp-oam-framework-11.txt(work in progress),
February 2011
10.2. Informative References
None
11. Acknowledgments
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 and Nurit Sprecher for their comments and enhancements to the
text.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Manuel Paul
Deutsche Telekom
Email: Manuel.Paul@telekom.de
Satoshi Ueno
NTT Communications
Email: satoshi.ueno@ntt.com
Yoshinori Koike
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Koike Expires April 30, 2012 [Page 15]