INTERNET-DRAFT Koike, Yoshinori Intended Status: Informational NTT Expires: April 29, 2010 October 26, 2009 MPLS-TP OAM maintenance points draft-koike-ietf-mpls-tp-oam-maintenance-points-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 April 29, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract MPLS transport profile (MPLS-TP) is expected to be one of the promising future transport technologies which will realize carrier grade packet transport network and complement future development of network. One of the most important features in MPLS-TP is the OAM tool/function which enables operators or service providers to provide various kinds of service characteristics such as prompt fault location, substantial survivability, performance monitoring, preliminary or in-service measurement and so on. Considering those new feature as transport profile, the definition of the maintenance points at which OAM messages are initiated, terminated and reacted are very important. This document describes the guidance and requirements regarding those maintenance points in MPLS-TP network. Table of Contents 1. Introduction 2 2. Conventions used in this document 3 2.1. Terminology 3 3. Maintenance operations in transport network 4 3.1. Fault location 4 4. Scenarios of maintenance points location 5 4.1. Fault location 5 5. < Requirements for maintenance points > 7 6. Security Considerations 8 7. IANA Considerations 8 8. References 8 8.1. Normative References 8 8.2. Informative References 8 9. Acknowledgments 9 1. Introduction A packet transport network will enable carriers or service providers to use network resources efficiently and reduce network cost. On the other hand, various maintenance operations such as prompt fault location, substantial survivability, performance monitoring, preliminary or in-service measurement are essential factors as well as quality and reliability of the system. These characteristics are mostly the best features of circuit management schemes such as ATM, SDH and OTN. Unlike the SDH or OTN, one of the fatal disadvantages in packet network is that we cannot constantly monitor the status of connections. In other words, unless one maintenance point receives packets, operators can never obtain information on the status of connections. To make up for this drawback, it is important to define appropriate maintenance points after fully understanding why fault location is essential and the factors which comprise the network (transmission line and network element). If maintenance points are not defined properly, any excellent OAM function may become meaningless for fault locations and preventive maintenance and so on. Therefore, it should be significantly considered to prioritize the definition of maintenance points. This document clarifies a few requirements on OAM maintenance points by showing the background. 2. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 ME Maintenance Entity MEG Maintenance Entity Group MEP Maintenance Entity Group End Point MIP Maintenance Entity Group Intermediate Point NE Network Element OTN Optical Transport Network SDH Synchronous Digital Hierarchy 3. Maintenance operations in transport network 3.1. Fault location The following three characteristics are significant in circuit management schemes, such as SDH and OTN. C1) When a fault occurs with client traffic, it must be possible to locate the cause of the fault in client data traffic, that is, whether it is within one administrative domain or outside the domain. C2) When a fault occurs in the MPLS-TP connection within one administrative domain, it is possible to locate whether the cause is within a node (equipment alarm:EQP) or between two neighbouring nodes (communication alarm:COM). C3) When a fault is detected within one node, it must be possible to take prompt and appropriate actions by replacing packages/line cards/modules or by changing settings with the package, port, section, or connection unit . If a fault occurs in client traffic, the problem is whether the cause is within our administrative domain or outside it. How quickly we can deal with the problem will be an important factor for providing effective maintenance services for our customers. If the fault is not quickly located, operators might have to spend much meaningless efforts although the cause is outside the administrative domain. Therefore, C1) is an inevitable characteristic of the transport profile. Then, if the fault is within one administrative domain, the next action is to determine if the problem is within one node or transmission line, in other words, whether it is an equipment alarm or communication alarm. The basic reason the two alarms are separately defined in a transport network is dependent on the characteristic difference of two network components, the node or the transmission line. The quality of the node is mainly regulated by that of the switch or forwarding block, whose implementation is quite different among system vendors. On the other hand, the quality of the transmission line is mainly regulated by that of the line card/IF package and transmission media. The line card/IF package is not as different among system vendors, compared with the forwarding and switching blocks. Accordingly, the separation between the switching and transmission parts is quite reasonable from the perspective of architecture design. After the operator locates the fault point, it is highly recommended to restore the failure and the suspected package, which is detected based on the above separation of the management section, has to be replaced immediately. Efficiently handling this problem and avoiding any effect on other client traffic, which does not encounter faults and is not related to the fault, are important. In a packet transport network, the fault should be located with a logical connection unit such as PW/LSP. 4. Scenarios of maintenance points location Note: Fault location and delay measurement needs to be described separately and respectively 4.1. Fault location To fulfill the characteristics of fault location in transport networks, which is described in section 3.1, maintenance points (maintenance end point (MEP) and maintenance intermediate point (MIP)) is the most essential factor when MPLS-TP OAM framework is considered. The maintenance points must be properly deployed for fault management, test and performance management. In typical transport systems, such as SDH and OTN, generally alarm detection and performance monitoring for input or output signal is done in an IF package or line card. Those IF packages or line cards are usually positioned on both sides of the switching/forwarding package. This structure makes it possible to fulfil the characteristics in section 3.1. Figure.1 shows the definition of maintenance points, which fulfill the characteristics discussed in section 3.1 in packet transport networks. Customer Operator's administrative Customer Domain Domain Domain -------> <-----------------------------------> <------ NE1 SN1 SN2 SN3 NE2 <--------> <--------> <--------> +---+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +---+ P1 SW1 P2 P3 SW2 P4 P5 SW3 P6 V--------*----*-------*----*--------V MEP MIP MIP MIP MIP MEP Loopback (1)<========> (2)<=============> (3)<====================> (4)<==========================> (5)<===================================> <--><--------><--><--------><--><--------><--> COM EQP COM EQP COM EQP COM Figure 1: Example of required settings of MIPs and MEPs in one PW/LSP of MPLS-TP network The following two cases based on Figure.1 explain two concrete problems, which are related to characteristics (C1) and (C2) in section 2.1. Case 1: Loopback (2) is no good (NG), and P1 correctly receives client packets Case 2: Customer traffic between NE1 and NE2 contains a fault. Loopback (4) is OK In Case 1, the suspected fault point is a physical interface (P2 or P3), switch fabric of SN1, or transmission line between MIP1 and MIP2. We cannot narrow the suspected point where the problem exists. If operators in the administrative domain define MIP1 in P2, they can obtain additional information on the fault by practicing Loopback (1). If the result of Loopback (1) is OK, the suspected points are almost limited to the transmission line between MIP1 and MIP2 or P3. If the result of Loopback (1) is NG, the suspected points are almost P2 or switch fabric on SN1. By effectively replacing or switching the suspected package based on the result of fault location, they can easily solve the problem. Similarly, in case 2, they have another problem. In this case, it is first assumed that MIP4 corresponds to MEP2 and loopback (4) is OK. They would like to ask the client domain to respond to loopback, if possible. However, there is a possibility that a customer will never allow a response to the loopback from the operators domain. In that case, they cannot handle the problem, and replacing the switch fabric should be avoided because it can affect other customers' traffic. If MEP2 is assigned and Loopback (5) is OK, the suspected points are almost limited to the transmission line between MEP2 and the client node or to the line card in the client node. ?As explained above, setting maintenance points on both sides of the switch fabric enable operators to locate fault points easily and perform maintenance more efficiently. What it comes down to is that at edge nodes it must be possible to set one MIP and one MEP; one MIP at the far side of physical interface from client node and one MEP near side of physical interface from client node. Moreover, at the intermediate nodes, it must be possible to set two MIPs; one MIP on one side of the physical interface and the other on the other side. 5. Requirements for maintenance points On the basis of discussion in the previous sections, the following three requirements must be included in the MPLS-TP OAM framework. 1) At the intermediate node on PW/LSP, it should be possible to set two MIPs on both sides of the switch fabric/forwarding part, respectively. 2) At the edge node on PW/LSP, it should be possible to set one MIP and one MEP on both sides of the switch fabric/forwarding part, respectively. 3) MEPs have to be set at all times when the LSP is set. On the other hand, a MIP has to be set at any time, when it is necessary or required. Note: Requirements should be reconsidered based on function, rather than location. 6. Security Considerations This document does not by itself raise any particular security considerations. 7. IANA Considerations No new IANA considerations. 8. References 8.1. Normative References Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, January 2001 8.2. Informative References Niven-Jenkins, B., Brungard, D., Betts, M., sprecher, N., Ueno, S., "MPLS-TP Requirements", RFC 5654, September 2009 Bocci, M., et al., "A Framework for MPLS in Transport Networks", draft-ietf-mpls-tp-framework-01 (work in progress), June 2009 Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-03 (work in progress), August 2009 Busi, I., Niven-Jenkins, B. , "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework-01.txt, July 2009 Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., "MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-04 (work in progress), May 2009 ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", January 2007 ITU-T Recommendation G.709/Y.1331 (03/03), "Interfaces for the Optical Transport Network (OTN)", March 2003 ITU-T Recommendation G.805 (03/00), "Generic functional architecture of transport networks", March 2000 ITU-T Recommendation G.806 (01/09), "Characteristics of transport equipment - Description methodology and generic functionality", January 2009 ITU-T Recommendation G.7710 (07/07), "Common equipment management function requirements", July 2007 9. Acknowledgments The author would like to thank all members (including MPLS-TP steering committee and the Joint Working Team) 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