From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7054.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7054.txt (limited to 'doc/rfc/rfc7054.txt') diff --git a/doc/rfc/rfc7054.txt b/doc/rfc/rfc7054.txt new file mode 100644 index 0000000..c7517bc --- /dev/null +++ b/doc/rfc/rfc7054.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Farrel +Request for Comments: 7054 Juniper Networks +Category: Informational H. Endo +ISSN: 2070-1721 Hitachi, Ltd. + R. Winter + NEC + Y. Koike + NTT + M. Paul + Deutsche Telekom + November 2013 + + + Addressing Requirements and Design Considerations for + Per-Interface Maintenance Entity Group Intermediate Points (MIPs) + +Abstract + + The framework 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 at incoming and outgoing interfaces. + + This document elaborates on important considerations for internal MIP + addressing. More precisely, 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 or outgoing + 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 of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the 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 a candidate for any level of Internet + 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 be obtained at + http://www.rfc-editor.org/info/rfc7054. + + + + +Farrel, et al. Informational [Page 1] + +RFC 7054 Internal MIP Considerations November 2013 + + +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 ....................................................2 + 2. Terminology .....................................................3 + 3. Summary of the Problem Statement ................................3 + 4. Requirements and Design Considerations for Internal-MIP + Addressing ......................................................6 + 5. Security Considerations ........................................10 + 6. Acknowledgments ................................................10 + 7. References .....................................................10 + 7.1. Normative References ......................................10 + 7.2. Informative References ....................................11 + +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 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 header Time-to-Live (TTL) field. OAM + messages for the end points of PWs and LSPs are simply delivered as + normal. + + + + + + +Farrel, et al. Informational [Page 2] + +RFC 7054 Internal MIP Considerations November 2013 + + + 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]. + + If 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 design considerations, which are discussed in this + document. + +2. Terminology + + In this document, we use the term in-MIP (incoming MIP) to refer to + the MIP that 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 incoming interface (labeled "In"), a + forwarding engine (FW), and an outgoing 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 + + + + + + + + +Farrel, et al. Informational [Page 3] + +RFC 7054 Internal MIP Considerations November 2013 + + + Several distinct OAM functions are required within this architectural + model for both PWs and LSPs, such as: + + o Connectivity Verification (CV) between a Maintenance 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 may also 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 fault quickly to initiate a timely and well- + directed maintenance action to resume normal network operation. + + The following two figures illustrate the fundamental difference + between 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. + In the figure, a bidirectional LSP is depicted where in the forward + (FWD) direction MEP1, MIP1, and MEP2 are located on the ingress + interface. In the backward (BWD) direction MEP1', MIP1' and MEP2' + are located on the egress 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. Figure 3, on the other hand, shows + the same basic network, but per-interface maintenance points are + configured for OAM operations. Note that these figures are merely + examples. It is important to note that per-interface MEPs or per- + interface MIPs must logically be placed at a point before (for + in-MIP) or after (for 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. + + + + + + + + + +Farrel, et al. Informational [Page 4] + +RFC 7054 Internal MIP Considerations November 2013 + + + Customer| Operator's Administrative | 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 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. Note that in this + scenario, the PWs or LSPs are to be understood as two examples (not + 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 rule 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 OAM + operations, such as fault localization and performance monitoring, + which gives operators better information to deal with adverse + networking conditions. + + + + + + +Farrel, et al. Informational [Page 5] + +RFC 7054 Internal MIP Considerations November 2013 + + + Customer| Operator's Administrative |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 OAM Relying on Per-Interface MIPs and MEPs + +4. Requirements and Design Considerations for Internal-MIP Addressing + + OAM messages for transit points of PWs or LSPs are delivered using + the expiration of the 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 the 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 address MIPs, which are defined in [RFC6370] and [RFC6923] + + 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 are implemented in a way that all + queuing and the forwarding function are 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 + + + + + +Farrel, et al. Informational [Page 6] + +RFC 7054 Internal MIP Considerations November 2013 + + + MIP functions on those interfaces. This is the case for existing + deployed 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. This 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, and 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 + + + +Farrel, et al. Informational [Page 7] + +RFC 7054 Internal MIP Considerations November 2013 + + + ---------------------- + | ->-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 bullet points are obvious. However, the third + bullet point is also vital. To illustrate the importance, a rejected + solution is depicted in Figure 7. In the figure, 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. + + + + + + + + + + +Farrel, et al. Informational [Page 8] + +RFC 7054 Internal MIP Considerations November 2013 + + + ------------------------ + |----- -----| + 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. + + 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 be fast; 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 individual node; however, the format of the + message needs to be standardized 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 in Figures 4 and 6. + + Note that the last bullet point describes a safety net in case OAM + messages leak beyond their intended scope, but implementations should + take care that messages do not leak so that the safety net does not + need to be used. + + + +Farrel, et al. Informational [Page 9] + +RFC 7054 Internal MIP Considerations November 2013 + + +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 for denial- + of-service attacks and other types of attack. Implementations + therefore are required to offer security mechanisms for OAM. + Deployments are therefore strongly advised to 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. Acknowledgments + + The authors gratefully acknowledge the substantial contributions of + Zhenlong Cui. We would also like to thank Eric Gray, Sami Boutros, + and Shahram Davari for interesting input to this document through + discussions. + +7. References + +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., 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. + + + + + +Farrel, et al. Informational [Page 10] + +RFC 7054 Internal MIP Considerations November 2013 + + + [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. + +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 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. Informational [Page 11] + -- cgit v1.2.3