MPLS Working Group Y.Koike, Ed. Internet Draft T.Hamano M.Namiki NTT Intended status: Informational Expires: January 8, 2013 July 9, 2012 A framework for Point-to-Multipoint MPLS-TP OAM in case that return paths don't exist draft-hmk-mpls-tp-p2mp-oam-framework-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 8, 2013. 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 Koike, et al. Expires January X, 2013 [Page 1] Internet-Draft MPLS-TP p2mp OAM framework July 2012 (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. Abstract The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport. This document provides texts proposal which should be discussed and included in draft-fbb-mpls-tp-p2mp-framework, particularly focusing on p2mp OAM framework in case that return paths don't exist. Other requirements of p2mp transport path such as protection will also be discussed. Note: This I-D was made based on the result of discussion in ITU-T SG15 which is described in a Liaison Statement: Request advance work on the p2mp framework in MPLS-TP (https://datatracker.ietf.org/liaison/1163/) 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 ................................................ 3 2. Conventions used in this document............................ 4 2.1. Terminology ............................................ 4 2.2. Definitions ............................................ 4 3. P2MP OAM .................................................... 4 3.1. OAM functions for proactive monitoring ..................5 3.1.1. Continuity Check and Connectivity Verification..... 5 3.1.2. Remote Defect Indication........................... 6 Koike, et al. Expires January 8, 2013 [Page 2] Internet-Draft MPLS-TP p2mp OAM framework July 2012 3.1.3. Alarm Reporting.................................... 6 3.1.4. Lock Reporting..................................... 7 3.1.5. Packet Loss Measurement............................ 7 3.1.6. Packet Delay Measurement........................... 7 3.1.7. Client Failure Indication ..........................7 3.2. OAM functions for on-demand monitoring ..................7 3.2.1. Connectivity verification ..........................7 3.2.2. Packet loss measurement............................ 8 3.2.3. Diagnostic tests................................... 9 3.2.4. Route Tracing...................................... 9 3.2.5. Packet delay measurement........................... 9 3.3. OAM functions for administration control................ 9 3.3.1. Lock Instruct...................................... 9 4. Security Considerations...................................... 9 5. IANA Considerations ......................................... 9 6. References .................................................. 9 6.1. Normative References.................................... 9 6.2. Informative References................................. 10 7. Acknowledgments ............................................ 10 1. Introduction The demand for P2MP traffic is expected to increase due to the increase in new services such as IP-TV and video distribution services. Moreover considering the global trend to improve energy efficiency, a P2MP transport function in MPLS-TP could be one of the solutions to achieve this goal from the perspective of efficient use of network resources. RFC5654[1] defines the following requirements which are specific to P2MP. - Traffic-engineered point-to-multipoint (P2MP) transport paths.(item 6) - Unidirectional point-to-multipoint transport paths (item 8) - Being capable of using P2MP server (sub)layer capabilities when supporting P2MP MPLS-TP transport paths(item 40) - The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (i.e. unidirectional P2MP) including configuration of protection functions and any associated maintenance functions.(item 50) Unidirectional 1+1 protection for P2MP connectivity (item 65 C) - Unidirectional 1:n protection for P2MP connectivity(item 67 B) - MPLS-TP recovery in a ring MUST protect unidirectional P2MP transport paths.(item 95) Koike, et al. Expires January 8, 2013 [Page 3] Internet-Draft MPLS-TP p2mp OAM framework July 2012 RFC5860[2] defines MPLS-TP OAM requirements including those for unidirectional P2MP transport paths. In case of unidirectional P2MP transport path, two cased are assumed as per section 3.3 of RFC6371[3]. One is when an "out-of-band" return path exists and it is used and the other is when any return path does not exist or is not use. Missing OAM requirements which are necessary in P2MP transport networks are those in the latter case. In I-D[4], Operations, Administration and Maintenance (OAM) is planned to be specified in clause 4. According to the editor's note, this section will contain a summary of point-to-multipoint OAM as described in RFC6371[3] that defines the overall OAM architecture for MPLS-TP. However, considering the missing OAM requirements in case that a return paths don't exist, the most appropriate place where they could be added is I-D[4]. Therefore, this draft intends to provide texts which should be included in OAM section and network management section of the I-D[4]. 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]. 2.1. Terminology LSP Label Switched Path 2.2. Definitions None 3. P2MP OAM Note: It is proposed that this section be incorporated in section 4 of I-D[4]. Unidirectional P2MP is supported in MPLS-TP. This means that "in- band" return path is out of scope. In this section, only two cases, Koike, et al. Expires January 8, 2013 [Page 4] Internet-Draft MPLS-TP p2mp OAM framework July 2012 with out-band return path and without return path, are considered and requirements should be independently specified, if necessary. P2MP considerations are described in section 3.7 of RFC6371. The RFC has already described some requirements with out-band return path(s). On the other hand, even if there is no return path, parts of OAM requirements in RFC5860 could be met by supporting management interface through which EMS/NMS can retrieve the received OAM packets. Note: In the following sections, basically additional requirements are described function-by-function, which haven't been covered or clarified in RFC5860[2] and RFC6371[3] have particularly focused on the case that return paths doen't exist. 3.1. OAM functions for proactive monitoring 3.1.1. Continuity Check and Connectivity Verification Continuity Check function enable one or more leaf MEPs on unidirectional P2MP transport path to monitor the continuity of OAM packets from root MEP and detect one or more loss of continuity(LOC) defect between the root MEP and the leaf MEPs. Connectivity Verification function enables one or more leaf MEPs on P2MP transport path to monitor the connectivity of OAM packets from a specific root MEP and detect an unexpected connectivity defect between two MEGs(two P2MP transport paths) Continuity Check and Connectivity Verification MUST be supported in case that a return path in a unidirectional P2MP transport path doesn't exist. This requirement is already included in section 2.2.3 of RFC5860[2]. As described in RFC6371[3], CC-V OAM packets are used for P2MP transport path. Defect detection mechanisms in P2MP transport paths are the same as those of P2MP transport path specified in section 5.1 of RFC6371. That is, loss of continuity defect, mis-connectivity defect, period mis-configuration defect and unexpected encapsulation defect. Entry criteria and exist criteria are also the same as those of P2MP transport path in RFC6371[3]. Moreover, consequent actions of unidirectional P2MP transport path are also covered in section 5.1.2 of the RFC[3] Regarding configuration consideration, following additional requirements on unidirectional P2MP transport path in case that the return paths don't exist. Koike, et al. Expires January 8, 2013 [Page 5] Internet-Draft MPLS-TP p2mp OAM framework July 2012 1. EMS/NMS should provide a tool to manually configure consistent values on each piece of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) to a root-MEP and all the related leaf-MEPs in a MEG of a P2MP transport path. 2. Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for E-LSPs, transmission rate) between a root MEP and any leaf-MEP at which proactive monitoring is enabled, should be detected as a configuration mis-match alarm by parsing received CC-VOAM packets. 3. Mis-matches of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) between a leaf MEP and any other leaf-MEP, at which proactive monitoring are enabled, may be detected through configuration management process of EMS/NMS as a configuration mis-match alarm without receiving OAM packets from a source MEP. 4. Configuration information mis-match alarms described in 4 and 5 may be supported in case that a proactive monitoring is not enabled in order to check those mis-matches before monitoring functions are enabled. 5. Enabling or disabling configuration mis-matich alarms must be able to be configured at each leaf-MEP independently. 3.1.2. Remote Defect Indication This OAM function is not available on P2MP transport path in case that return paths don't exist, because this function is implemented only on the return path. 3.1.3. Alarm Reporting Alarm Reporting functions MUST be supported in case that a return path in a unidirectional P2MP transport paths don't exist. This is already included in section 2.2.8 of RFC5860[2]. 6. EMS/NMS should provide a tool to manually configure consistent values on "hold-off intervals prior to asserting an alarm to the management system" and AIS transmission period to all the leaf- MEPs in a MEG of a P2MP transport path. 7. Mis-matches of configuration information (hold-off interval and AIS transmission period) between a root MEP and any leaf-MEP at which alarm reporting is enabled, should be detected as a configuration mis-match alarm by parsing received AIS OAM packets. Koike, et al. Expires January 8, 2013 [Page 6] Internet-Draft MPLS-TP p2mp OAM framework July 2012 8. Mis-matches of configuration information (hold-off interval and AIS transmission period) between a leaf MEP and any other leaf-MEP, at which alarm reporting is enabled, may be detected through configuration management process of EMS/NMS as a configuration mis-match alarm without receiving OAM packets from a source MEP. 9. Configuration information mis-match alarms described in 4 and 5 may be supported in case that a alarm reporting is not enabled in order to check those mis-matches before monitoring functions are enabled. 10.Enabling or disabling configuration information mis-matich alarms must be able to be configured at each leaf-MEP independently. 3.1.4. Lock Reporting FFS 3.1.5. Packet Loss Measurement FFS 3.1.6. Packet Delay Measurement FFS 3.1.7. Client Failure Indication FFS 3.2. OAM functions for on-demand monitoring 3.2.1. Connectivity verification Connectivity Verification function enables one or more leaf MEPs on P2MP transport path to monitor the connectivity of OAM packets from a specific root MEP and detect an unexpected connectivity defect between two MEGs(two P2MP transport paths) 11.Connectivity verification functions MUST be supported in case that return paths in a unidirectional P2MP transport path don't exist. Koike, et al. Expires January 8, 2013 [Page 7] Internet-Draft MPLS-TP p2mp OAM framework July 2012 As described in RFC6371[3], CC-V OAM packets are used for P2MP transport path. Defect detection mechanisms in P2MP transport paths are the same as those of P2MP transport path specified in section 5.1 of RFC6371. That is, loss of continuity defect, mis-connectivity defect, period mis-configuration defect and unexpected encapsulation defect. Entry criteria and exist criteria are also the same as those of P2MP transport path in RFC6371[3]. Moreover, consequent actions of unidirectional P2MP transport path are also covered in section 5.1.2 of the RFC[3] Regarding configuration consideration, following additional requirements on unidirectional P2MP transport path in case that return path doesn't exist. 12.EMS/NMS should provide a tool to manually configure consistent values on each piece of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) to a root-MEP and all the related leaf-MEPs in a MEG of a P2MP transport path. 13.Mis-matches of configuration information (MEG-ID, MEP-ID, PHB for E-LSPs, transmission rate) between a root MEP and any leaf-MEP at which proactive monitoring is enabled, should be detected as a configuration mis-match alarm by parsing received CC-VOAM packets. 14.Mis-matches of configuration information (MEG-ID, MEP-ID, list of the other MEPs in the MEG, PHB for E-LSPs, transmission rate) between a leaf MEP and any other leaf-MEP, at which proactive monitoring are enabled, may be detected through configuration management process of EMS/NMS as a configuration mis-match alarm without receiving OAM packets from a source MEP. 15.Configuration information mis-match alarms described in 4 and 5 may be supported in case that a proactive monitoring is not enabled in order to check those mis-matches before monitoring functions are enabled. 16.Enabling or disabling configuration mis-matich alarms must be able to be configured at each leaf-MEP independently. 3.2.2. Packet loss measurement FFS Koike, et al. Expires January 8, 2013 [Page 8] Internet-Draft MPLS-TP p2mp OAM framework July 2012 3.2.3. Diagnostic tests 17.Diagnostic test functions MUST be supported in case that a return path in a unidirectional P2MP transport path doesn't exist. Other requirements are ffs. 3.2.4. Route Tracing 18.Route tracing function MUST be supported in case that a return path in a unidirectional P2MP transport path doesn't exist. Other requirements are ffs. 3.2.5. Packet delay measurement FFS 3.3. OAM functions for administration control 3.3.1. Lock Instruct FFS. 4. Security Considerations This document does not by itself raise any particular security considerations. 5. IANA Considerations There are no IANA actions required by this draft. 6. References 6.1. Normative References [1] Niven-Jenkins, B., et all, "Requirements of an MPLS Transport Profile", RFC5654, September 2009 [2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", RFC5860, May 2010 Koike, et al. Expires January 8, 2013 [Page 9] Internet-Draft MPLS-TP p2mp OAM framework July 2012 [3] Busi, I., Dave, A. , "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks ", RFC6371, September 2011 [4] Frost, Dan.,et all, "A Framework for Point-to-Multipoint MPLS in Transport Networks", draft-fbb-mpls-tp-p2mp-framework-04, June 2012 6.2. Informative References None 7. 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. This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Takafumi Hamano NTT hamano.takafumi@lab.ntt.co.jp Masatoshi Namiki NTT namiki.masatoshi@lab.ntt.co.jp Yoshinori Koike NTT Email: koike.yoshinori@lab.ntt.co.jp Koike, et al. Expires January 8, 2013 [Page 10]