MPLS Working Group Y.Koike
Internet Draft NTT
A. D'Alessandro
Telecom Italia
Intended status: Informational
Expires: September 13, 2011 March 14, 2011
Temporal and hitless path segment monitoring
draft-koike-mpls-tp-temporal-hitless-psm-02.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 September 13, 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
publication of this document. Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.
Koike Expires September 13, 2011 [Page 1]
Internet-Draft Temporal and hitless PSM March 2011
Abstract
The MPLS transport profile (MPLS-TP) is now being standardized to
enable carrier-grade packet transport and complement converged packet
network deployments. One of the most attractive features in MPLS-TP
is OAM functions, which enable network operators or service providers
to provide various maintenance characteristics, such as prompt fault
location, substantial survivability, performance monitoring, and
preliminary or in-service measurements, inherent in circuit-based
transport networks.
One of the important characteristics which are common in transport
network operation is the 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 for the segment monitoring(SPME) has some fatal issues. This
document elaborates on the problem statement on the path segment
monitoring function. Moreover, this document also requests to add
network objectives to solve or improve the issues and proposes to
reconsider the new improved method of the 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
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
Koike Expires September 13, 2011 [Page 2]
Internet-Draft Temporal and hitless PSM March 2011
8. Security Considerations.....................................13
9. IANA Considerations........................................13
10. References................................................14
10.1. Normative References..................................14
10.2. Informative References................................14
11. Acknowledgments...........................................14
Koike Expires September 13, 2011 [Page 3]
Internet-Draft Temporal and hitless PSM March 2011
1. Introduction
A packet transport network will enable carriers or service providers
to use network resources efficiently and reduce network cost. For
carrier-grade network operation, appropriate maintenance
characteristics, such as prompt fault location, substantial
survivability, performance monitoring, and preliminary or in-service
measurement, 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 to operator 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) it provides. 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 or management is not enough as a
maintenance tool. In end-to-end OAM monitoring, when one problem
occurs in an MPLS-TP network, the operator can detect the fault, but
cannot solve the issue efficiently. As the operator cannot localize
the point, he/she has no choice but to thoroughly search by trial and
error by replacing packages or changing configuration by disrupting
the connection service provided to customers. This is very
inefficient and far from a carrier-grade network.
As a result, 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 efficiently localize
the fault point. This is an important characteristic in transport
networks. However, a few fatal missing features, which are normally
met in transport network operation, were found regarding the segment
monitoring function of a transport path in the on-going MPLS-TP OAM
standard.
This document elaborates on the problem statement on the path segment
monitoring function. Moreover, this document also requests to add
network objectives to solve or improve the issues and proposes to
reconsider the new improved method of the segment monitoring.
2. Conventions used in this document
Koike Expires September 13, 2011 [Page 4]
Internet-Draft Temporal and hitless PSM March 2011
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].
2.1. Terminology
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 in the current on-
going MPLS-TP standard 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 was agreed in ITU-T SG15 that Network objective (1) is mandatory
and that regarding Network objective (2) the monitoring shall be
hitless and not change the forwarding behavior.
4. Problem statement
To monitor, protect, or manage a portion of a transport path, such as
LSP 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 LSP 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
Koike Expires September 13, 2011 [Page 5]
Internet-Draft Temporal and hitless PSM March 2011
stack entry (LSE) and interface identifier value at the corresponding
hierarchical LSP level in a per-node model.
This method can cause the following problems due to label stacking,
which are fatal in terms of cost and operation.
(P-1) Increasing the bandwidth by the stacking shim header(s)
(P-2) Increasing the address management of all MEPs and MIPs newly
configured for SPME in the old MEG
Problem (P-1) increases the operation cost and wastes bandwidth. As
the number of segments for monitoring increases, the number of label
stacking increases. Moreover this is a permanent monitoring element,
which should be set in advance, not a temporal setting. This prevents
the operator from securing the shared bandwidth for efficient
monitoring. However, the best solution is not to increase the
bandwidth for monitoring.
Problem (P-2) is related to an identifier issue, of which the
discussion is still continuing and not so fatal at the moment, but
can be quite inefficient if the policy of allocating the identifier
is independent in each layer. 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 identifier and managed layer
should be the fundamental direction in designing the architecture.
The most familiar example of the SPME in the transport network
standard is tandem connection monitoring (TCM), which is used for a
carrier's carrier solution 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).
To avoid these issues, the temporal setting of the SPME(s) only when
necessary seems reasonable and efficient for monitoring in MPLS-TP
transport network operation. Unfortunately, the method of temporal
settings of SPMEs also cause the following problems due to label
stacking, which are fatal in terms of intrinsic monitoring and
service disruption.
Koike Expires September 13, 2011 [Page 6]
Internet-Draft Temporal and hitless PSM March 2011
(P'-1) Changing the condition of the original transport path by
changing the length of the MPLS frame (delay measurement and loss
measurement can be sensitive)
(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.
The monitoring function checks 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 purpose of the
monitoring meaningless because it seems very possible that the result
of the monitoring does not reflect the data when the original fault
or degradation occurred.
In addition, changing the settings of the original shim header should
not be allowed because those changes correspond to creating a portion
of the original transport path, which is completely different from
the original circumstances.
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. This is not the monitoring of the original transport path but
the monitoring of a different path.
(Before SPME settings)
--- --- --- --- ---
| | | | | | | | | |
| | | | | | | | | |
--- --- --- --- ---
A--100--B--110--C--120--D--130--E
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
Koike Expires September 13, 2011 [Page 7]
Internet-Draft Temporal and hitless PSM March 2011
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 circumstances of the targeted
transport path, because the make-before-break procedure is premised
on the change of the label value. This means changing one of the
settings in MPLS shim header and should not be allowed as explained
in (P'-1) above.
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
traffics) as creation of an SPME on the same LSP.
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 on 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 may disappear when you set 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 way MPLS works requires use of SPMEs to be designed in advance,
hence the utility of SPMEs is basically limited.
To summarize, the problem statement is that the current sub-path
maintenance based on a hierarchical LSP (SPME) is problematic in
terms of increasing bandwidth by label stacking and managing objects
by layer stacking and address management. A temporal configuration of
SPME is one of the possible approaches for minimizing the impact of
these issues; however, the current method is not applicable 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, the solution for avoiding those issues or
minimizing their impact should be reconsidered.
Koike Expires September 13, 2011 [Page 8]
Internet-Draft Temporal and hitless PSM March 2011
5. OAM functions for segment monitoring
OAM functions in which segment monitoring is required are basically
limited to on-demand monitoring which are defined in OAM framework
document [5], because those segment monitoring functions are
basically used to locate the fault/degraded point or diagnose the
status for detailed analyses, especially when a problem occurred.
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
fault or defect 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,
temporal and hitless monitoring for packet loss and packet delay
measurements are indispensable for transport network operation.
Regarding other on-demand monitoring functions, segment monitoring is
desirable, but not as urgent as the packet loss and packet delay
measurements.
Regarding out-of-service on-demand monitoring functions, such as
diagnostic tests, there is no need of hitless settings. However,
specific segment monitoring is necessary for enabling the flexibility
in diagnostic test patterns.
Note:
The reason only on-demand OAM functions are discussed at this point
is because the characteristic of "on-demand" is generally temporal
for maintenance operation, and those operations are not reasonable
and should not be based on pre-configuration. Pre-design and pre-
configuration of PST/TCM (label stacking) for all the possible
patterns for the on-demand (temporal) usage are not reasonable,
because these tasks will additionally increase the operator's
burden, although pre-configuration of PST for pro-active usage may
be accepted considering the agreement thus far. Therefore, the
solution for temporal and hitless segment monitoring does not need
to be limited to label stacking mechanisms, such as PST/TCM(label
stacking), which can cause the issues (P-1) and (P-2) described in
Section 4.
Note that the issue of SPME is now under discussion in OAM
framework draft [5]. The results of the discussion will have to be
considered eventually. The solution for temporal and hitless
Koike Expires September 13, 2011 [Page 9]
Internet-Draft Temporal and hitless PSM March 2011
segment monitoring has to cover both per-node model and per-
interface model in the draft [5].
6. Further consideration of requirements for enhanced segment monitoring
An existing segment monitoring function relates to SPME that
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. From this
perspective, monitoring function related to can be considered
''proactive multi-layer monitoring,'' which has already been determined
by consensus to be mandatory in MPLS-TP.
6.1. Necessity of on-demand single-layer monitoring
In contrast to the ''proactive multi-layer monitoring'' so called
''SPME'', 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-
layer) 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.
A combination of multi-layer and simultaneous monitoring is the most
powerful tool for accurately diagnosing the performance of a
transport path. However, considering the balance of estimated
implementation difficulties and the substantial benefits to operators,
a strict monitoring function such as in a test environment in a
laboratory does not seem to be necessary in the field. To summarize,
on-demand and in-service (hitless) single-layer segment monitoring is
required, but the need for on-demand and in-service multi-layer
segment monitoring is not as urgent at the moment. Figure 2 shows an
example of a multi-layer on-demand segment monitoring.
Koike Expires September 13, 2011 [Page 10]
Internet-Draft Temporal and hitless PSM March 2011
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP
+-----------------------------+ <= Proactive E2E monitoring
*------------------* <= segment monitoring layer1
*-------------* <= segment monitoring layer2
*-* <= segment monitoring layer3
Figure 2 : An Example of a multi-layer on-demand segment monitoring
6.2. Necessity of on-demand monitoring independent from proactive
monitoring
As multi-layer simultaneous monitoring only in layers for on-demand
monitoring was already discussed in section6.1, we consider the
necessity of simultaneous proactive and on-demand monitoring.
Normally, on-demand segment monitoring is configured in a segment of
a maintenance entity of a transport path. In this environment, on-
demand single-layer monitoring should be done irrespective of the
status of pro-active monitoring of the targeted end-to-end transport
path.
If operators have to disable the pro-active monitoring during ''on-
demand and in-service'' 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.
From this perspective, the ability for on-demand single layer segment
monitoring is required without changing or interfering the proactive
monitoring of the original end-to-end transport path.
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP
+-----------------------------+ <= Proactive E2E monitoring
*------------------* <= On-demand segment monitoring
Figure 3 : Relation between proactive end-to-end monitoring and on-
demand segment monitoring
Koike Expires September 13, 2011 [Page 11]
Internet-Draft Temporal and hitless PSM March 2011
6.3. On-demand diagnostic procedures
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).
--- --- --- --- ---
| | | | | | | | | |
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP
+-----------------------------+<= Proactive E2E monitoring *-----* <= 1stOn-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 and in-service segment
monitoring 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.
Koike Expires September 13, 2011 [Page 12]
Internet-Draft Temporal and hitless PSM March 2011
--- --- ---
--- | | | | | | ---
| A | | B | | C | | D | | E |
--- --- --- --- ---
MEP MEP
+-----------------------------+<= 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
We request that the above two network objectives in Section 3 are
included in the MPLS-TP OAM framework. In addition, We also request
that the necessity of temporal and hitless path segment monitoring is
also described in the MPLS-TP OAM framework[5]. In addition, the
solution should be specified in other document and should minimize
the problems mentioned in Section 4, i.e., P-1, P-2, P'-1 and P'-2,
to meet those two network objectives. The solution is needed to
become normative in RFC for the consent of G.8113.x(G.tpoam) in
December 2011.
In addition, the following requirements should be considered for the
new enhanced temporal and hitless path segment monitoring funciton.
- An on-demand and in-service ''single-layer'' segment monitoring is
proposed. Multi-layer segment monitoring is optional.
- ''On-demand and in-service'' single layer 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 set
in an arbitrary segment of a transport path.
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.
Koike Expires September 13, 2011 [Page 13]
Internet-Draft Temporal and hitless PSM March 2011
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
[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. , "MPLS-TP OAM Framework", 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, Manuel Paul and Nurit Sprecher for their comments and
enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot.
Koike Expires September 13, 2011 [Page 14]
Internet-Draft Temporal and hitless PSM March 2011
Authors' Addresses
Yoshinori Koike (Editor)
NTT
Email: koike.yoshinori@lab.ntt.co.jp
Alessandro D'Alessandro (Editor)
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Koike Expires September 13, 2011 [Page 15]