TOC |
|
MPLS-TP P2MP OAM analysis
draft-xia-mpls-tp-p2mp-oam-analysis-00
Abstract
This document attempts to analyze MPLS-TP P2MP OAM implementations and related problems by combining with MPLS-TP P2MP network characteristics and the MPLS-TP OAM requirements. We give a specific analysis to some key issues in P2MP scenarios. And we analyze every MPLS-TP OAM function in P2MP scenarios and give guidelines or recommendations.
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 material or to cite them other than as “work in progress.”
This Internet-Draft will expire on January 28, 2011.
Copyright Notice
Copyright (c) 2010 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
1.1.
Movitation and Scope
1.2.
Conventions
1.3.
Abbreviations
1.4.
MPLS P2MP signaling technology overview
1.5.
MPLS-TP P2MP OAM requirements and current solutions
2.
P2MP key issues
2.1.
Scalability issue
2.2.
Return path
2.3.
P2MP Node Identifier TLV
2.4.
TTL setting and handle
2.5.
Bud node analysis
2.6.
SPME OAM in P2MP
2.7.
Locally independence requirements
2.8.
Per-interface MIP/MEP
3.
P2MP OAM Functions Analysis
3.1.
Continuity Check and Pro-active Connectivity Verification and Remote Defect Indication
3.2.
Alarm Reporting and Lock Reporting
3.3.
On-demand Connectivity Verification and Route Tracing
3.4.
Diagnostic Tests
3.4.1.
Throughput Estimation
3.4.2.
Data Plane Loopback
3.5.
Lock Instruct
3.6.
Client Failure Indication
3.7.
Packet Loss Measurement
3.8.
Packet Delay Measurement
4.
P2MP PW analysis
5.
IANA Considerations
6.
Security Considerations
7.
Acknowledgements
8.
References
8.1.
Normative References
8.2.
Informative References
§
Authors' Addresses
TOC |
1. Introduction
TOC |
1.1. Movitation and Scope
MPLS-TP OAM provides efficient and reliable methods for fault management and performance monitoring. It also can help operators to meet the SLAs while reducing their operational costs.
[RFC5654] (Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” September 2009.) in general, and [RFC5860] (Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” May 2010.) in particular define a set of requirements for OAM functionality applied to MPLS-TP Label Switched Paths (LSPs) (network infrastructure) and Pseudowires (PWs) (services). [I‑D.ietf‑mpls‑tp‑oam‑analysis] (Sprecher, N., Bellagamba, E., and Y. Weingarten, “MPLS-TP OAM Analysis,” July 2010.) has given an analysis to those existing OAM tools defined for MPLS and in ITU-T, including LSP Ping, MPLS BFD, VCCV, and Y.1731. It has identified which tools need to be extended to comply with the MPLS-TP OAM requirements, and which new tools need to be defined.
Based on above documents, some drafts concerning specific OAM tool have been worked out. Including [I‑D.ietf‑mpls‑tp‑lsp‑ping‑bfd‑procedures] (Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher, N., and Y. Weingarten, “LSP-Ping and BFD encapsulation over ACH,” March 2010.), [I‑D.ietf‑mpls‑tp‑cc‑cv‑rdi] (Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan, S., and D. Ward, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” July 2010.), [I‑D.nitinb‑mpls‑tp‑lsp‑ping‑extensions] (Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “LSP-Ping extensions for MPLS-TP,” February 2010.), etc.
The current situation is that these above drafts mainly focus on the analysis and implementation of P2P OAM, and they do not have enough in-depth analysis with respect to P2MP OAM.
Then this document attempts to analyze MPLS-TP P2MP OAM implementations and related problems by combining with MPLS-TP P2MP network characteristics and the MPLS-TP OAM requirements. Solutions are provided for some problems, and others need further study.
This document is arranged as follows: first, an overview of MPLS P2MP technology and MPLS-TP P2MP OAM requirements with current solutions, which is given as a starting point for following discussion; secondly, from the structure point of view, a specific analysis is given to some key issues; finally, from a functional perspective, every MPLS-TP P2MP OAM function is analyzed and guidelines or recommendations are given.
TOC |
1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
TOC |
1.3. Abbreviations
ACH: Associated Channel Header
BFD: Bidirectional Forwarding Detection
CC: Continuity Check
CRC: Cyclic Redundancy Check
CV: Connectivity Verification
DM: Packet Delay Measurement
LB: Loopback
LDP: Label Distribution Protocol
LM: Loss Measurement
LSP: Label Switched Path
MEG: Maintenance Entity Group
MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point
MPLS-TP: MPLS Transport Profile
OAM: Operations, Administration and Maintenance
P2P: Point to Point
P2MP: Point to MultiPoint
PW: PseudoWire
RSVP-TE: Resource Reservation Protocol-Traffic Engineering
SLA: Service Level Agreement
SPME: Sub-Path Maintenance Element
TLV: Type Length Value
VCCV: Virtual Circuit Connection Verification
TOC |
1.4. MPLS P2MP signaling technology overview
P2MP service is used to deliver data from a single source to one or more receivers. This service can be simply supported by combination of P2P LSPs. But the fully efficient way (mainly refer to bandwidth consumption, numbers of used LSPs) to support P2MP service is using P2MP LSP. P2MP LSP has only one ingress LSR,but may have one or more egress LSRs. Data traffic is efficiently replicated in branch LSRs. Signaling requirements for the P2MP TE LSPs can refer to [RFC4461] (Yasukawa, S., “Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs),” April 2006.).
Currently, there are two kinds of signaling protocol mechanisms to build P2MP LSP:
- 1.
- Extensions to RSVP-TE protocol for P2MP TE LSPs([RFC4875] (Aggarwal, R., Papadimitriou, D., and S. Yasukawa, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” May 2007.)):This solution relies on the semantics of the Resource Reservation Protocol (RSVP) that RSVP-TE inherits for building P2MP LSPs. It doesn't require a multicast routing protocol in the Service Provider core. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between the ingress and egress LSRs and are appropriately combined by the branch LSRs using RSVP semantics to result in a P2MP TE LSP. One Path message may signal one or multiple S2L sub-LSPs for a single P2MP LSP. Hence the S2L sub-LSPs belonging to a P2MP LSP can be signaled using one Path message or split across multiple Path messages.
- 2.
- LDP Extensions for P2MP and MP2MP LSPs([I‑D.ietf‑mpls‑ldp‑p2mp] (Minei, I., Kompella, K., Wijnands, I., and B. Thomas, “Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths,” July 2010.)):These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Leaf nodes initiate P2MP LSP setup and tear-down. Leaf nodes also install forwarding state to deliver the traffic received on a P2MP LSP to wherever it needs to go. Transit nodes install MPLS forwarding state and propagate the P2MP LSP setup (and tear-down) toward the root. The root node installs forwarding state to map traffic into the P2MP LSP.
MPLS-TP decides to build P2MP TE LSP by using RSVP-TE signaling protocol in Control Plane or by static configuration in Management Plane. LDP Extensions for P2MP is outside the scope of this document.
TOC |
1.5. MPLS-TP P2MP OAM requirements and current solutions
MPLS-TP OAM is running on Data Plane. So, its implementation mechanism must be based on the characteristics of the data plane. The basic characteristics of the data plane in P2MP network is a unidirectional tree topology. Data traffic is sent from the only one ingress LSR, and replicated in branch LSRs, received by all (one or more) egress LSRs.
MPLS P2MP OAM requirements([RFC4687] (Yasukawa, S., Farrel, A., King, D., and T. Nadeau, “Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks,” September 2006.)) analyzes from various functional point of view, including Detection and Diagnosis of LSP Defects, Path Characterization, SLA Measurement, Frequency of OAM Execution, Alarm Suppression, Fault Notification, etc. It gives the general requirements and related high-level analysis about OAM implementations in P2MP MPLS network.
MPLS-TP OAM Requirements ([RFC5860] (Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” May 2010.)) analyzes the OAM requirements in MPLS-TP network from the architectural and functional these two aspects. The table below gives a summary about P2MP part in this document:
+-----------+------------+-----------+---------------+---------+-----------+ | Item | pro-active | on-demand | path type | P2MP | out of | | | | | | | band | | | | | | | return | | | | | | | path | | | | | | | for | | | | | | | P2MP | +-----------+------------+-----------+---------------+---------+-----------+ | CC | support | no | E2E | support | no need | | | | support | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | CV | support | support | pro-active: | support | on-demand | | | | | E2E, | | need | | | | | on-demand:E2E | | | | | | | or E2I | | | +-----------+------------+-----------+---------------+---------+-----------+ | Route | no | support | E2E or E2I | support | need | | Tracing, | support | | | | | | Diagnostic| | | | | | | Tests | | | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | Lock | support | no | I2E | support | no need | | Reporting,| | support | | | | | Alarm | | | | | | | Reporting | | | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | Remote | support | no | E2E | support | need | | Defect | | support | | | | | Indication| | | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | Client | support | no | E2E | support | no need | | Failure | | support | | | | | Indication| | | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | Packet | support | support | E2E | support | no need | | Loss | | | | | | |Measurement| | | | | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+ | Packet | support | support | E2E | one way | no need | | Delay | | | | delay: | | |Measurement| | | | support | | | | | | | two way | | | | | | | delay | | | | | | | : no | | | | | | | support | | | | | | | | | +-----------+------------+-----------+---------------+---------+-----------+
Figure 1: MPLS_TP P2MP OAM requirements table |
Notes:
- 1)
- The abbreviations in column "path type" of E2E, E2I, I2E means separately end point to end point, end point to intermediate point, intermediate point to end point;
- 2)
- Out of band return path for P2MP: P2MP LSP is an unidirectional path from the ingress node to all of the egress nodes in Data Plane. So the return path here referred does not exist in Data Plane. It mainly refers to the Control Plane or IP routing return path. It is usually called out of band return path.
MPLS-TP OAM analysis document ([I‑D.ietf‑mpls‑tp‑oam‑analysis] (Sprecher, N., Bellagamba, E., and Y. Weingarten, “MPLS-TP OAM Analysis,” July 2010.)) analyzes the current OAM tools defined for MPLS and ITU-T, and gives the conclusions about whether existing OAM tools can be used to meet the MPLS-TP OAM requirements, and identify which tools need to be extended to comply with the requirements and which new tools need to be defined. Based on this document, many specific OAM tools implementation documents have been produced. The table below gives a summary of OAM tools implementation which is also applied to P2MP scenario:
+--------------+-----------------+-----------------+----------------+ | Items | Recommendations | Gaps | Solutions | +--------------+-----------------+-----------------+----------------+ | Pro-active | Extend MPLS BFD | MPLS BFD | use ACH for | | CC-V, Remote | to fully | requires IP | non-IP | | Defect | support | encapsulation | encapsulation | | Indication | |-----------------+----------------| | | | For CV, basic | define a new | | | | BFD's | type ACH and a | | | | limitation of | new TLV | | | | locally unique | carrying the | | | | (to each node) | unique source | | | | session | MEP Identifier | | | | identifiers | | +--------------+-----------------+-----------------+----------------+ | On-demand | Extend LSP Ping | LSP Ping | use ACH for | | CV, Route | to fully | requires IP | non-IP | | Tracing | support | encapsulation | encapsulation | | | |-----------------+----------------| | | | How to arrive | Proper setting | | | | intermediate | of the TTL | | | | node | value | | | |-----------------+----------------| | | | Global | Add new | | | | identifiers for | type TLVs | | | | Source Address, | | | | | MEP, MIP etc | | +--------------+-----------------+-----------------+----------------+ | Lock | Extend LSP Ping | PDU and | Refer to | | Instruct | to support | procedure | Y.1731 | | | | definition | | +--------------+-----------------+-----------------+----------------+ | Alarm | Define a new | PDU and | Refer to | | Reporting, | PDU which will | procedure | Y.1731 | | Lock | be transmitted | definition | | | Reporting, | over G-ACH to | | | | Diagnostic | support | | | | Tests, | | | | | Packet Loss | | | | | Measurement, | | | | | Packet Delay | | | | | Measurement | | | | +--------------+-----------------+-----------------+----------------+ | Client | Use PWE3 tool | PDU and | Define new | | Failure | to propagate | procedure | | | Indication | Client Fail | definition | | | | Indication via | | | | | an ACH | | | +--------------+-----------------+-----------------+----------------+
Figure 2: MPLS-TP P2MP OAM tools implementation summary table |
TOC |
2. P2MP key issues
TOC |
2.1. Scalability issue
Scalability is a key requirement in P2MP network. Since the number of egresses for a single P2MP LSP is unknown and not bounded by any small number, it follows that all mechanisms defined for OAM support MUST scale well with the number of egresses and the complexity of the path of the LSP. So, P2MP OAM mechanisms MUST be designed to scale well with an increase in the number of any of the sink MEPs and MIPs.
Scalability is a high-level and general requirement. How to achieve it needs further study on every specific OAM tool.
TOC |
2.2. Return path
P2MP LSP is inherently an unidirectional path from the ingress node to all of the egress nodes in Data Plane. And in band return path does not exist in Data Plane. So, it can not directly support the OAM mechanism which needs to return a confirmation message. For example, On-demand CV, Route Tracing, etc. In this case, we have three general solutions:
- 1.
- Out of band return path: It mainly refers to the Control Plane or IP routing return path;
- 2.
- In band return path: Building a P2P LSP from an egress node to ingress node in Data Plane to be the in band return path;
- 3.
- Extending existed OAM tools to run without the support of return path. This solution needs further study.
TOC |
2.3. P2MP Node Identifier TLV
P2MP Node Identifier TLV here means the TLV attribute that was brought in the OAM packet, and contains enough information to uniquely identify the destination MEP or MIP node. It is also called P2MP Responder Identifier TLV in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.).
In a P2MP LSP, the ingress node can be the only one source MEP, all the branch nodes in the middle of the P2MP tree can be the MIPs, all of the bud nodes can be both sink MEPs and MIPs, all egress nodes can be sink MEPS.
In general, OAM packets sent from the source MEP, through the Data Plane, forwarded to all sink MEPs, should be processed by each sink MEPs. If the OAM packets are required to be processed only by one or a group of designated sink MEPs, but not all sink MEPs, then a new extending mechanism--- P2MP Node Identifier TLV can achieve it.
An OAM packet transmitted by the source MEP can carry a number of P2MP Node Identifier TLVs, corresponding to a group of designated sink MEPs. This OAM packet is forwarded through Data Plane, to reach all sink MEPs. Sink MEPs can use those P2MP Node Identifier TLVs carried in the OAM packet to decide how to process this OAM packet. A sink MEP will process the OAM packet only when it matches a P2MP Node Identifier TLV in the OAM packet, or else it should discard the OAM packet. Of course, if an OAM packet does not carry any P2MP Node Identifier TLV, it should be processed by all sink MEPs.
The P2MP Node Identifier TLV only has meaning on an OAM message which is sent from source MEP to sink MEPs. If present on a return OAM message, it SHOULD be ignored.
Sometimes, OAM packets need to be processed by one or a group of designated MIPs. In this case, except for P2MP Node Identifier TLV, but also needs TTL together to locate the designated MIPs. Section 2.4 will give a more detailed description about it.
One possibility is that the number of sink MEPs or MIPS which need to process an OAM packet is too large to carry all P2MP Node Identifier TLVs in an OAM packet. In order to handle this problem, source MEP can set the max number of P2MP Node Identifier TLVs in an OAM packet and transmit the OAM packet for several times.
The TLV format based on IP address and the details of using it are defined in [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.), the non-IP definition needs further study.
TOC |
2.4. TTL setting and handle
In the case of MPLS-TP P2P LSP,when an OAM packet needs to be processed by a MIP, it must properly set the TTL value to be the hop number from the MEP to MIP, together with the only Node Identifier TLV carried in the OAM packet to verify the validity of the destination MIP.
P2MP LSP also has the same requirement. There are three cases when an OAM packet transmitted from the source MEP needs to be processed by one or a group of MIPs in the P2MP LSP, as follow:
- 1.
- Case one: Destination is one MIP. After properly setting the TTL value and the P2MP Node Identifier TLV carried in the OAM packet, the source MEP sends the OAM packet out, and then the OAM packet is terminated in those MIPs whose hop number from the source MEP is equal to the setting of TTL value. These MIPs decide whether to process the OAM packet by checking the P2MP Node Identifier TLV in the OAM packet. At last, only one MIP will process the OAM packet and other MIPs should discard the OAM packet.
- 2.
- Case two: Destination is a group of MIPs which have the same hop number from the source MEP. The TTL setting and processing is similar with case one, the only difference is that the OAM packet needs to carry more than one P2MP Node Identifier TLVs or no P2MP Node Identifier TLV(aimed to all MIPs with the same TTL value). At last, these group(or all) MIPs will process the OAM packet and other MIPs should discard the OAM packet.
- 3.
- Case three: Destination includes a group of MIPs which have the different hop number from the source MEP. In this case, the source MEP must construct more than one OAM packets with different TTL value, the destination of every OAM packet is a group of MIPs which have the same hop number from the source MEP. Every OAM packet can carry more than one P2MP Node Identifier TLVs.
The above process solutions have a premise that the source MEP already knew the hop number between itself and each designated MIP.
In above process, one possibility is that some sink MEPs may have less hop number from the source MEP than the TTL value setted in the OAM packet. In this case, how to process the OAM packet is nothing to do with the TTL value, and the OAM packet must be terminated in the sink MEPs. When the OAM packet carrys the Node Identifier TLVs, the sink MEPs will discard the OAM packet because of the mismatch of the P2MP Node Identifier TLV. If not, [I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) has provided a solution of a new "Respond Only If TTL Expired" flag to reduce extraneous responses from sink MEPs.
TOC |
2.5. Bud node analysis
In a P2MP LSP, the bud node can be not only a MIP, but also a sink MEP.
As a MIP, the bud node should forward all the OAM packets whose destination is the downstream MIPs or sink MEPs. At the same time as a sink MEP, the bud node must do a copy of every OAM packet it received to handle.
We can describe a bud node function logically in the below figure:
-------------------------- | | | | | |->| MEP | | | | ----------- | | | | | | -----| | | copy ->-| |->---- | | | | Out | | ^ | | i/f | | | ---- | -----| |----- | f | | | | MIP | | o | | -----| | | | r |- | | ----->-| In |->-| w |--->-| Out |->---- | i/f | | a |- | i/f | |----- | r | | -----| | | d | | | | ---- | -----| | | | | | ->-| Out |->---- | | i/f | | -----| --------------------------
Figure 3: Bud node logic function |
From the figure above, we can see that the MEP in bud node gets a copy of the OAM packet it received to handle. This copy of OAM packet is nothing to do with the OAM packets forward to downstream nodes of the bud node. So, the defects such as LOC of CC or unintended connectivity between two MEPs (e.g. mismerging or misconnection or unexpected MEP) of CV and so on, found by the MEP in the bud node are also nothing to do with the downstream nodes of the bud node.
In general, although the bud node takes two roles of MIP and sink MEP, but these two functions are still running independent of each other. the OAM processing results of MEP can not in turn affect the MIP operation.
TOC |
2.6. SPME OAM in P2MP
SPME OAM in P2P LSP scenarios is intended to be used for monitoring the behavior of a portion of a P2P LSP or a set of co-routed P2P LSPs. It is implemented by means of setting the two end nodes of the SPME to be MEPs and utilizing label stack to support multiple layer operation.
Similarly, SPME OAM can also be used in P2MP LSP tree scenarios, intended to be used for monitoring the behavior of a sub-tree of a P2MP LSP tree. In this case, it needs to set the root and all leaf nodes of the sub-tree to be MEPs, and still utilizes label stack to support multiple layer operation. And the sub-tree SPME OAM MEG is independent of the P2MP LSP tree OAM MEG. The OAM packet belong to the latter MEG is considered a common data packet in former MEG and should be forwarded in Data Plane without any OAM operations. The OAM packet belong to the former MEG is only forwarded and performs OAM operation between MEPs of itself, and will not leak to the latter MEG.
More complex, if a sub-tree exists in more than one P2MP LSP trees, it is preferred to implement only a sub-tree SPME OAM MEG for this sub-tree. This sub-tree SPME OAM MEG can provide monitoring for all P2MP LSP trees. So it does not need to have a sub-tree SPME OAM MEG for every above P2MP LSP tree. Specially, when the middle portion multiplexing rate of multiple P2MP LSPs is relatively high, the method is particularly applicable.
TOC |
2.7. Locally independence requirements
A P2MP LSP tree may contain many branches and sub-trees. From scalability point of view, it requires that the partial changes happened in a sub-tree only affect this sub-tree OAM functions and can not affect the OAM functions of the other part of the P2MP LSP. These partial changes include the add, delete, modification of the sub-tree or the leafs.
This issue needs more examples to perform a more in-depth analysis!
TOC |
2.8. Per-interface MIP/MEP
Per-interface MIP/MEP model is the extended and enhancement definition of the two basic concepts of MIP and MEP. Compare to the traditional Per-node MIP/MEP model, MIP and MEP can be defined and run on the in interface or out interface of a node. Because of the more precise location of MIP and MEP, per-interface MIP/MEP model can provide more effective and more precise OAM functions such as a proactive continuity check, proactive on-demand connectivity verification, on-demand route tracing, on-demand loss measurement, on-demand delay measurement and diagnostic test than per-node MIP/MEP model.
[I‑D.koike‑ietf‑mpls‑tp‑oam‑maintenance‑points] (Paul, M. and Y. Koike, “MPLS-TP OAM Maintenance Points,” March 2010.) provides the requirements and definitions of the Per-interface MIP/MEP model and its implementations in every OAM function. [I‑D.farrel‑mpls‑tp‑mip‑mep‑map] (Farrel, A. and H. Endo, “Handling MPLS-TP OAM Packets Targeted at Internal MIPs,” July 2010.) 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 contents of these two documents can all directly apply to P2MP scenarios.
As for P2MP scenarios, the Per-interface MIP model in branch node needs focus attention and study. Branch node has one in interface,more than one out interfaces. They can all be set to be MIPs so that get more precise fault location or performance monitoring information than traditional Per-node model.
TOC |
3. P2MP OAM Functions Analysis
TOC |
3.1. Continuity Check and Pro-active Connectivity Verification and Remote Defect Indication
- CC(Continuity Check) monitors the integrity of the continuity of the path for any loss of continuity defect by pro-actively sending OAM packet.
- Pro-active CV(Connectivity Verification) monitors the integrity of the routing of the path between sink and source for any connectivity issues by pro-actively sending OAM packet.
- RDI(Remote Defect Indication) enables an End Point to report, to its associated End Point, a fault or defect condition that it detects on a path.
According to [I‑D.ietf‑mpls‑tp‑oam‑analysis] (Sprecher, N., Bellagamba, E., and Y. Weingarten, “MPLS-TP OAM Analysis,” July 2010.), they can all be fully supported by Extending MPLS BFD.
Currently, [I‑D.ietf‑mpls‑tp‑cc‑cv‑rdi] (Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan, S., and D. Ward, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” July 2010.) has already given the definitions and descriptions of how MPLS BFD supports the above three pro-active OAM functions.
RDI requires bidirectional path support. So, RDI cannot be supported directly in P2MP scenario because of the inherently unidirectional characteristics of P2MP, unless an out of band return path from sink MEP to source MEP exists.
For CC and pro-active CV,below is a comparison between the P2MP LSP and P2P LSP:
- Source MEP: Only one source MEP per LSP. The format and semantics of the extended MPLS BFD packet for P2P LSP CC and pro-active CV function do not need any changes to identify the source MEP in the P2MP LSP. So the implementation of this two OAM functions in the source MEP has no difference between the P2MP LSP and the P2P LSP.
- Sink MEP: Only one sink MEP in a P2P LSP. P2MP LSP is extended to have one or more sink MEPs. However, each sink MEP of the P2MP LSP can run the OAM packets receiving and LSP defects detection of the CC and pro-active CV function independently, and exactly the same as the sink MEP of P2P LSP.
- The transmission of the OAM packet: P2MP LSP inherently supports to forward the OAM packet from source MEP to all sink MEPs in Data Plane. Since each sink MEP runs the OAM function independently from each other,the CC and pro-active CV function in P2MP LSP can be considered a group of OAM functions independently and simultaneously running between the source MEP and each sink MEP. In this respect, there is no essential difference between P2MP LSP and the P2P LSP.
In summary, the definition and implementation of the CC and pro-active CV in [I‑D.ietf‑mpls‑tp‑cc‑cv‑rdi] (Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan, S., and D. Ward, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” July 2010.) can be applied directly on the P2MP LSP.
TOC |
3.2. Alarm Reporting and Lock Reporting
The MPLS-TP Alarm Indication Signal (AIS) message is generated in response to detecting defects in the server layer.
The MPLS-TP Locked Report (LKR) message is generated when a server layer entity has been administratively locked to communicate that condition to inform the client layer entities.
These two kinds of OAM messages are immediately sent to the client MEPs by inserting them into the affected paths in the direction opposite to the detecting MEP's peer server MEP(s) after they are once generated. Their primary purpose is to suppress alarms in the MPLS-TP layer network above the level at which the defect occurs. The AIS message MAY be used to trigger recovery mechanisms.
These two OAM functions are all inter-layer functions. For P2MP LSP scenario, there are two kinds of situations:
- P2MP LSP as a client layer: The server layer which carries it is Section layer, or P2MP/P2P LSP SPME sub-layer. These two server layers have exactly the same treatment to the messages. Next, Section layer is introduced as an example. Section monitoring is running between two directly connected nodes, intention to detect bidirectional defects or administrative locking between them. When a node has detected above events, AIS or LKR messages will be immediately generated in the node and inserted into P2MP LSP client layer. Because the P2MP LSP is unidirectional, these two kinds of OAM messages are also unidirectional. They are forwarded along the direction of the P2MP LSP to notify the defect or administrative locking to all downstream sink MEPs of the node. These messages can suppress alarms in the downstream sink MEPs. The AIS message MAY be used to trigger recovery mechanisms.
- P2MP LSP as a server layer: The client layer carried above it can be PW, LSP, IP, etc layer. In this case, the sink MEPs of the P2MP LSP are the intermediate point of the above client layer. The defect or administrative locking of the unidirectional P2MP LSP detected in the sink MEPs will cause the generation of AIS or LKR messages and inserted them into the client layer. These messages are forwarded along the direction of the P2MP LSP to notify the defect or administrative locking to the end MEP of the client layer. These messages can suppress alarms in the end MEP of the client layer. The AIS message MAY be used to trigger recovery mechanisms.
The above contents analysis the AIS and LKR implementation in P2MP LSP. In general, the current AIS and LKR mechanism([I‑D.ietf‑mpls‑tp‑fault] (Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., Ward, D., Bryant, S., and S. Sivabalan, “MPLS Fault Management OAM,” July 2010.)) can apply to P2MP LSP without problem.
TOC |
3.3. On-demand Connectivity Verification and Route Tracing
On-demand CV(Connectivity Verification) enables an End Point to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP or Section, or is connected to specific Intermediate Point(s) by means of the expected PW, LSP.
On-demand Route Tracing enables an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP or Section, and more generally to trace the route of a PW, LSP or Section. The information collected MUST include identifiers related to the nodes and interfaces composing that route.
According to the OAM analysis, they can all be fully supported by Extending LSP Ping.
Currently, [I‑D.nitinb‑mpls‑tp‑lsp‑ping‑extensions] (Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “LSP-Ping extensions for MPLS-TP,” February 2010.) has already given the definitions and descriptions of how LSP Ping supports the above two on-demand OAM functions.
The process of these two OAM functions is basically the same, the echo request message is generated in source MEP, forwarded to the destination sink MEPs or MIPs. They return echo response with result after some processes. So, these two OAM functions all need return path. Because P2MP LSP is a unidirectional LSP without in band return path by itself, the return path is a key issue of these two OAM functions. The analysis about return path discussed in section 2.2 is applicable here.
On-demand CV function send OAM messages from source MEP to any MIPs or sink MEPs by using P2MP Node Indentifier TLV and proper TTL value. These OAM packets carry the TLVs(including source address TLV, MEP/MIP id TLV, etc) for connectivity verification. The destination nodes(MIPs or sink MEPs) use these TLVs for connectivity verification and return response message with result to source MEP.
Route Tracing is implemented by using Downstream Detailed Mapping TLV. This TLV can be used for transit, branch or bud node to return multiple Return Codes for different downstream paths.
[I‑D.ietf‑mpls‑p2mp‑lsp‑ping] (Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” March 2010.) has defined an extended LSP Ping mechanism for supporting MPLS P2MP scenarios. Whether this mechanism can be directly applied to MPLS-TP P2MP scenarios without problem or some new problems generated to be resolved needs further study.
TOC |
3.4. Diagnostic Tests
TOC |
3.4.1. Throughput Estimation
As specified in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” July 2010.), throughput estimation is an on-demand out-of-service function, which allows verifying the bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before it is put in-service. Throughput estimation is performed between MEPs and can be performed in one-way or two-way modes.
When applied to P2MP transport path, only one-way throughput estimation can be performed in case a return path exists. Also note that there are two options for throughput estimation on P2MP transport path, one is that respective throughput result can be obtained for each ME between the root and each specific leaf, another one is that only one throughput result can be obtained for the MEG between the root and all leaves. Just like throughput estimation in P2P transport path, two simple measurement methods can be used to estimate throughput in P2MP transport path, one is binary search method and another one is to increase sending rate (up to the theoretical maximum) of OAM test packets in fixed step until OAM test packets begin to drop.
For the option 1 that respective throughput result can be obtained for each ME, the two measurement methods mentioned above can be used in different way. When the binary search method is used, each independent throughput estimation process will be needed for each ME between the root and each specific leaf, which requires the source MEP to send a single OAM packet which contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and ignored by the other leaves. When the other method described above is used, only one throughput estimation process will be needed and also the individual throughput result will be obtained for each ME, also note that with this method the precision of measurement result is lower compared with the binary search method.
For the option 2 that only one throughput result can be obtained for the MEG, the two measurement methods mentioned above can be used in the same way. When the binary search method is used, like the other method that increase sending rate in fixed step, only one throughput estimation process will be needed for the MEG between the root and all leaves, which requires the source MEP to send a single OAM packet to all leaves and is processed by all leaves at the same time, and packet loss will be judged by emerging packet loss at any leaf.
TOC |
3.4.2. Data Plane Loopback
As specified in [I‑D.ietf‑mpls‑tp‑oam‑framework] (Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” July 2010.), data plane loopback is an out-of-service function, which permits all traffic (including user data and OAM except for the OAM used for this function) originated at the ingress of a transport path or inserted by the test equipment to be looped back in the direction of the point of origin by an interface at either an intermediate node or a terminating node.
Due to the specific function mechanism of data plane loopback, this function is applicable to co-routed bidirectional path when it's performed at an intermediate node, and applicable to co-routed bidirectional or associated bidirectional path when it's performed at an end node. So with P2MP path, it's only applicable at a leaf node in case an associated bidirectional path exists. Also note that when this function is performed with P2MP path, at any time only one leaf node can be set as loopback mode, otherwise the root can't distinguish from which leaf the received traffic is looped back.
TOC |
3.5. Lock Instruct
Lock Instruct function is a command which allows a MEP to instruct its peer MEP(s) to put a MPLS-TP transport path into a locked condition. This function allows single-side and two side provisions, only the former requires a lock instruct message be sent to the peer MEP(s).
For a P2MP transport path, there may be no return path to the lock instruct request MEP. So no response message is needed in this case, or can sends a response via a control plane protocol if the control plane exists. Under this situation, the peer MEP(s) should always accept the lock instruction.
Currently, there is no standardized mechanism defined in the IETF to support this function.
In general, the recommendation is to define a new tool and PDU to support Lock Instruct. Some material useful for this scope can be found in [I‑D.boutros‑mpls‑tp‑loopback] (Boutros, S., Sivabalan, S., Swallow, G., Ward, D., Bryant, S., Pignataro, C., Aggarwal, R., Bitar, N., Vigoureux, M., Busi, I., Levrau, L., and L. Ciavaglia, “Operating MPLS Transport Profile LSP in Loopback Mode,” March 2010.) and [I‑D.dai‑mpls‑tp‑lock‑instruct] (Dai, X., Bo, W., and J. Yang, “MPLS-TP Lock Instruction,” October 2009.).
TOC |
3.6. Client Failure Indication
The CFI function is used to propagate the information of a client's defect or fault condition through the MPLS-TP network from edge to edge in case the client layer OAM functionality does not provide an alarm notification function. This defect or fault is detected at and end point of a PW or LSP.
when used on a P2MP transport path, if this defect is detected by the root node, this CFI message will be sent through this P2MP path to all the leaves, and mapped to the associted ACs; however, if this defect is detected by a leaf node, this condition should also be propagated to the root node, so this requires a P2P return path from this leaf node to the root node.
Static PW status([I‑D.ietf‑pwe3‑static‑pw‑status] (Martini, L., Swallow, G., and M. Bocci, “Pseudowire Status for Static Pseudowires,” February 2010.)) can be used to perform this function on a PW . However, the peer node shoud identify it's a fault on the AC or on the PW. There is no mechanism defined in IETF to support this functionality for P2MP LSP.
So, It needs to define a new tool and PDU to support this functionality for CFI function in MPLS-TP P2MP scenarios. Some material useful for this scope can be found in [I‑D.he‑mpls‑tp‑csf] (Jia, H., Li, H., and E. Bellagamba, “Indication of Client Failure in MPLS-TP,” July 2010.) and [I‑D.ietf‑pwe3‑static‑pw‑status] (Martini, L., Swallow, G., and M. Bocci, “Pseudowire Status for Static Pseudowires,” February 2010.).
TOC |
3.7. Packet Loss Measurement
LM(Loss Measurement) is an OAM toolset which provides a function to enable the quantification of packet loss ratio over a PW, LSP or Section.
The Implementation of LM function in P2MP LSP is similar to which in P2P LSP. The source MEP send LM query messages periodically to all sink MEPs, every sink MEP uses a group of related counter values to calculate its own packet loss ratio. So, the LM mechanism defined and described in [I‑D.frost‑mpls‑tp‑loss‑delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” June 2010.) can be directly applied to MPLS-TP P2MP LSP.
The existed problems of LM function in P2P LSP such as message loss and packet misorder conditions and congestion also exist and are more serious in P2MP LSP. These questions all need a unified solution with P2P LSP.
For P2MP LSP, there is a specific requirement to support LM function in designated egress node of a P2MP LSP. This requirement can be implemented by setting proper P2MP Node Identifier TLV.
TOC |
3.8. Packet Delay Measurement
DM(Delay Measurement) is an OAM toolset which provides a function to enable the quantification of the one-way, and if appropriate, the two-way, delay of a PW, LSP or Section.
Unidirectional P2MP LSP can only implement one-way DM function. The mechanism is similar to which in P2P LSP. The source MEP send DM query messages with timestamp of sending time to all sink MEPs, every sink MEP can use the timestamp and the receiving time to calculate its own one-way delay. One-way DM function requires that the clocks of source MEP and all sink MEPs be synchronized. So, the on-way DM mechanism defined and described in [I‑D.frost‑mpls‑tp‑loss‑delay] (Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” June 2010.) can be directly applied to MPLS-TP P2MP LSP.
Like LM function, there is a specific requirement to support DM function in designated egress node of a P2MP LSP. This requirement can be implemented by setting proper P2MP Node Identifier TLV.
TOC |
4. P2MP PW analysis
To be added in a later version of this document.
TOC |
5. IANA Considerations
To be added in a later version of this document.
TOC |
6. Security Considerations
To be added in a later version of this document.
TOC |
7. Acknowledgements
To be added in a later version of this document.
TOC |
8. References
TOC |
8.1. Normative References
[I-D.boutros-mpls-tp-loopback] | Boutros, S., Sivabalan, S., Swallow, G., Ward, D., Bryant, S., Pignataro, C., Aggarwal, R., Bitar, N., Vigoureux, M., Busi, I., Levrau, L., and L. Ciavaglia, “Operating MPLS Transport Profile LSP in Loopback Mode,” draft-boutros-mpls-tp-loopback-03 (work in progress), March 2010 (TXT). |
[I-D.dai-mpls-tp-lock-instruct] | Dai, X., Bo, W., and J. Yang, “MPLS-TP Lock Instruction,” draft-dai-mpls-tp-lock-instruct-00 (work in progress), October 2009 (TXT). |
[I-D.farrel-mpls-tp-mip-mep-map] | Farrel, A. and H. Endo, “Handling MPLS-TP OAM Packets Targeted at Internal MIPs,” draft-farrel-mpls-tp-mip-mep-map-02 (work in progress), July 2010 (TXT). |
[I-D.frost-mpls-tp-loss-delay] | Frost, D. and S. Bryant, “Packet Loss and Delay Measurement for the MPLS Transport Profile,” draft-frost-mpls-tp-loss-delay-02 (work in progress), June 2010 (TXT). |
[I-D.he-mpls-tp-csf] | Jia, H., Li, H., and E. Bellagamba, “Indication of Client Failure in MPLS-TP,” draft-he-mpls-tp-csf-02 (work in progress), July 2010 (TXT). |
[I-D.ietf-mpls-ldp-p2mp] | Minei, I., Kompella, K., Wijnands, I., and B. Thomas, “Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths,” draft-ietf-mpls-ldp-p2mp-10 (work in progress), July 2010 (TXT). |
[I-D.ietf-mpls-p2mp-lsp-ping] | Yasukawa, S., Farrel, A., Ali, Z., Swallow, G., Nadeau, T., and S. Saxena, “Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping,” draft-ietf-mpls-p2mp-lsp-ping-10 (work in progress), March 2010 (TXT). |
[I-D.ietf-mpls-tp-cc-cv-rdi] | Allan, D., Drake, J., Swallow, G., Boutros, S., Sivabalan, S., and D. Ward, “Proactive Connection Verification, Continuity Check and Remote Defect indication for MPLS Transport Profile,” draft-ietf-mpls-tp-cc-cv-rdi-01 (work in progress), July 2010 (TXT). |
[I-D.ietf-mpls-tp-fault] | Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., Ward, D., Bryant, S., and S. Sivabalan, “MPLS Fault Management OAM,” draft-ietf-mpls-tp-fault-02 (work in progress), July 2010 (TXT). |
[I-D.ietf-mpls-tp-lsp-ping-bfd-procedures] | Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., Sprecher, N., and Y. Weingarten, “LSP-Ping and BFD encapsulation over ACH,” draft-ietf-mpls-tp-lsp-ping-bfd-procedures-00 (work in progress), March 2010 (TXT). |
[I-D.ietf-mpls-tp-oam-requirements] | Vigoureux, M. and D. Ward, “Requirements for OAM in MPLS Transport Networks,” draft-ietf-mpls-tp-oam-requirements-06 (work in progress), March 2010 (TXT). |
[I-D.ietf-pwe3-static-pw-status] | Martini, L., Swallow, G., and M. Bocci, “Pseudowire Status for Static Pseudowires,” draft-ietf-pwe3-static-pw-status-00 (work in progress), February 2010 (TXT). |
[I-D.nitinb-mpls-tp-lsp-ping-extensions] | Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, “LSP-Ping extensions for MPLS-TP,” draft-nitinb-mpls-tp-lsp-ping-extensions-01 (work in progress), February 2010 (TXT). |
[RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
[RFC4875] | Aggarwal, R., Papadimitriou, D., and S. Yasukawa, “Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs),” RFC 4875, May 2007 (TXT). |
[RFC5586] | Bocci, M., Vigoureux, M., and S. Bryant, “MPLS Generic Associated Channel,” RFC 5586, June 2009 (TXT). |
[RFC5654] | Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, “Requirements of an MPLS Transport Profile,” RFC 5654, September 2009 (TXT). |
[RFC5860] | Vigoureux, M., Ward, D., and M. Betts, “Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks,” RFC 5860, May 2010 (TXT). |
TOC |
8.2. Informative References
[I-D.ietf-mpls-tp-oam-analysis] | Sprecher, N., Bellagamba, E., and Y. Weingarten, “MPLS-TP OAM Analysis,” draft-ietf-mpls-tp-oam-analysis-02 (work in progress), July 2010 (TXT). |
[I-D.ietf-mpls-tp-oam-framework] | Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Mohan, D., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, “MPLS-TP OAM Framework,” draft-ietf-mpls-tp-oam-framework-07 (work in progress), July 2010 (TXT). |
[I-D.koike-ietf-mpls-tp-oam-maintenance-points] | Paul, M. and Y. Koike, “MPLS-TP OAM Maintenance Points,” draft-koike-ietf-mpls-tp-oam-maintenance-points-01 (work in progress), March 2010 (TXT). |
[RFC4461] | Yasukawa, S., “Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs),” RFC 4461, April 2006 (TXT). |
[RFC4687] | Yasukawa, S., Farrel, A., King, D., and T. Nadeau, “Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks,” RFC 4687, September 2006 (TXT). |
TOC |
Authors' Addresses
Liang Xia | |
ZTE Corporation | |
Email: | xia.liang2@zte.com.cn |
Min Xiao | |
ZTE Corporation | |
Email: | xiao.min2@zte.com.cn |
XueHui Dai | |
ZTE Corporation | |
Email: | dai.xuehui@zte.com.cn |
Jian Yang | |
ZTE Corporation | |
Email: | yang_jian@zte.com.cn |