MPLS Working Group                                            Y.Koike
Internet Draft                                                    NTT


Intended status: Informational
Expires: January 4, 2011                                  July 5, 2010


               Temporal and hitless path segment monitoring
              draft-koike-mpls-tp-temporal-hitless-psm-00.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 January 4, 2011.

Copyright Notice

   Copyright (c) 2009 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 January 4, 2011                [Page 1]


Internet-Draft        Temporal and hitless PSM               July 2010


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.........................7
   6. Conclusion..................................................8
   7. Security Considerations......................................8
   8. IANA Considerations.........................................8
   9. References..................................................9
      9.1. Normative References....................................9
      9.2. Informative References..................................9
   10. Acknowledgments............................................9


Koike                  Expires January 5, 2010                [Page 2]


Internet-Draft        Temporal and hitless PSM               July 2010


   Authors' Addresses.............................................9














































Koike                  Expires January 5, 2010                [Page 3]


Internet-Draft        Temporal and hitless PSM               July 2010


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 January 5, 2010                [Page 4]


Internet-Draft        Temporal and hitless PSM               July 2010


   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

   SDH  Synchronous Digital Hierarchy

   SPME Sub-path Maintenance Element

  2.2. Definitions

   None

3. Network objectives for monitoring

   There are two missing and indispensable network objectives in the
   current on-going MPLS-TP standard.

   (1) The monitoring and maintenance of current transport paths has to
   be conducted in service without traffic disruption.

   (2) The monitored or managed transport path condition has to be
   exactly the same irrespective of any configurations necessary for
   maintenance.

   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
   stack entry (LSE) and interface identifier value at the corresponding
   hierarchical LSP level in a per-node model.



Koike                  Expires January 5, 2010                [Page 5]


Internet-Draft        Temporal and hitless PSM               July 2010


   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 staking 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.

   (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)




Koike                  Expires January 5, 2010                [Page 6]


Internet-Draft        Temporal and hitless PSM               July 2010


   (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.

   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 is not effective under the static
   model without a control plane because the make-before-break is a
   restoration application based on the control plane.

   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.

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



Koike                  Expires January 5, 2010                [Page 7]


Internet-Draft        Temporal and hitless PSM               July 2010


   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.



6. 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 solution for temporal and hitless path segment monitoring
   should never cause the problems mentioned in Section 4, i.e., P-1, P-
   2, P'-1 and P'-2, or at least minimize their impact to meet those two
   network objectives. As indicated liaison from ITU-T SG15, the
   provided solution is needed to become normative for the preparation
   of G.tpoam before it is consented.



7. Security Considerations

   This document does not by itself raise any particular security
   considerations.

8. IANA Considerations

   There are no IANA actions required by this draft.




Koike                  Expires January 5, 2010                [Page 8]


Internet-Draft        Temporal and hitless PSM               July 2010


9. References

  9.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-to-be(work in progress), 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-05.txt(work in progress), April 2010

   [5]  Busi, I., Niven-Jenkins, B. , "MPLS-TP OAM Framework", draft-
         ietf-mpls-tp-oam-framework-06.txt(work in progress), April 2010

  9.2. Informative References

   None

10. Acknowledgments

   The authors 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.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Addresses

   Yoshinori Koike (Editor)
   NTT
   Email:  koike.yoshinori@lab.ntt.co.jp










Koike                  Expires January 5, 2010                [Page 9]