RFC 6371
Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks
4. Reference Model
The reference model for the MPLS-TP OAM framework builds upon the concept of a MEG, and its associated MEPs and MIPs, to support the functional requirements specified in RFC 5860 [11]. The following MPLS-TP MEGs are specified in this document: o A Section Maintenance Entity Group (SMEG), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).
o An LSP Maintenance Entity Group (LMEG), allowing monitoring and
management of an end-to-end LSP (between LERs).
o A PW Maintenance Entity Group (PMEG), allowing monitoring and
management of an end-to-end Single-Segment Pseudowire (SS-PW) or
MS-PW (between T-PEs).
o An LSP SPME ME Group (LSMEG), allowing monitoring and management
of an SPME (between a given pair of LERs and/or LSRs along an
LSP).
o A PW SPME ME Group (PSMEG), allowing monitoring and management of
an SPME (between a given pair of T-PEs and/or S-PEs along an
(MS-)PW).
The MEGs specified in this MPLS-TP OAM framework are compliant with
the architecture framework for MPLS-TP [8] that includes both MS-PWs
[4] and LSPs [1].
Hierarchical LSPs are also supported in the form of SPMEs. In this
case, each LSP in the hierarchy is a different sub-layer network that
can be monitored, independently from higher- and lower-level LSPs in
the hierarchy, on an end-to-end basis (from LER to LER) by an SPME.
It is possible to monitor a portion of a hierarchical LSP by
instantiating a hierarchical SPME between any LERs/LSRs along the
hierarchical LSP.
Native |<------------------ MS-PW1Z ---------------->| Native Layer | | Layer Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service (AC1) V V V V V V V V (AC2) +----+ +---+ +----+ +----+ +---+ +----+ +----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+ | | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | | | |=======| |=========| |=======| | | | | CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 | | | | |=======| |=========| |=======| | | | | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | +----+ +----+ +---+ +----+ +----+ +---+ +----+ . . . . | | | | |<--- Domain 1 -->| |<--- Domain Z -->| ^----------------- PW1Z PMEG ----------------^ ^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^ ^-------^ ^-------^ LSP13 LMEG LSPXZ LMEG ^--^ ^--^ ^---------^ ^--^ ^--^ Sec12 Sec23 Sec3X SecXY SecYZ SMEG SMEG SMEG SMEG SMEG ^---^ ME ^ MEP ==== LSP .... PW T-PE 1: Terminating Provider Edge 1 LSR 2: Label Switching Router 2 S-PE 3: Switching Provider Edge 3 S-PE X: Switching Provider Edge X LSR Y: Label Switching Router Y T-PE Z: Terminating Provider Edge Z Figure 5: Reference Model for the MPLS-TP OAM Framework Figure 5 depicts a high-level reference model for the MPLS-TP OAM framework. The figure depicts portions of two MPLS-TP-enabled network domains, Domain 1 and Domain Z. In Domain 1, T-PE 1 is adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is adjacent to S-PE 3 via the MPLS-TP Section Sec23. Similarly, in Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY, and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ. In addition, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.
Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on T-PE1 and AC2 on T-PE Z. The MS-PW consists of three bidirectional PW path segments: 1) PW13 path segment between T-PE 1 and S-PE 3 via the bidirectional LSP13 LSP, 2) PW3X path segment between S-PE 3 and S-PE X via the bidirectional LSP3X LSP, and 3) PWXZ path segment between S-PE X and T-PE Z via the bidirectional LSPXZ LSP. The MPLS-TP OAM procedures that apply to a MEG are expected to operate independently from procedures on other MEGs. Yet, this does not preclude that multiple MEGs may be affected simultaneously by the same network condition -- for example, a fiber cut event. Note that there are no constraints imposed by this OAM framework on the number or type (P2P, P2MP, LSP, or PW), of MEGs that may be instantiated on a particular node. In particular, when looking at Figure 5, it should be possible to configure one or more MEPs on the same node if that node is the end point of one or more MEGs. Figure 5 does not describe a PW3X PSMEG because typically SPMEs are used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) rather than the segment between two OAM domains. However, the OAM framework does not pose any constraints on the way SPMEs are instantiated as long as they are not overlapping. The subsections below define the MEGs specified in this MPLS-TP OAM architecture framework document. Unless otherwise stated, all references to domains, LSRs, MPLS-TP Sections, LSPs, pseudowires, and MEGs in this section are made in relation to those shown in Figure 5.4.1. MPLS-TP Section Monitoring (SMEG)
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity intended to monitor an MPLS-TP Section. An SMEG may be configured on any MPLS-TP section. SMEG OAM packets must fate-share with the user data packets sent over the monitored MPLS-TP Section. An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent (next hop in this layer network) MPLS-TP LSRs rather than monitoring the individual LSP or PW path segments traversing the MPLS-TP Section and where the server-layer technology does not provide adequate OAM capabilities.
Figure 5 shows five Section MEGs configured in the network between AC1 and AC2: 1. Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and LSR 2, 2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and S-PE 3, 3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and S-PE X, 4. SecXY MEG associated with the MPLS-TP Section between S-PE X and LSR Y, and 5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and T-PE Z4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG)
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group intended to monitor an end-to-end LSP between its LERs. An LMEG may be configured on any MPLS LSP. LMEG OAM packets must fate-share with user data packets sent over the monitored MPLS-TP LSP. An LMEG is intended to be deployed in scenarios where it is desirable to monitor an entire LSP between its LERs, rather than, say, monitoring individual PWs. Figure 5 depicts two LMEGs configured in the network between AC1 and AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ LMEG between S-PE X and T-PE Z. Note that the presence of a LSP3X LMEG in such a configuration is optional, and hence, not precluded by this framework. For instance, the network operator may prefer to monitor the MPLS-TP Section between the two LSRs rather than the individual LSPs.4.3. MPLS-TP PW Monitoring (PMEG)
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG can be configured on any SS-PW or MS-PW. PMEG OAM packets must fate-share with the user data packets sent over the monitored PW. A PMEG is intended to be deployed in scenarios where it is desirable to monitor an entire PW between a pair of MPLS-TP-enabled T-PEs rather than monitoring the LSP that aggregates multiple PWs between PEs.
Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z PMEG).4.4. MPLS-TP LSP SPME Monitoring (LSMEG)
An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an LSP between the MEPs instantiated for the SPME, independent from the end-to-end monitoring (LMEG). An LSMEG can monitor an LSP path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. When an SPME is established between non-adjacent LSRs, the edges of the SPME become adjacent at the LSP sub-layer network and any LSR that was previously in between becomes an LSR for the SPME. Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG OAM packets must fate-share with the user data packets sent over the monitored LSP path segment. A LSME can be defined between the following entities: o The LER and LSR of a given LSP. o Any two LSRs of a given LSP. An LSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an LSP or set of LSPs rather than the entire LSP itself, for example, when there is a need to monitor a part of an LSP that extends beyond the administrative boundaries of an MPLS-TP-enabled administrative domain.
|<-------------------- PW1Z ------------------->| | | | |<-------------LSP1Z LSP------------->| | | |<-LSP13->| |<LSP3X>| |<-LSPXZ->| | V V V V V V V V +----+ +---+ +----+ +----+ +---+ +----+ +----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+ | | | 1 | | 2 | | 3 | | X | | Y | | Z | | | | |AC1| |=====================================| |AC2| | | CE1|---|.....................PW1Z......................|---|CE2 | | | | |=====================================| | | | | | | | | | | | | | | | | | | | +----+ | | | | | | | | | | | | +----+ +----+ +---+ +----+ +----+ +---+ +----+ . . . . | | | | |<---- Domain 1 --->| |<---- Domain Z --->| ^---------^ ^---------^ LSP13 LSMEG LSPXZ LSMEG ^-------------------------------------^ LSP1Z LMEG DBN: Domain Border Node PE 1: Provider Edge 1 LSR 2: Label Switching Router 2 DBN 3: Domain Border Node 3 DBN X: Domain Border Node X LSR Y: Label Switching Router Y PE Z: Provider Edge Z Figure 6: MPLS-TP LSP SPME MEG (LSMEG) Figure 6 depicts a variation of the reference model in Figure 5 where there is an end-to-end LSP (LSP1Z) between PE 1 and PE Z. LSP1Z consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X, and LSPXZ. In this scenario, there are two separate LSMEGs configured to monitor the LSP1Z: 1) a LSMEG monitoring the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) a LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG). It is worth noticing that LSMEGs can coexist with the LMEG monitoring the end-to-end LSP and that LSMEG MEPs and LMEG MEPs can be coincident in the same node (e.g., PE 1 node supports both the LSP1Z LMEG MEP and the LSP13 LSMEG MEP).
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG)
An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an MS-PW between the MEPs instantiated for the SPME, independently of the end-to-end monitoring (PMEG). A PSMEG can monitor a PW path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. A PSMEG is no different than an SPME; it is simply named as such to discuss SPMEs specifically in a PW context. When SPME is established between non-adjacent S-PEs, the edges of the SPME become adjacent at the MS-PW sub-layer network, and any S-PE that was previously in between becomes an LSR for the SPME. S-PE placement is typically dictated by considerations other than OAM. S-PEs will frequently reside at operational boundaries such as the transition from distributed control plane (CP) to centralized Network Management System (NMS) control or at a routing area boundary. As such, the architecture would appear not to have the flexibility that arbitrary placement of SPME segments would imply. Support for an arbitrary placement of PSMEG would require the definition of additional PW sub-layering. Multiple hierarchical PSMEGs can be configured on any MS-PW. PSMEG OAM packets fate-share with the user data packets sent over the monitored PW path Segment. A PSMEG does not add hierarchical components to the MPLS architecture; it defines the role of existing components for the purposes of discussing OAM functionality. A PSME can be defined between the following entities: o The T-PE and any S-PE of a given MS-PW. o Any two S-PEs of a given MS-PW. Note that, in line with the SPME description in Section 3.2, when a PW SPME is instantiated after the MS-PW has been instantiated, the TTL distance of the MIPs may change and MIPs in the PW SPME are no longer part of the encompassing MEG. This means that the S-PE nodes hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP level. The consequences are that the S-PEs hosting the PSMEG MEPs become adjacent S-PEs. This is no different than the operation of SPMEs in general. A PSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an MS-PW rather than the entire end-to-end PW itself, for example, when monitoring an MS-
PW path segment within a given network domain of an inter-domain MS- PW. Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments: PW13, PW3X, and PWXZ with two separate PSMEGs: 1) a PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG) and 2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ PSMEG). It is worth noticing that PSMEGs can coexist with the PMEG monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG MEPs can be coincident in the same node (e.g., T-PE 1 node supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP).4.6. Fate-Sharing Considerations for Multilink
Multilink techniques are in use today and are expected to continue to be used in future deployments. These techniques include Ethernet link aggregation [22] and the use of link bundling for MPLS [18] where the option to spread traffic over component links is supported and enabled. While the use of link bundling can be controlled at the MPLS-TP layer, use of link aggregation (or any server-layer-specific multilink) is not necessarily under the control of the MPLS-TP layer. Other techniques may emerge in the future. These techniques frequently share the characteristic that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs). The use of multilink techniques may be prohibited or permitted in any particular deployment. If multilink techniques are used, the deployment can be considered to be only partially MPLS-TP compliant; however, this is unlikely to prevent their use. The implications for OAM are that not all components of a multilink will be exercised, independent server-layer OAM being required to exercise the aggregated link components. This has further implications for MIP and MEP placement, as per-interface MIPs or Down MEPs on a multilink interface are akin to a layer violation, as they instrument at the granularity of the server layer. The implications for reduced OAM loss measurement functionality are documented in Sections 5.5.3 and 6.2.3.
5. OAM Functions for Proactive Monitoring
In this document, proactive monitoring refers to OAM operations that are either configured to be carried out periodically and continuously or preconfigured to act on certain events such as alarm signals. Proactive monitoring is usually performed "in-service". Such transactions are universally MEP to MEP in operation, while notifications can be node to node (e.g., some MS-PW transactions) or node to MEPs (e.g., AIS). The control and measurement considerations are: 1. Proactive monitoring for a MEG is typically configured at the creation time of the transport path. 2. The operational characteristics of in-band measurement transactions (e.g., CV, Loss Measurement (LM), etc.) are configured at the MEPs. 3. Server-layer events are reported by OAM packets originating at intermediate nodes. 4. The measurements resulting from proactive monitoring are typically reported outside of the MEG (e.g., to a management system) as notification events such as faults or indications of performance degradations (such as signal degrade conditions). 5. The measurements resulting from proactive monitoring may be periodically harvested by an NMS. Proactive fault reporting is assumed to be subject to unreliable delivery and soft-state, and it needs to operate in cases where a return path is not available or faulty. Therefore, periodic repetition is assumed to be used for reliability, instead of handshaking. Delay measurement also requires periodic repetition to allow estimation of the packet delay variation for the MEG. For statically provisioned transport paths, the above information is statically configured; for dynamically established transport paths, the configuration information is signaled via the control plane or configured via the management plane. The operator may enable/disable some of the consequent actions defined in Section 5.1.2.
5.1. Continuity Check and Connectivity Verification
Proactive Continuity Check functions, as required in Section 2.2.2 of RFC 5860 [11], are used to detect a loss of continuity (LOC) defect between two MEPs in a MEG. Proactive Connectivity Verification functions, as required in Section 2.2.3 of RFC 5860 [11], are used to detect an unexpected connectivity defect between two MEGs (e.g., mismerging or misconnection), as well as unexpected connectivity within the MEG with an unexpected MEP. Both functions are based on the (proactive) generation, at the same rate, of OAM packets by the source MEP that are processed by the peer sink MEP(s). As a consequence, in order to save OAM bandwidth consumption, CV, when used, is linked with CC into Continuity Check and Connectivity Verification (CC-V) OAM packets. In order to perform proactive Connectivity Verification, each CC-V OAM packet also includes a globally unique Source MEP identifier, whose value needs to be configured on the source MEP and on the peer sink MEP(s). In some cases, to avoid the need to configure the globally unique Source MEP identifier, it is preferable to perform only proactive Continuity Check. In this case, the CC-V OAM packet does not need to include any globally unique Source MEP identifier. Therefore, a MEG can be monitored only for CC or for both CC and CV. CC-V OAM packets used for CC-only monitoring are called CC OAM packets, while CC-V OAM packets used for both CC and CV are called CV OAM packets. As a consequence, it is not possible to detect misconnections between two MEGs monitored only for continuity as neither the OAM packet type nor the OAM packet content provides sufficient information to disambiguate an invalid source. To expand: o For a CC OAM packet leaking into a CC monitored MEG - undetectable. o For a CV OAM packet leaking into a CC monitored MEG - reception of CV OAM packets instead of a CC OAM packets (e.g., with the additional Source MEP identifier) allows detecting the fault. o For a CC OAM packet leaking into a CV monitored MEG - reception of CC OAM packets instead of CV OAM packets (e.g., lack of additional Source MEP identifier) allows detecting the fault. o For a CV OAM packet leaking into a CV monitored MEG - reception of CV OAM packets with different Source MEP identifier permits fault to be identified.
Having a common packet format for CC-V OAM packets would simplify parsing in a sink MEP to properly detect all the misconfiguration cases described above. MPLS-TP OAM supports different formats of MEP identifiers to address different environments. When an alternative to IP addressing is desired (e.g., MPLS-TP is deployed in transport network environments where consistent operations with other transport technologies defined by the ITU-T are required), the ITU Carrier Code (ICC)-based format for MEP identification is used: this format is under definition in [25]. When MPLS-TP is deployed in an environment where IP capabilities are available and desired for OAM, the IP-based MEP identification is used: this format is described in [24]. CC-V OAM packets are transmitted at a regular, operator-configurable rate. The default CC-V transmission periods are application dependent (see Section 5.1.3). Proactive CC-V OAM packets are transmitted with the "minimum loss probability PHB" within the transport path (LSP, PW) they are monitoring. For E-LSPs, this PHB is configurable on the network operator's basis, while for L-LSPs this is determined as per RFC 3270 [23]. PHBs can be translated at the network borders by the same function that translates them for user data traffic. The implication is that CC-V fate-shares with much of the forwarding implementation, but not all aspects of PHB processing are exercised. Either on- demand tools are used for finer-grained fault finding or an implementation may utilize a CC-V flow per PHB to ensure a CC-V flow fate-shares with each individual PHB. In a co-routed or associated, bidirectional point-to-point transport path, when a MEP is enabled to generate proactive CC-V OAM packets with a configured transmission rate, it also expects to receive proactive CC-V OAM packets from its peer MEP at the same transmission rate. This is because a common SLA applies to all components of the transport path. In a unidirectional transport path (either point-to- point or point-to-multipoint), the source MEP is enabled only to generate CC-V OAM packets, while each sink MEP is configured to expect these packets at the configured rate. MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are transparent to the proactive CC-V information and forward these proactive CC-V OAM packets as regular data packets. During path setup and tear down, situations arise where CC-V checks would give rise to alarms, as the path is not fully instantiated. In order to avoid these spurious alarms, the following procedures are recommended. At initialization, the source MEP function (generating
proactive CC-V packets) should be enabled prior to the corresponding sink MEP function (detecting continuity and connectivity defects). When disabling the CC-V proactive functionality, the sink MEP function should be disabled prior to the corresponding source MEP function. It should be noted that different encapsulations are possible for CC-V packets, and therefore it is possible that in case of misconfigurations or mis-connectivity, CC-V packets are received with an unexpected encapsulation. There are practical limitations to detecting unexpected encapsulation. It is possible that there are misconfiguration or mis-connectivity scenarios where OAM packets can alias as payload, e.g., when a transport path can carry an arbitrary payload without a pseudowire. When CC-V packets are received with an unexpected encapsulation that can be parsed by a sink MEP, the CC-V packet is processed as if it were received with the correct encapsulation. If it is not a manifestation of a mis-connectivity defect, a warning is raised (see Section 5.1.1.4). Otherwise, the CC-V packet may be silently discarded as unrecognized and a LOC defect may be detected (see Section 5.1.1.1). The defect conditions are described in no specific order.5.1.1. Defects Identified by CC-V
Proactive CC-V functions allow a sink MEP to detect the defect conditions described in the following subsections. For all of the described defect cases, a sink MEP should notify the equipment fault management process of the detected defect. Sequential consecutive loss of CC-V packets is considered indicative of an actual break and not of congestive loss or physical-layer degradation. The loss of 3 packets in a row (implying a detection interval that is 3.5 times the insertion time) is interpreted as a true break and a condition that will not clear by itself. A CC-V OAM packet is considered to carry an unexpected globally unique Source MEP identifier if it is a CC OAM packet received by a sink MEP monitoring the MEG for CV; it is a CV OAM packet received by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV but carrying a unique Source MEP identifier that is different that the expected one. Conversely, the CC-V packet is considered to have an expected globally unique Source MEP identifier; it is a CC OAM packet received
by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV and carrying a unique Source MEP identifier that is equal to the expected one.5.1.1.1. Loss of Continuity Defect
When proactive CC-V is enabled, a sink MEP detects a loss of continuity (LOC) defect when it fails to receive proactive CC-V OAM packets from the source MEP. o Entry criteria: If no proactive CC-V OAM packets from the source MEP (and in the case of CV, this includes the requirement to have the expected globally unique Source MEP identifier) are received within the interval equal to 3.5 times the receiving MEP's configured CC-V reception period. o Exit criteria: A proactive CC-V OAM packet from the source MEP (and again in the case of CV, with the expected globally unique Source MEP identifier) is received.5.1.1.2. Mis-Connectivity Defect
When a proactive CC-V OAM packet is received, a sink MEP identifies a mis-connectivity defect (e.g., mismerge, misconnection, or unintended looping) when the received packet carries an unexpected globally unique Source MEP identifier. o Entry criteria: The sink MEP receives a proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier or with an unexpected encapsulation. o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with an unexpected globally unique Source MEP identifier since this defect has been raised. This requires the OAM packet to self-identify the CC-V periodicity, as not all MEPs can be expected to have knowledge of all MEGs.5.1.1.3. Period Misconfiguration Defect
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected.
o Entry criteria: A MEP receives a CC-V proactive packet with the
expected globally unique Source MEP identifier but with a
transmission period different than its own CC-V-configured
transmission period.
o Exit criteria: The sink MEP does not receive any proactive CC-V
OAM packet with the expected globally unique Source MEP identifier
and an incorrect transmission period for an interval equal at
least to 3.5 times the longest transmission period of the
proactive CC-V OAM packets received with the expected globally
unique Source MEP identifier and an incorrect transmission period
since this defect has been raised.
5.1.1.4. Unexpected Encapsulation Defect
If proactive CC-V OAM packets are received with the expected globally
unique Source MEP identifier but with an unexpected encapsulation,
then a CC-V unexpected encapsulation defect is detected.
It should be noted that there are practical limitations to detecting
unexpected encapsulation (see Section 5.1.1).
o Entry criteria: A MEP receives a CC-V proactive packet with the
expected globally unique Source MEP identifier but with an
unexpected encapsulation.
o Exit criteria: The sink MEP does not receive any proactive CC-V
OAM packet with the expected globally unique Source MEP identifier
and an unexpected encapsulation for an interval equal at least to
3.5 times the longest transmission period of the proactive CC-V
OAM packets received with the expected globally unique Source MEP
identifier and an unexpected encapsulation since this defect has
been raised.
5.1.2. Consequent Action
A sink MEP that detects any of the defect conditions defined in
Section 5.1.1 declares a defect condition and performs the following
consequent actions.
If a MEP detects a mis-connectivity defect, it blocks all the traffic
(including also the user data packets) that it receives from the
misconnected transport path.
If a MEP detects a LOC defect that is not caused by a period
misconfiguration, it should block all the traffic (including also the
user data packets) that it receives from the transport path, if this
consequent action has been enabled by the operator.
It is worth noticing that the OAM requirements document [11] recommends that CC-V proactive monitoring be enabled on every MEG in order to reliably detect connectivity defects. However, CC-V proactive monitoring can be disabled by an operator for a MEG. In the event of a misconnection between a transport path that is proactively monitored for CC-V and a transport path that is not, the MEP of the former transport path will detect a LOC defect representing a connectivity problem (e.g., a misconnection with a transport path where CC-V proactive monitoring is not enabled) instead of a continuity problem, with a consequence of delivery of traffic to an incorrect destination. For these reasons, the traffic block consequent action is applied even when a LOC condition occurs. This block consequent action can be disabled through configuration. This deactivation of the block action may be used for activating or deactivating the monitoring when it is not possible to synchronize the function activation of the two peer MEPs. If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity defect (Section 5.1.1.2), it declares a signal fail condition of the ME. It is a matter of local policy whether or not a MEP that detects a period misconfiguration defect (Section 5.1.1.3) declares a signal fail condition of the ME. The detection of an unexpected encapsulation defect does not have any consequent action: it is just a warning for the network operator. An implementation able to detect an unexpected encapsulation but not able to verify the source MEP ID may choose to declare a mis- connectivity defect.5.1.3. Configuration Considerations
At all MEPs inside a MEG, the following configuration information needs to be configured when a proactive CC-V function is enabled: o MEG-ID: the MEG identifier to which the MEP belongs. o MEP-ID: the MEP's own identity inside the MEG. o list of the other MEPs in the MEG. For a point-to-point MEG, the list would consist of the single MEP ID from which the OAM packets are expected. In case of the root MEP of a P2MP MEG, the list is composed of all the leaf MEP IDs inside the MEG. In case of the leaf MEP of a P2MP MEG, the list is composed of the root MEP ID (i.e., each leaf needs to know the root MEP ID from which it expects to receive the CC-V OAM packets).
o PHB for E-LSPs. It identifies the per-hop behavior of a CC-V
packet. Proactive CC-V packets are transmitted with the "minimum
loss probability PHB" previously configured within a single
network operator. This PHB is configurable on network operator's
basis. PHBs can be translated at the network borders.
o transmission rate. The default CC-V transmission periods are
application dependent (depending on whether they are used to
support fault management, performance monitoring, or protection-
switching applications):
* Fault Management: default transmission period is 1 s (i.e.,
transmission rate of 1 packet/second).
* Performance Management: default transmission period is 100 ms
(i.e., transmission rate of 10 packets/second). CC-V
contributes to the accuracy of performance monitoring
statistics by permitting the defect-free periods to be properly
distinguished as described in Sections 5.5.1 and 5.6.1.
* Protection Switching: If protection switching with CC-V, defect
entry criteria of 12 ms is required (for example, in
conjunction with the requirement to support 50 ms recovery time
as indicated in RFC 5654 [5]), then an implementation should
use a default transmission period of 3.33 ms (i.e.,
transmission rate of 300 packets/second). Sometimes, the
requirement of 50 ms recovery time is associated with the
requirement for a CC-V defect entry criteria period of 35 ms;
in these cases a transmission period of 10 ms (i.e.,
transmission rate of 100 packets/second) can be used.
Furthermore, when there is no need for so small CC-V defect
entry criteria periods, a larger transmission period can be
used.
It should be possible for the operator to configure these
transmission rates for all applications, to satisfy specific network
requirements.
Note that the reception period is the same as the configured
transmission rate.
For management-provisioned transport paths, the above parameters are
statically configured; for dynamically signaled transport paths, the
configuration information is distributed via the control plane.
The operator should be able to enable/disable some of the consequent
actions. Which consequent actions can be enabled/disabled is
described in Section 5.1.2.
5.2. Remote Defect Indication
The Remote Defect Indication (RDI) function, as required in Section 2.2.9 of RFC 5860 [11], is an indicator that is transmitted by a sink MEP to communicate to its source MEP that a signal fail condition exists. In case of co-routed and associated bidirectional transport paths, RDI is associated with proactive CC-V, and the RDI indicator can be piggy-backed onto the CC-V packet. In case of unidirectional transport paths, the RDI indicator can be sent only using an out-of- band return path if it exists and its usage is enabled by policy actions. When a MEP detects a signal fail condition (e.g., in case of a continuity or connectivity defect), it should begin transmitting an RDI indicator to its peer MEP. When incorporated into CC-V, the RDI information will be included in all proactive CC-V packets that it generates for the duration of the signal fail condition's existence. A MEP that receives packets from a peer MEP with the RDI information should determine that its peer MEP has encountered a defect condition associated with a signal fail condition. MIPs as well as intermediate nodes not supporting MPLS-TP OAM are transparent to the RDI indicator and forward OAM packets that include the RDI indicator as regular data packets, i.e., the MIP should not perform any actions nor examine the indicator. When the signal fail condition clears, the MEP should stop transmitting the RDI indicator to its peer MEP. When incorporated into CC-V, the RDI indicator will not be set for subsequent transmission of proactive CC-V packets. A MEP should clear the RDI defect upon reception of an RDI indicator cleared.5.2.1. Configuration Considerations
In order to support RDI, the indication may be carried in a unique OAM packet or may be embedded in a CC-V packet. The in-band RDI transmission rate and PHB of the OAM packets carrying RDIs should be the same as that configured for CC-V to allow both far-end and near- end defect conditions being resolved in a timeframe that has the same order of magnitude. This timeframe is application specific as described in Section 5.1.3. Methods of the out-of-band return paths will dictate how out-of-band RDIs are transmitted.
5.3. Alarm Reporting
The Alarm Reporting function, as required in Section 2.2.8 of RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) packet to suppress alarms following detection of defect conditions at the server (sub-)layer. When a server MEP asserts a signal fail condition, it notifies that to the co-located MPLS-TP client/server adaptation function that then generates OAM packets with AIS information in the downstream direction to allow the suppression of secondary alarms at the MPLS-TP MEP in the client (sub-)layer. The generation of packets with AIS information starts immediately when the server MEP asserts a signal fail condition. These periodic OAM packets, with AIS information, continue to be transmitted until the signal fail condition is cleared. It is assumed that to avoid spurious alarm generation a MEP detecting a loss of continuity defect (see Section 5.1.1.1) will wait for a hold-off interval prior to asserting an alarm to the management system. Therefore, upon receiving an OAM packet with AIS information, an MPLS-TP MEP enters an AIS defect condition and suppresses reporting of alarms to the NMS on the loss of continuity with its peer MEP, but it does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of AIS condition. MIPs, as well as intermediate nodes, do not process AIS information and forward these AIS OAM packets as regular data packets. For example, let's consider a fiber cut between T-PE 1 and LSR 2 in the reference network of Figure 5. Assuming that all of the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of Sec12 SMEG, LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network, only the alarm associated to the fiber cut needs to be reported to an NMS, while all secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms). If the fiber cut is detected by the MEP in the physical layer (in LSR 2), LSR 2 can generate the proper alarm in the physical layer and suppress the secondary alarm associated with the LOC defect detected on Sec12 SMEG. As both MEPs reside within the same node, this process does not involve any external protocol exchange. Otherwise,
if the physical layer does not have enough OAM capabilities to detect the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC alarm. In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates AIS packets on the LSP13 LMEG in order to allow its MEP in S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm. The generation of AIS packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the AIS generation). The AIS condition is cleared if no AIS packet has been received in 3.5 times the AIS transmission period. The AIS transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established. AIS packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].5.4. Lock Reporting
The Lock Reporting function, as required in Section 2.2.7 of RFC 5860 [11], relies upon a Lock Report (LKR) packet used to suppress alarms following administrative locking action in the server (sub-)layer. When a server MEP is locked, the MPLS-TP client (sub-)layer adaptation function generates packets with LKR information to allow the suppression of secondary alarms at the MEPs in the client (sub-)layer. Again, it is assumed that there is a hold-off for any loss of continuity alarms in the client-layer MEPs downstream of the node originating the Lock Report. In case of client (sub-)layer co- routed bidirectional transport paths, the LKR information is sent on both directions. In case of client (sub-)layer unidirectional transport paths, the LKR information is sent only in the downstream direction. As a consequence, in case of client (sub-)layer point-to- multipoint transport paths, the LKR information is sent only to the
MEPs that are downstream from the server (sub-)layer that has been administratively locked. Client (sub-)layer associated bidirectional transport paths behave like co-routed bidirectional transport paths if the server (sub-)layer that has been administratively locked is used by both directions; otherwise, they behave like unidirectional transport paths. The generation of packets with LKR information starts immediately when the server MEP is locked. These periodic packets, with LKR information, continue to be transmitted until the locked condition is cleared. Upon receiving a packet with LKR information, an MPLS-TP MEP enters an LKR defect condition and suppresses the loss of continuity alarm associated with its peer MEP but does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of the LKR condition. MIPs, as well as intermediate nodes, do not process the LKR information; they forward these LKR OAM packets as regular data packets. For example, let's consider the case where the MPLS-TP Section between T-PE 1 and LSR 2 in the reference network of Figure 5 is administratively locked at LSR 2 (in both directions). Assuming that all the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network all these secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms). The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates LKR packets on the LSP13 LMEG in order to allow its MEPs in T-PE 1 and S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm. The generation of LKR packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the LKR generation).
The locked condition is cleared if no LKR packet has been received for 3.5 times the transmission period. The LKR transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established. LKR packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].5.5. Packet Loss Measurement
Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring (PM) function in order to facilitate reporting of Quality of Service (QoS) information for a transport path as required in Section 2.2.11 of RFC 5860 [11]. LM is used to exchange counter values for the number of ingress and egress packets transmitted and received by the transport path monitored by a pair of MEPs. Proactive LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during the lifetime of the transport path. Each MEP performs measurements of its transmitted and received user data packets. These measurements are then correlated in real time with the peer MEP in the ME to derive the impact of packet loss on a number of performance metrics for the ME in the MEG. The LM transactions are issued such that the OAM packets will experience the same PHB scheduling class as the measured traffic while transiting between the MEPs in the ME. For a MEP, near-end packet loss refers to packet loss associated with incoming data packets (from the far-end MEP), while far-end packet loss refers to packet loss associated with egress data packets (towards the far-end MEP). Proactive LM can be operated in two ways: o One-way: a MEP sends an LM OAM packet to its peer MEP containing all the required information to facilitate near-end packet loss measurements at the peer MEP. o Two-way: a MEP sends an LM OAM packet with an LM request to its peer MEP, which replies with an LM OAM packet as an LM response. The request/response LM OAM packets contain all the required
information to facilitate both near-end and far-end packet loss
measurements from the viewpoint of the originating MEP.
One-way LM is applicable to both unidirectional and bidirectional
(co-routed or associated) transport paths, while two-way LM is
applicable only to bidirectional (co-routed or associated) transport
paths.
MIPs, as well as intermediate nodes, do not process the LM
information; they forward these proactive LM OAM packets as regular
data packets.
5.5.1. Configuration Considerations
In order to support proactive LM, the transmission rate and, for
E-LSPs, the PHB class (associated with the LM OAM packets originating
from a MEP) need to be configured as part of the LM provisioning. LM
OAM packets should be transmitted with the PHB that yields the lowest
drop precedence within the measured PHB Scheduling Class (see RFC
3260 [17]), in order to maximize reliability of measurement within
the traffic class.
If that PHB class is not an ordered aggregate where the ordering
constraint is all packets with the PHB class being delivered in
order, LM can produce inconsistent results.
Performance monitoring (e.g., LM) is only relevant when the transport
path is defect free. CC-V contributes to the accuracy of PM
statistics by permitting the defect-free periods to be properly
distinguished. Therefore, support of proactive LM has implications
on the CC-V transmission period (see Section 5.1.3).
5.5.2. Sampling Skew
If an implementation makes use of a hardware forwarding path that
operates in parallel with an OAM processing path, whether hardware or
software based, the packet and byte counts may be skewed if one or
more packets can be processed before the OAM processing samples
counters. If OAM is implemented in software, this error can be quite
large.
5.5.3. Multilink Issues
If multilink is used at the ingress or egress of a transport path,
there may not be a single packet-processing engine where an LM packet
can be injected or extracted as an atomic operation while having
accurate packet and byte counts associated with the packet.
In the case where multilink is encountered along the route of the transport path, the reordering of packets within the transport path can cause inaccurate LM results.5.6. Packet Delay Measurement
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function in order to facilitate reporting of QoS information for a transport path as required in Section 2.2.12 of RFC 5860 [11]. Specifically, proactive DM is used to measure the long- term packet delay and packet delay variation in the transport path monitored by a pair of MEPs. Proactive DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval. Proactive DM can be operated in two ways: o One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP by means outside the scope of this framework. o Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP. One-way DM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way DM is applicable only to bidirectional (co-routed or associated) transport paths. MIPs, as well as intermediate nodes, do not process the DM information; they forward these proactive DM OAM packets as regular data packets.5.6.1. Configuration Considerations
In order to support proactive DM, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. DM OAM packets should be transmitted with the PHB that yields the lowest
drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]). Performance monitoring (e.g., DM) is only relevant when the transport path is defect free. CC-V contributes to the accuracy of PM statistics by permitting the defect-free periods to be properly distinguished. Therefore, support of proactive DM has implications on the CC-V transmission period (see Section 5.1.3).5.7. Client Failure Indication
The Client Failure Indication (CFI) function, as required in Section 2.2.10 of RFC 5860 [11], is used to help process client defects and propagate a client signal defect condition from the process associated with the local attachment circuit where the defect was detected (typically the source adaptation function for the local client interface). It is propagated to the process associated with the far-end attachment circuit (typically the source adaptation function for the far-end client interface) for the same transmission path, in case the client of the transport path does not support a native defect/alarm indication mechanism, e.g., AIS. A source MEP starts transmitting a CFI to its peer MEP when it receives a local client signal defect notification via its local client signal fail indication. Mechanisms to detect local client signal fail defects are technology specific. Similarly, mechanisms to determine when to cease originating client signal fail indication are also technology specific. A sink MEP that has received a CFI reports this condition to its associated client process via its local CFI function. Consequent actions toward the client attachment circuit are technology specific. There needs to be a 1:1 correspondence between the client and the MEG; otherwise, when multiple clients are multiplexed over a transport path, the CFI packet requires additional information to permit the client instance to be identified. MIPs, as well as intermediate nodes, do not process the CFI information; they forward these proactive CFI OAM packets as regular data packets.5.7.1. Configuration Considerations
In order to support CFI indication, the CFI transmission rate and, for E-LSPs, the PHB of the CFI OAM packets should be configured as part of the CFI configuration.
(next page on part 3)
