Network Working Group A. Farrel Internet-Draft Juniper Networks Intended status: Informational H. Endo Expires: May 16, 2013 Hitachi, Ltd. R. Winter NEC Y. Koike NTT M. Paul Deutsche Telekom November 12, 2012 Handling MPLS-TP OAM Packets Targeted at Internal MIPs draft-ietf-mpls-tp-mip-mep-map-04 Abstract The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the forwarding engine, and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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 Farrel, et al. Expires May 16, 2013 [Page 1] Internet-Draft Internal MIP Handling November 2012 material or to cite them other than as "work in progress." This Internet-Draft will expire on May 16, 2013. Copyright Notice Copyright (c) 2012 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. 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. Farrel, et al. Expires May 16, 2013 [Page 2] Internet-Draft Internal MIP Handling November 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Summary of the Problem Statement . . . . . . . . . . . . . . . 5 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Rejected Partial Solution . . . . . . . . . . . . . . . . 10 6. Per-Interface MIP Message Handling . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Farrel, et al. Expires May 16, 2013 [Page 3] Internet-Draft Internal MIP Handling November 2012 1. Introduction The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM Framework, [RFC6371]) distinguishes two configurations for Maintenance Entity Group Intermediate Points (MIPs) on a node. It defines per-node MIPs and per-interface MIPs, where a per-node MIP is a single MIP per node in an unspecified location within the node and per-interface MIPs are two (or more) MIPs per node on both sides of the forwarding engine. In-band OAM messages are sent using the Generic Associated Channel (G-ACh) [RFC5586]. OAM messages for the transit points of pseudowires (PWs) or Label Switched Paths (LSPs) are delivered using the expiration of the MPLS shim header time-to-live (TTL) field. OAM messages for the end points of PWs and LSPs are simply delivered as normal. OAM messages delivered to end points or transit points are distinguished from other (data) packets so that they can be processed as OAM. In LSPs, the mechanism used is the presence of the Generic Associated Channel Label (GAL) in the Label Stack Entry (LSE) under the top LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW Associated Channel Header (PWACH) [RFC4385] or the presence of a GAL [RFC6423]. In case multiple MIPs are present on a single node, these mechanisms alone provide no way to address one particular MIP out of the set of MIPs. This document describes a way of forming OAM messages so that they can be targeted at incoming MIPs and outgoing MIPs, forwarded correctly through the forwarding engine, and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF)/International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architecture to support the capabilities and functionalities of a packet transport network. Note that the acronym "OAM" is used in conformance with [RFC6291]. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Farrel, et al. Expires May 16, 2013 [Page 4] Internet-Draft Internal MIP Handling November 2012 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology In this document we use the term in-MIP (incoming MIP) to refer to the MIP which processes OAM messages before they pass through the forwarding engine of a node. An out-MIP (outgoing MIP) processes OAM messages after they have passed the forwarding engine of the node. The two together are referred to as internal MIPs. 4. Summary of the Problem Statement Figure 1 shows an abstract functional representation of an MPLS-TP node. It is decomposed as an incoming interface, a forwarding engine (FW), and an outgoing interface. As per the discussion in [RFC6371], MIPs may be placed in each of the functional interface components. ------------------------ |----- -----| | MIP | | MIP | | | ---- | | ----->-| In |->-| FW |->-| Out |->---- | i/f | ---- | i/f | |----- -----| ------------------------ Figure 1: Abstract Functional Representation of an MPLS-TP Node Several distinct OAM functions are required within this architectural model for both PWs and LSPs such as: o CV between a MEP and a MIP o traceroute over an MPLS-TP LSP and/or an MPLS-TP PW containing MIPs o data-plane loopback configuration at a MIP o diagnostic tests The MIPs in these OAM functions may equally be the MIPs at the incoming or outgoing interfaces. Per-interface MIPs have the advantage that they enable a more accurate localization and identification of faults and diagnostic test. In particular, the identification of whether a problem is located between nodes or on a particular node and where on that node is greatly enhanced. For obvious reasons, it is important to narrow Farrel, et al. Expires May 16, 2013 [Page 5] Internet-Draft Internal MIP Handling November 2012 the cause of a fault down quickly to initiate a timely, and well- directed maintenance action to resume normal network operation. The following two figures illustrate the fundamental difference of using per-node and per-interface MEPs and MIPs for OAM. Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons of exposition we pick a location for the MIPs on the nodes but the standard does not mandate the exact location for the per-node model. Figure 3 on the other hand shows the same basic network but for OAM operations per-interface maintenance points are configured. Customer| Operator's administrative | Customer Domain | Domain | Domain ------> |<--------------------------------------->| <------ CE1 | PE1 P1 PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD LSP | o-------------------------- > | | V-------------*-------------V | | MEP1 MIP1 MEP2 | BWD LSP | <---------------------------o | | V-------------*-------------V | | MEP1' MIP1' MEP2'| (S1)<============> (S2)<==========================> Figure 2: Example of OAM relying on per-node MIPs and MEPs To illustrate the difference between these two modes of operation, we use fault detection as an example. Consider the case where the client traffic between CE1 and CE2 experiences a fault. Also assume that an on-demand CV test between PE1 and PE2 was successful. The scenario in Figure 2 therefore leaves the forwarding engine (FW) of PE2, the out-going interface of PE2, the transmission line between PE2 and CE2 or CE2 itself as a potential location of the fault as on- demand CV can only be performed on segment S2. The per-interface model in Figure 3 allows more fine-grained OAM operations to be performed. At first, CV on segment S'4 and in addition CV on segment S'5 can help to rule out e.g. the forwarding Farrel, et al. Expires May 16, 2013 [Page 6] Internet-Draft Internal MIP Handling November 2012 engine of PE2. This is of course only a single example, and other OAM functions and scenarios are trivially conceivable. The basic message is that with the per-interface OAM model, an operator can configure smaller segments on a transport path to which OAM operations apply. This enables a more fine-grained scoping of OAM operations such as fault localization and performance monitoring which gives operators better information to deal with adverse networking conditions. Customer Operator's administrative Customer Domain Domain Domain ------->|<--------------------------------------->|<------ CE1 | PE1 P1 PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD LSP | o-----------------------------------> | | V-------*------*------*-----*-------V | | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| | | BWD LSP | <-----------------------------------o | | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| (S'1)<======> (S'2)<=============> (S'3)<====================> (S'4)<==========================> (S'5)<==================================> Figure 3: Example of OAM relying on per-interface MIPs and MEPs 5. Overview In-band OAM messages are sent using the G-ACh [RFC5586] for MPLS-TP LSPs and MPLS-TP PWs, respectively. OAM messages for the transit points of PWs or LSPs are delivered using the expiration of the time- to-live (TTL) field in the top LSE of the MPLS packet header. OAM messages for the end points of PWs and LSPs are simply delivered as normal. OAM messages delivered to end points or transit points are Farrel, et al. Expires May 16, 2013 [Page 7] Internet-Draft Internal MIP Handling November 2012 distinguished from other (data) packets so that they can be processed as OAM. In LSPs, the mechanism used is the presence of the Generic Associated Channel Label (GAL) in the LSE under the top LSE [RFC5586]. In PWs, the mechanism used is the presence of the PW Associated Channel Header [RFC4385] or the presence of a GAL [RFC6423]. Any solution for sending OAM messages to the in and out-MIPs must fit within these existing models of handling OAM. Additionally, many MPLS-TP nodes contain an optimization such that all queuing and the forwarding function is performed at the incoming interface. The abstract functional representation of such a node is shown in Figure 4. As shown in the figure, the outgoing interfaces are minimal and for this reason it may not be possible to include MIP functions on those interfaces. This is in particular the case for existing deployed implementations. Any solution that attempts to send OAM messages to the outgoing interface of an MPLS-TP node must not cause any problems when such implementations are present. ------------------ |------------ | | MIP | | | ---- | | ----->-| In | FW | |-->--|->--- | i/f ---- | | |------------ | ------------------ Figure 4: Abstract Functional Representation of an Optimized MPLS-TP Node Lastly, OAM must operate on MPLS-TP nodes that are branch points on point-to-multipoint (P2MP) trees. That means that it must be possible to target individual outgoing MIPs as well as all outgoing MIPs in the abstract functional representation shown in Figure 5, as well as to handle the optimized P2MP node as shown in Figure 6. Farrel, et al. Expires May 16, 2013 [Page 8] Internet-Draft Internal MIP Handling November 2012 -------------------------- | -----| | | MIP | | ->-| |->---- | | | Out | | | | i/f | | | -----| |----- | -----| | MIP | ---- | | MIP | | | | |- | | ----->-| In |->-| FW |--->-| Out |->---- | i/f | | |- | i/f | |----- ---- | -----| | | -----| | | | MIP | | | | | | ->-| Out |->---- | | i/f | | -----| -------------------------- Figure 5: Abstract Functional Representation of an MPLS-TP Node Supporting P2MP ------------------ | ->-|->---- | | | |------------ | | | | | | | MIP ---- | | | | | | |- | ----->-| In | FW | |--->-|->---- | i/f | | |- | | ---- | | | | | | | |------------ | | | | | | ->-|->---- ------------------ Figure 6: Abstract Functional Representation of an Optimized MPLS-TP Node Supporting P2MP In summary, the solution for OAM message delivery must support the following features: Farrel, et al. Expires May 16, 2013 [Page 9] Internet-Draft Internal MIP Handling November 2012 o Forwarding of OAM packets exactly as data packets. o Delivery of OAM messages to the correct MPLS-TP node. o Delivery of OAM instructions to the correct MIP within an MPLS-TP node. o Packet inspection at the incoming and outgoing interfaces must be minimized. Note that although this issue appears superficially to be an implementation matter local to an individual node, the format of the message needs to be standardised so that: o A MEP can correctly target the outgoing MIP of a specific MPLS-TP node. o A node can correctly filter out any OAM messages that were intended for its upstream neighbor's outgoing MIP, but which were not handled there because the upstream neighbor is an optimized implementation. Note that the last bullet point describes a safety net and an implementation should avoid that this situation ever arises. 5.1. Rejected Partial Solution A rejected solution is depicted in Figure 7. All data and non-local OAM is handled as normal. Local OAM is intercepted at the incoming interface and delivered to the MIP at the incoming interface. If the OAM is intended for the incoming MIP it is handled there with no issue. If the OAM is intended for the outgoing MIP it is forwarded to that MIP using some internal messaging system that is implementation-specific. ------------------------ |----- -----| local OAM ----->-| MIP |----->------| MIP | | | ---- | | data =====>=| In |=>=| FW |=>=| Out |=>==== data non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM |----- ---- -----| ------------------------ Figure 7: OAM Control Message Delivery Bypassing the Forwarding Engine This solution is fully functional for the incoming MIP. It also supports control of data loopback for the outgoing MIP, and can adequately perform some OAM features such as interface identity reporting at the outgoing MIP. Farrel, et al. Expires May 16, 2013 [Page 10] Internet-Draft Internal MIP Handling November 2012 However, because the OAM message is not forwarded through the forwarding engine, this solution cannot correctly perform OAM loopback, connectivity verification, LSP tracing, or performance measurement. 6. Per-Interface MIP Message Handling The preferred solution to per-interface MIP message handling is presented in this section. The appendix of this document contains a few solutions that the authors have discarded which have been left in the document for informational purposes. Per-interface MIP addressing should not require changes to existing OAM solutions. Therefore, identification information that specific OAM mechanisms already contain should be (re-)used to address the MIPs on a node. Upcoming OAM solutions therefore need to individually make sure that enough of that information is present to support the per-interface model. In particular, the MIP identifiers as described in [RFC6370] or [I-D.ietf-mpls-tp-itu-t-identifiers] need to be present in OAM messages. [RFC6370] and [I-D.ietf-mpls-tp-itu-t-identifiers] define formats that support the per-interface model which is sufficient for this purpose. In addition, some constraints must be agreed on. Regarding the features we required earlier from a solution this translates to: o Feature 1: "Forwarding of OAM packets exactly as data packets" * Using existing identification information in OAM messages for internal-MIP addressing has no implications on the way data packets and non-local OAM packets are handled as the label stack is not altered for the purpose of MIP addressing. Also the TTL processing remains untouched. This means that the TTL will expire on the ingress. o Feature 2: "Delivery of OAM messages to the correct MPLS-TP node" * The node itself is addresses using TTL expiry. Therefore, per- interface MIP addressing does not alter node addressing. o Feature 3: "Delivery of OAM instructions to the correct MIP within an MPLS-TP node" * The identification information containted in the OAM packet is used to tell whether the packet is for the in-MIP or the out- MIP. o Feature 4: "Packet inspection at the incoming and outgoing interfaces must be minimized" * Additional packet inspection compared to the per-node case is inevitably needed. The identification information indside the OAM message needs to be considered in order to deliver the Farrel, et al. Expires May 16, 2013 [Page 11] Internet-Draft Internal MIP Handling November 2012 packet to the correct MIP. The above illustrates how in principle per-MIP addressing operates. Another issue of concern was the correct filtering of OAM messages at a downstream node, that were intended for an upstream node's outgoing MIP. Since OAM messages expire on the ingress, the legacy upstream neighbor will actually process the packet. Since the identification information is not correct, the node should discard that packet. Leakage should therefore not occur. There might be certain cases where MIP identifiers are not know a priori to other nodes in the network, e.g. in scenarios with static MPLS-TP LSP and PWs. A head end performing route tracing e.g. would have no means to address MIPs in this model. In case OAM solutions expect MIPs to anwser without prior knowledge of the identifier, it is expected that these OAM solutions specify the MIP behaviour in these cases. This could involve unconditional answers from MIPs for certain OAM messages or reserved MIP address for certain OAM tools but the specification of this behaviour is outside the scope of this document. 7. Security Considerations OAM security is discussed in [RFC6371] and security aspects specific to MPLS-TP in general are outlined in [I-D.ietf-mpls-tp-security-framework]. OAM can provide useful information for detecting and tracing security attacks. OAM can also be used to illicitly gather information or for denial of service attacks and other types of attack. Implementations therefore are required to offer security mechanisms for OAM. Deployments are strongly advised to use such mechanisms. Mixing of per-node and per-interface OAM on a single node is not advised as OAM message leakage could be the result. 8. IANA Considerations This revision of this document does not make any requests of IANA. 9. Acknowledgments The authors gratefully acknowledge the substantial contributions of Farrel, et al. Expires May 16, 2013 [Page 12] Internet-Draft Internal MIP Handling November 2012 Zhenlong Cui. We would also like to thank Eric Gray and Sami Boutros for interesting input to this document through discussions. 10. References 10.1. Normative References [I-D.ietf-mpls-tp-itu-t-identifiers] Winter, R., Gray, E., Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", draft-ietf-mpls-tp-itu-t-identifiers-06 (work in progress), November 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC6423] Li, H., Martini, L., He, J., and F. Huang, "Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP)", RFC 6423, November 2011. 10.2. Informative References [I-D.ietf-mpls-tp-security-framework] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS-TP Security Framework", draft-ietf-mpls-tp-security-framework-05 (work in progress), October 2012. [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011. Farrel, et al. Expires May 16, 2013 [Page 13] Internet-Draft Internal MIP Handling November 2012 Authors' Addresses Adrian Farrel Juniper Networks Email: adrian@olddog.co.uk Hideki Endo Hitachi, Ltd. Email: hideki.endo.es@hitachi.com Rolf Winter NEC Email: rolf.winter@neclab.eu Yoshinori Koike NTT Email: koike.yoshinori@lab.ntt.co.jp Manuel Paul Deutsche Telekom Email: Manuel.Paul@telekom.de Farrel, et al. Expires May 16, 2013 [Page 14]