summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7054.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7054.txt')
-rw-r--r--doc/rfc/rfc7054.txt619
1 files changed, 619 insertions, 0 deletions
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]
+