Network Working GroupInternet Engineering Task Force (IETF) A. FarrelInternet-DraftRequest for Comments: 7054 Juniper NetworksIntended status:Category: Informational H. EndoExpires: March 3, 2014ISSN: 2070-1721 Hitachi, Ltd. R. Winter NEC Y. Koike NTT M. Paul Deutsche TelekomAugust 30,November 2013Per-Interface MIPAddressing Requirements and Design Considerationsdraft-ietf-mpls-tp-mip-mep-map-09for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) Abstract TheFrameworkframework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how the Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes attheincoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. Morepreciselyprecisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming orMIPs onoutgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. Status ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are amaximumcandidate for any level ofsix monthsInternet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 3, 2014.http://www.rfc-editor.org/info/rfc7054. Copyright Notice Copyright (c) 2013 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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . 3.....................................................3 3. Summary of the Problem Statement. . . . . . . . . . . . . . . 3................................3 4. Requirements and Design Considerations for Internal-MIPAdressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6Addressing ......................................................6 5. Security Considerations. . . . . . . . . . . . . . . . . . . 10........................................10 6.IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 10 8.................................................10 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1......................................................10 7.1. Normative References. . . . . . . . . . . . . . . . . . . 11 8.2.......................................10 7.2. Informative References. . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11....................................11 1. Introduction TheFrameworkframework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP)(the MPLS-TP OAM Framework, [RFC6371]) distinguishes two configurations for the 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 each side 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 headertime-to-liveTime-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 caseIf 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. A mechanism that addresses this shortcoming has to obey a few important designconsiderationsconsiderations, which are discussed in this document.Note that the acronym "OAM" is used in conformance with [RFC6291].2. Terminology In thisdocumentdocument, we use the term in-MIP (incoming MIP) to refer to the MIPwhichthat 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. The term "forwarding engine" is used as defined in [RFC6371]. Note that the acronym "OAM" is used in conformance with [RFC6291]. 3. Summary of the Problem Statement Figure 1 shows an abstract functional representation of an MPLS-TP node. It is decomposed as an incominginterface,interface (labeled "In"), a forwarding engine (FW), and an outgoinginterface.interface (labeled "Out"). 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 andLSPsLSPs, such as: o Connectivity Verification (CV) between aMEPMaintenance Entity Group End Point (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 mayequallyalso 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 tests. 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 down the cause of a faultdownquickly to initiate atimely,timely and well- directed maintenance action to resume normal network operation. The following two figures illustrate the fundamental differenceofbetween using per-node and per-interface MEPs and MIPs for OAM. Figure 2 depicts OAM using per-node MIPs and MEPs. For reasons ofexpositionexposition, we pick a location for the MIPs on the nodes but the standard does not mandate the exact location for the per-node model. In thefigurefigure, abi-directionalbidirectional LSP is depicted where in the forward (FWD) direction MEP1, MIP1, and MEP2 are located on the ingressinterface (IF).interface. In the backward (BWD) direction MEP1', MIP1' and MEP2' are located on the egressIF, i.e.interface, i.e., the same interfaces. S1 in the figure denotes the segment from PE1 In to P1 In and S2 denotes the segment from PE1 In to P2 In. Figure33, on the otherhandhand, shows the same basicnetworknetwork, butfor OAM operationsper-interface maintenance points areconfigured.configured for OAM operations. Note that these figures are merely examples. It is important to note that per-interface MEPs orper-interfaceper- interface MIPs must logically be placed at a point before (for in-MIP) or after (forout- MIP)out-MIP) passing the forwarding engine as defined in [RFC6371]. All traffic associated with the MEP/MIP must pass through or be terminated at that point. Customer| Operator'sadministrativeAdministrative | Customer Domain | Domain | Domain ------> |<--------------------------------------->| <------ CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD PW/LSP | o-------------------------- > | | V-------------*-------------V | | MEP1 MIP1 MEP2 | BWD PW/LSP | <---------------------------o | | V-------------*-------------V | | MEP1' MIP1' MEP2'| (S1)<============> (S2)<==========================> Figure 2: Example of OAMrelyingRelying onper-nodePer-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 andCE2CE2, or CE2 itself as a potential location of the fault ason- demandon-demand CV can only be performed on segment S2. Note that in this scenario, the PWs or LSPs are to be understood as two examples (notone). I.e.one), i.e., the figures do not show the layer structure of PWs and LSPs. 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 ruleout e.g.out, for example, the forwarding 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 OAMoperationsoperations, such as fault localization and performancemonitoringmonitoring, which gives operators better information to deal with adverse networking conditions.CustomerCustomer| Operator'sadministrative Customer DomainAdministrative |Customer Domain | Domain |Domain ------->|<--------------------------------------->|<------ CE1 | T-PE/PE1 S-PE/P1 T-PE/PE2 | CE2 | <--------> <--------> <--------> | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +---+ | +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ | +---+ | In FW Out In FW Out In FW Out | | | FWD PW/LSP | o-----------------------------------> | | V-------*------*------*-----*-------V | | MEP1 MIP1 MIP2 MIP3 MIP4 MEP2| | | BWD PW/LSP | <-----------------------------------o | | MEP1' MIP1' MIP2' MIP3' MIP4' MEP2'| (S'1)<======> (S'2)<=============> (S'3)<====================> (S'4)<==========================> (S'5)<==================================> Figure 3: Example of OAMrelyingRelying onper-interfacePer-Interface MIPs and MEPs 4. Requirements and Design Considerations for Internal-MIPAdressingAddressing OAM messages for transit points of PWs or LSPs are delivered using the expiration of thetime-to-live (TTL)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. These messages are distinguished from other (data) packets so that they can be processed as OAM. In LSPs, the mechanism used is the presence of theGeneric Associated Channel Label (GAL)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]. In addition, two sets of identifiers exist that can be used to addressMIPsMIPs, which are defined in [RFC6370] and [RFC6923] Any solution for sending OAM messages to theinin- and out-MIPs must fit within these existing models of handling OAM. Additionally, many MPLS-TP nodes are implemented in a way that all queuing and the forwarding functionisare 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 isin particularthe case for existing deployedimplementations.implementations in particular. 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 (such as leaking OAM packets with a TTL of 0). --------------------- |------------ | | MIP | | | ---- | | ----->-| In | FW | |-->-Out-|->--- | i/f ---- | i/f | |------------ | --------------------- Figure 4: Abstract Functional Representation of Some Existing MPLS-TP Nodes OAM must operate on MPLS-TP nodes that are branch points on point-to- multipoint (P2MP) trees.ThatThis 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 asand to handle the P2MP node implementations as shown in Figure 6 without causing problems. -------------------------- | -----| | | 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 ---------------------- | ->-Out-|->---- | | i/f | |------------ | | | | | | | MIP ---- | | | | | | |- | ----->-| In | FW | |--->-Out-|->---- | i/f | | |- i/f | | ---- | | | | | | | |------------ | | | | Out | | ->-i/f-|->---- ---------------------- Figure 6: Abstract Functional Representation of Some Existing MPLS-TP Nodes Supporting P2MP In summary, the solution for OAM message delivery must behave as follows: 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 Forwarding of OAM packets exactly as data packets. o Packet inspection at the incoming and outgoing interfaces must be minimized. The first and second bulletpointpoints are obvious.TheHowever, the third bullet pointhoweveris also vital. To illustrate the importance, a rejected solution is depicted in Figure 7. In the figure, all data andnon-localnon- 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 incomingMIPMIP, it is handled there with no issue. If the OAM is intended for the outgoingMIPMIP, it is forwarded to that MIP using some internal messaging system that isimplementation-specific.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 outgoingMIP,MIP and can adequately perform some OAM features such as interface identity reporting at the outgoing MIP. 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. The last bullet point is also an important requirement for any solution to the internal-MIP addressing problem. Since OAM packets that target an out-MIP need to be sent through the forwarding engine and treated exactly as regular data packets, the determination of whether to forward the packet or process it at the incoming MIP needs to befast and thereforefast; therefore, the processing overhead must be kept to a minimum. In addition, there are a few OAM procedures that operate at line rate such as OAM loopback. This adds to the requirement of minimal processing overhead for both the in-MIP and out-MIP. Most of the above superficially appears to be an implementation matter local to an individualnode,node; however, the format of the message needs to bestandardisedstandardized 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 implementation as shown inFigureFigures 4or Figureand 6. Note that the last bullet point describes a safety netand an implementationin case OAM messages leak beyond their intended scope, but implementations shouldavoidtake care thatthis situation ever arises.messages do not leak so that the safety net does not need to be used. 5. Security Considerations OAM security is discussed in [RFC6371] and security aspects specific to MPLS-TP in general are outlined in [RFC6941]. OAM can provide useful information for detecting and tracing security attacks. OAM can also be used to illicitly gather information or fordenial of servicedenial- of-service attacks and other types of attack. Implementations therefore are required to offer security mechanisms for OAM. Deployments are therefore strongly advised touse such mechanisms.follow the security advice provided in RFCs 6371 and 6941. Mixing of per-node and per-interface OAM on a single node is not advised as OAM message leakage could be the result. 6.IANA Considerations This revision of this document does not make any requests of IANA. 7.Acknowledgments The authors gratefully acknowledge the substantial contributions of Zhenlong Cui. We would also like to thank Eric Gray, SamiBoutrosBoutros, and Shahram Davari for interesting input to this document through discussions.8.7. References8.1.7.1. Normative References [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., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "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.I., Ed., and D. Allan, Ed., "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. [RFC6923] Winter, R., Gray, E., van Helvoort, H., and M. Betts, "MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions", RFC 6923, May 2013.8.2.7.2. Informative References [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. [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013. Authors' Addresses Adrian Farrel Juniper NetworksEmail:EMail: adrian@olddog.co.uk Hideki Endo Hitachi, Ltd.Email:EMail: hideki.endo.es@hitachi.com Rolf Winter NECEmail:EMail: rolf.winter@neclab.eu Yoshinori Koike NTTEmail:EMail: koike.yoshinori@lab.ntt.co.jp Manuel Paul Deutsche TelekomEmail:EMail: Manuel.Paul@telekom.de