Network Working Group A. Farrel Internet-Draft Huawei Technologies Intended status: Standards Track Expires: May 29, 2010 November 29, 2009 Handling MPLS-TP OAM Packets Targeted at Internal MIPs draft-farrel-mpls-tp-mip-mep-map-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 May 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. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 1] Internet-Draft Internal MIP Handling November 2009 Abstract The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance 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 incoming MIPs and outgoing MIPs, forwarded correctly through the "switch fabric", and handled efficiently in optimized node implementations where there is no distinction between the incoming and outgoing MIP. The material in this document is provided for discussion within the MPLS-TP community in the expectation that this idea or some similar mechanism will be subsumed into a more general MPLS-TP OAM document. 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. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 2] Internet-Draft Internal MIP Handling November 2009 1. Introduction The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) (the MPLS-TP OAM Framework, [OAM-FWK]) describes how Maintenance Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. OAM messages are formed and delivered using the expiration of the MPLS shim header time-to-live (TTL) field, and the presence of the Generic Associated Channel Label (GAL) in the label stack under the top label [RFC5586]. This means that all OAM messages intended for any MIP on a node are delivered to the MIP at the incoming interface. 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 "switch fabric", and handled efficiently in optimized node implementations where there is no distinction between the incoming and outgoing MIP. The material in this document is provided for discussion within the MPLS-TP community in the expectation that this idea or some similar mechanism will be subsumed into a more general MPLS-TP OAM document. 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. Note that the acronym "OAM" is used in conformance with [OAM-SOUP]. 2. Summary of Problem Statement Figure 1 shows an abstract functional represenation of an MPLS-TP node. It is decomposed as an incoming interface, a cross-connect (XC), and an outgoing interface. As per the discussion in [OAM-FWK], MIPs may be placed in each of the functional interace components. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 3] Internet-Draft Internal MIP Handling November 2009 ------------------------ | | |----- -----| | MIP | | MIP | | | ---- | | ----->-| In |->-| XC |->-| 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: - OAM loopback at a MIP - data loopback at a MIP - OAM control at a MIP - measurement at a MIP The MIPs in these OAM functions may equally be the MIPs at the input or output interfaces. The way that OAM messages are delivered to an MPLS-TP node is through the expirey of the TTL in the top-of-stack shim header on the MPLS packet. The top label in the stack is always the same as would be used for data on the same label switched path (LSP) so that OAM is handled in exactly the same way as data as it travels through the network. The second label on the stack is the GAL so that OAM can be distinguished from data. Any solution for sending OAM to the in and out MIPs must fit within this existing model of handling OAM. Additionally, many MPLS-TP nodes contain an optimization such that all queuing and forwarding function is performed at the incoming interface. The abstract functional representation of such a node is shown in Figure 2. As shown in the figure, the outgoing interfaces are minimal and for this reason it may not be possible to include MIP function on those interfaces. This is particularly the case for existing deployed implmentations. Any solution that attempts to send OAM to the outgoing interface of an MPLS-TP node must not cause any problems when such implementations are present. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 4] Internet-Draft Internal MIP Handling November 2009 ------------------ | | |------------ | | MIP | | | ---- | | ----->-| In | XC | |-->--|->--- | i/f ---- | | |------------ | | | ------------------ Figure 2 : 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). That means that it must possible to target individual outgoing MIPs as well as all outgoing MIPs in the abstract fucntional representation shown in Figure 3, as well as to handle the optimized P2MP node as shown in Figure 4. -------------------------- | | | -----| | | MIP | | ->-| |->---- | | | Out | | | | i/f | | | -----| |----- | -----| | MIP | ---- | | MIP | | | | |- | | ----->-| In |->-| XC |--->-| Out |->---- | i/f | | |- | i/f | |----- ---- | -----| | | -----| | | | MIP | | | | | | ->-| Out |->---- | | i/f | | -----| -------------------------- Figure 3 : Abstract Functional Representation of an MPLS-TP Node Supporting P2MP Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 5] Internet-Draft Internal MIP Handling November 2009 ------------------ | | | ->-|->---- | | | |------------ | | | | | | | MIP ---- | | | | | | |- | ----->-| In | XC | |--->-|->---- | i/f | | |- | | ---- | | | | | | | |------------ | | | | | | ->-|->---- | | ------------------ Figure 4 : Abstract Functional Representation of an Optimized MPLS-TP Node Supporting P2MP In summary, the solution for OAM message delivery must support the following features: - Forwarding of OAM packets exactly as data packets. - Delivery of OAM messages to the correct MPLS-TP node. - Direction of OAM instructions to the correct MIP within an MPLS-TP node. - Packet inspection at the outgoing interface must be minimised. 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: - An upstream MEP can correctly target the outgoing MIP of a specific MPLS-TP node. - A downstream node can correctly filter out any OAM messages that were intended for its upstream negihbor's outgoing MIP, but which were not handled there because the upstream neighbor is an optimized implmentation. 2.1. Rejected Partial Solution A reject solution is depicted in Figure 5. 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 Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 6] Internet-Draft Internal MIP Handling November 2009 issues. 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 |=>=| XC |=>=| Out |=>==== data non-local OAM ~~~~~>~| i/f |~>~| |~>~| i/f |~>~~~~ non-local OAM |----- ---- -----| | | ------------------------ Figure 5 : OAM Control Message Delivery Bypassing the Switching Fabric 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. However, because the the OAM message is not forwarded through the switch fabric, this solution cannot correctly perform OAM loopback, connectivity verification, LSP tracing, or performance measurement. 3. Proposed Solution Figure 6 shows a proposed message format for handling the different cases described in Section 2. The subsections that follow describe the processing rules for each case. Note that this proposed solution requires a packet to be sent with TTL=0. An alternative approach is described in Section 4. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 7] Internet-Draft Internal MIP Handling November 2009 ------------------------ |----- -----| | MIP | ---- | MIP | ----->-| In |->-| XC |->-| Out |->---- | i/f | ---- | i/f | |----- -----| ------------------------ ----------------- ------------------- data | Label=x | TTL=n |----------------->| Label=y | TTL=n-1 | ----------------- ------------------- ----------------- ----------------- non-local| Label=x | TTL=2 |----------------->| Label=y | TTL=1 | OAM|-----------------| |-----------------| | GAL | | | GAL | | |-----------------| |-----------------| | ACH Type = OAM | | ACH Type = OAM | ----------------- ----------------- ----------------- in-MIP| Label=x | TTL=1 |--- OAM|-----------------| | | GAL | | | |-----------------| | | ACH Type = OAM | | ----------------- | <------ ----------------- ----------------- out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=0 |--- OAM|-----------------| |-----------------| | | GAL | | | GAL | | | |-----------------| |-----------------| | | ACH Type = OAM | | ACH Type = OAM | | |-----------------| |-----------------| | | ACH TLV=out-MIP | | ACH TLV=out-MIP | | ----------------- ----------------- | <------- ----------------- ----------------- out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=0 |---> not |-----------------| |-----------------| supported| GAL | | | GAL | | |-----------------| |-----------------| | ACH Type = OAM | | ACH Type = OAM | |-----------------| |-----------------| | ACH TLV=out-MIP | | ACH TLV=out-MIP | ----------------- ----------------- Figure 6 : Packet Formats for In and Out MIP OAM Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 8] Internet-Draft Internal MIP Handling November 2009 3.1. Processing of Data and Non-Local OAM The message formats and processing rules for data and non-local OAM are not changed by this proposal. The top-of-stack label is swapped and the top-of-stack TTL is decremented. 3.2. Processing of In-MIP OAM The message formats and processing rules for in-MIP OAM are not changed by this proposal. The top-of-stack TTL is decremented and expires. The packet is examined further and the GAL is discovered. Further inspection of the packet reveals the ACH type and the packet is delivered to the in-MIP. Note that an ACH TLV could be included to identify the in-MIP (as in Section 3.3), but this is not required since the absence of such a TLV could be inferred to indicate the in-MIP as the target. 3.3. Processing of Out-MIP OAM OAM messages intended for the out-MIP on a node are initially intercepted as any OAM message targeted at any MIP on the node. That is, the TTL expires, the GAL is found, and the ACH indicates that the message is OAM. An ACH TLV is included to indicate that the OAM is targeted at the outgoing MIP. The incoming interface must forward the OAM message through the switch fabric as if it was data. So, the packet is passed on unchanged except that the TTL has been decremented and expired. This enables the outgoing interface to inspect only the TTL field of the outgoing packet to know that it should intercept the packet and not send it out to the next MPLS-TP node. Further inspection of the packet at the outgoing interface will reveal the GAL, the ACH type, and the ACH TLV. 3.4. Processing at P2MP Branch Nodes At P2MP branch nodes, the OAM messages may be targeted at one or all outgoing interfaces. It should be noted that packet replication is a function of the switch fabric so that any OAM message forwarded by the incoming interface will be passed to all outgoing interfaces. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 9] Internet-Draft Internal MIP Handling November 2009 The procedures operate as described in section 3.3. The outgoing interfaces are able to determine whether the OAM message is intended for the local MIP by examining a MIP identifier carried in an ACH TLV. OAM messages received at outgoing interfaces but not intended for the local MIP are silently dropped. 3.5. Processing When There is No Out-MIP When there is no out-MIP supported on an optimized switch implementation there are two options. 1. The OAM message is intercepted at the incoming interface as described in Section 3.3, but the incoming interface is aware that it forms part of an optimized implementation that does not support an out-MIP. It can discard the received OAM message, or respond to indicate that the out-MIP is not supported. 2. The OAM message is intercepted and forwarded as described in Section 3.3. Since there is no out-MIP, the message is forwarded out of the outgoing interface to the next downstream MPLS-TP node as shown at the bottom of Figure 6. This means that the packet will be received at the downstream node carrying a TTL that has already expired (before it is decremented at the downstream node) indicating that the packet should be silently discarded. If the packet is examined, it will reveal a GAL, an ACH type indicating OAM, and an ACH TLV identifying a MIP that is not local to the downstream node. This will result in the packet being dropped or a negative response being sent. 4. Enhanced Proposed Solution The mechanisms described in Section 3 can be enhanced by the use of a new reserved label, the Outgoin Mip Lable (OML). This label is substituted for the GAL when an OAM message intended for an outgoing MIP is processed at an incoming interface as shown in Figure 7. The advantage of this mechanism is that the outgoing interface of the local node and the incoming interface of the downstream node have someting more substantial to check than just the TTL value being zero. In fact, it allows the mesage to be sent with TTL of one so that the rules for sending packets with zero TTL are not compromised. The disadvantage is that a further reserved label is used. Note that an option is to allocate the OML as a purely local matter. Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 10] Internet-Draft Internal MIP Handling November 2009 That means that the implementation allocates the value of the OML from its local label space and assigns the meaning as described. This approach, however, would be risky if the packet escaped and was processed by the downstream node. ----------------- ----------------- out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=1 |--- OAM|-----------------| |-----------------| | | GAL | | | OML | | | |-----------------| |-----------------| | | ACH TLV=out-MIP | | ACH TLV=out-MIP | | ----------------- ----------------- | <------- ----------------- ----------------- out-MIP| Label=x | TTL=1 |--------------->| Label=y | TTL=1 |---> not |-----------------| |-----------------| supported| GAL | | | OML | | |-----------------| |-----------------| | ACH TLV=out-MIP | | ACH TLV=out-MIP | ----------------- ----------------- Figure 7 : Use of the Outgoing MIP Label 5. Security Considerations OAM security is discussed in [OAM-FWK] and [OAM-SEC]. 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. Implementations are required to offer security mechanisms for OAM. Deployments are strongly advised to use suh mechanisms. 6. IANA Considerations This revision of this document does not make any requests of IANA. If the solution described in Section 4 is adopted, a request will be made to IANA for the allocation of a new reserved label. 7. Acknowledgment TBD Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 11] Internet-Draft Internal MIP Handling November 2009 8. References 8.1. Normative References [RFC5586] Bocci, M., Vigoureux, M., and Bryant, S., "MPLS Generic Associated Channel", RFC 5586, June 2009. 8.2. Informative References [OAM-FWK] Busi, I., Niven-Jenkins, B. and Allan, D., "MPLS-TP OAM Framework ", draft-ietf-mpls-tp-oam-framework, work in progress. [OAM-SOUP] Andersson, L., Betts, M., van Helvoort, H., Bonica, R., and Romascanu, D., "The OAM Acronym Soup", draft-ietf- opsawg-mpls-tp-oam-def, work in progress. [OAM-SEC] Manral, V., "MPLS-TP General Authentication TLV for G-ACH", draft-manral-mpls-tp-oam-security-tlv, work in progress. Author's Address Adrian Farrel Huawei Technologies Email: adrian.farrel@huawei.com Farrel draft-farrel-mpls-tp-mip-mep-map-00.txt [Page 12]