Unofficial Draft ITU-T New Recommendation Y.1373/G.8114

Transcription

1 Unofficial Draft ITU-T New Recommendation Y.1373/G.8114 This draft is prepared to assist the revision work of the IAB T-MPLS DT. Revision bars mark the changes that will be done to this Recommendation if the contributions to the next SG13 plenary meeting and shared with the T-MPLS DT are accepted for inclusion in this draft Recommendation before its approval. Issue Notes Document History 0.0 Initial version based on Editor s latest draft available at This draft resolves (TBC by T-MPLS DT) the issues raised against the usage of EXP bits and TTL field in the OAM alert header differently than RFC 3429 (comment 9, 10 and 35). Revision bars mark the changes proposed in text_exp v01.doc, text_mel v01.doc and text_ttl v00.doc The proposed resolutions are aligned with IETF - TMPLS Answers-00.doc 0.1 This draft includes proposed resolutions as in IETF - TMPLS Answers-01.doc 0.2 This draft includes proposed resolutions as in IETF - TMPLS Answers-02.doc 0.3 This draft includes proposed resolutions as in IETF - TMPLS Answers-03.doc

2 - 2 - ITU-T Recommendation Y.1373/G.8114 Summary Operation & maintenance mechanism for T-MPLS layer networks This Recommendation provides mechanisms for user-plane OAM (operation administration and maintenance) functionality in T-MPLS layer networks according to the requirements and principles given in [ITU-T Y.1372/G.8113]. This Recommendation is designed primarily to support point-topoint and point-to-multipoint T-MPLS connections. The OAM mechanisms defined in this Recommendation assume common forwarding of the T-MPLS user PDUs and T-MPLS OAM PDUs. It is noted that this Recommendation does not address the administration aspects of OAM.

3 - 3 - Table of Contents Introduction Scope References Definitions Abbreviations Conventions Representation of octets Maintenance Entity (ME) ME Group (MEG) MEG End Point (MEP) Server MEP MEG Intermediate Point (MIP) MEG Level (MEL) OAM transparency OAM relationships MEs, MEPs, and MIPs relations MEGs and MEG relations MEPs and MIPs configurations OAM support in uni-directional/bi-directional connections Generic OAM packet identification in MEPs and MIPs OAM functions for fault management Continuity and Connectivity Check (CC) CV (with CC information) Transmission CV (with CC information) Reception Alarm Indication Signal (AIS) FDI/AIS Transmission FDI/AIS Reception Remote Defect Indication (RDI) CV (with RDI information) Transmission CV (with RDI information) Reception LoopBack (LB) LB in bi-directional point-to-point T-MPLS connections (LB) LB in uni-directional T-MPLS connections Lock (LCK) LCK Transmission LCK Reception Test (TST) TST Transmission...21

4 TST Reception OAM functions for performance monitoring Packet Loss Measurement (LM) Dual-ended T-MPLS LM Single-ended T-MPLS LM Packet Delay and Packet Delay Variation Measurements (DM) One-way T-MPLS DM Two-way T-MPLS DM Other OAM [LC3-5] [LC3-7] functions Automatic Protection Switching (APS) function Management Communication Channel (MCC) function Signalling Communication Channel (SCC) function Synchronisation Status Message (SSM) function EXperimental (EX) function Vendor Specific (VS) function Client Signal Fail (CSF) OAM PDU types Common OAM PDU format [ITU-T G.8112] compatible OAM PDU format TLV format Connectivity Verification (CV) Forward Defect Indication (FDI) Loopback OAM LoopBack Message (LBM) LoopBack Response (LBR) Loss Measurement Loss Measurement Message (LMM) Loss Measurement Response (LMR) Lock (LCK) Test (TST) Automatic Protecting Switching (APS) Management Communications Channel (MCC) Signalling Communications Channel (SCC) Delay Measurement One-way Delay Measurement (1DM) Two-way Delay Measurement (DM) Two-way Delay Measurement Message (DMM) Two-way Delay Measurement Response (DMR) Experimental OAM Experimental OAM Message (EXM)...51

5 Experimental OAM Response (EXR) Vendor Specific OAM Vendor Specific OAM Message (VSM) Vendor Specific OAM Response (VSR) Client Signal Fail (CSF) Synchronisation Status Message (SSM) Security aspects...56 Annex A Backward Defect Indication (BDI)...57 Annex B [ITU-T G.8112] Compatibility Considerations...57 B.1 seti only configuration...58 B.2 v1 only configuration...58 B.3 seti-setii Interworking configurations...58 B.4 seti-setii interworking requirements...59 B.5 setii automatic configuration...60 Annex C [LC1-11] ETH T-MPLS interworking (OAM)...60 Appendix I T-MPLS Network Scenarios...60 Appendix II Packet loss measurement...61 II.1 Packet loss calculations...61 II.1. Simplified calculation for Packet Loss...63 II.2 Packet counter wrapping periodicity...63

6 - 6 - ITU-T Recommendation Y.1373/G.8114 Introduction Operation & maintenance mechanism for T-MPLS layer networks This Recommendation provides T-MPLS OAM mechanisms to meet the T-MPLS OAM requirements defined in [ITU-T Y.1372/G.8113]. 1 Scope This [LC1-1] Recommendation specifies the mechanisms required to operate and maintain the network and service aspects of the transport MPLS (T-MPLS) layer network. It also specifies the T- MPLS OAM packet formats, syntax and semantics of T-MPLS OAM packet fields. The T-MPLS OAM mechanisms as described in this Recommendation apply to both point-to-point T-MPLS connections and point-to-multipoint T-MPLS connections. The T-MPLS OAM mechanisms as described in this Recommendation are applicable to any environment where the T-MPLS layer(s) is (are) managed using network management systems (NMS) and/or operational support systems (OSS). The NMS or OSS can be with or without a control plane. The architectural basis for this Recommendation is the T-MPLS architectural specification [ITU-T G ]. [IETF-4] The detailed description of the OAM procedures is outside the scope of this Recommendation. They are under definition in [ITU-T G.8121]. The OAM functions of the server layer network used by the T-MPLS layer network are not within the scope of this Recommendation. The OAM functions of the client layer network(s) of the T- MPLS layer network are not within the scope of this Recommendation either. It is noted that this Recommendation does not address the administration aspects of OAM. 2 References The [LC3-1] following ITU-T Recommendations and other references contain provisions that, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. [ITU-T G.805] [ITU-T G.806] [ITU-T G.809] ITU-T Recommendation G.805 (2000), Generic functional architecture of transport networks. ITU-T Recommendation G.806 (2004), Characteristics of transport equipment Description methodology and generic functionality. ITU-T Recommendation G.809 (2003), Functional architecture of connectionless layer networks.

7 - 7 - [ITU-T G.826] [ITU-T G.7710] [ITU-T G ] [ITU-T G.8121] [ITU-T G.8131] [ITU-T G.8261] ITU-T Recommendation G.826 (2002), End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections. ITU-T Recommendation G.7710 (2001), Common equipment management function requirements. ITU-T Recommendation G (2004), Architecture of T-MPLS Layer Networks. ITU-T Recommendation G.8121 (2004), Characteristics of T-MPLS Transport Network Equipment Functional Blocks. ITU-T Recommendation G.8131 (2006), T-MPLS linear protection switching. ITU-T Recommendation G.8261/Y.1361 (2006), Timing and synchronisation aspects of packet networks [ITU-T M.1400] [ITU-T O.150] [ITU-T T.50] ITU-T Recommendation M.1400 (2004), Designation for interconnections among operator s networks. ITU-T Recommendation O.150 (1996), General requirements for instrumentation for performance measurement on digital transmission equipment. ITU-T Recommendation T.50 (1992), International Reference Alphabet (IRA) Information technology 7-bit coded character set for information interchange [ITU-T Y.1372/G.8113] ITU-T Recommendation Y.1372/G.8113, Requirements for Operation & maintenance functionality in T-MPLS networks. [ITU-T Y.1711] ITU-T Recommendation Y.1711 (2004), Operation & Maintenance mechanism for MPLS networks. [IEEE ] IEEE , Standard for A Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. [IEEE 802.1] 3 Definitions IEEE , IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. This Recommendation introduces some terminology, which is required to discuss the functional network components associated with T-MPLS OAM. These definitions are consistent with ITU-T [ITU-T G.805], [ITU-T G.806]and [ITU-T G.809]terminology. 3.1 anomaly: see [LC3-2] [ITU-T G.806]. 3.2 backward direction: The backward direction is opposite to the forward direction. 3.3 client/server relationship: see [ITU-T G.809]. 3.4 defect: see [ITU-T G.806]. 3.5 failure: see [ITU-T G.806]. 3.6 forward direction: The forward direction is the direction that traffic and the OAM PDUs directed to the near end trail termination are transported on a T-MPLS connection. 3.7 link connection: see [ITU-T G.805].

8 sub-network connection: see [ITU-T G.805]. 3.9 trail: see [ITU-T G.805] trail termination function (TT): see [ITU-T G.806] user-plane: This refers to the set of traffic forwarding components through which traffic is transported. The user-plane is also sometimes called the data-plane or transport-plane. Note that control-plane protocols (e.g., for signalling or routing) and management-plane protocols will require their own user-plane, and their user-plane may or may not be congruent (to varying degrees) with the traffic bearing user-plane. 4 Abbreviations This Recommendation uses the following abbreviations: 1DM AIS APS BDI BIP CC CSF CV DM DMM DMR EXM EXR FDI FFD LB LBM LBR LCK LM LMM LMR MCC ME MEG One-way Delay Measurement Alarm Indication Signal Automatic Protection Switching Backward Defect Indicator Bit Interleaved Parity Continuity and Connectivity Check Client Signal Fail Connectivity Verification Delay Measurement Delay Measurement Message Delay Measurement Response Exercise Message Exercise Response Forward Defect Indicator Fast Failure Detection Loopback Loopback Message Loopback Response Lock Loss Measurement Loss Measurement Message Loss Measurement Response Management Communication Channel Maintenance Entity ME Group

9 - 9 - MEL MEP MIP MPLS NMS OAM OSS PHB RDI SCC SDH SES SLA SSM TLV T-MPLS TST TTL TTSI VSM VSR MEG Level MEG End Point MEG Intermediate Point Multi-Protocol Label Switching Network Management System Operation Administration and Maintenance Operational Support Systems Per Hop Behaviour Remote Defect Indicator Signalling Communication Channel Synchronous Digital Hierarchy Severely Errored Second Service Level Agreement Synchronisation Status Message Type Length Value Transport MPLS Test Time to Live Trail Termination Source Identifier Vendor Specific Message Vendor Specific Response 5 Conventions The diagrammatic conventions for connection-oriented and connectionless layer networks described in this Recommendation are those of [ITU-T G.805], [ITU-T G.809], and [ITU-T G ]. For the purposes of this Recommendation, the following OAM terms and diagrammatic conventions are also defined. 5.1 Representation of octets The bits in an octet are numbered from 1 to 8, where bit 1 is the least significant bit (LSB) and bit 8 is the most significant bit (MSB). The order of transmission is from left to right, most significant bit (MSB) to least significant bit (LSB). When consecutive octets are used to represent a binary number, the lower octet number has the most significant value. 5.2 Maintenance Entity (ME) A ME [LC1-2] represents an entity that requires management and is a relationship between two Maintenance Entity Group End Points (see sub-clause 5.4). The basic ME in the T-MPLS network

10 is the T-MPLS connection-oriented trail (see [ITU-T G ]). MEs can nest but shall not overlap. 5.3 ME Group (MEG) A ME Group (MEG) includes different MEs that satisfy the following conditions: MEs in a MEG exist in the same administrative boundary, MEs in a MEG operate at the same MEG Level (see sub-clause 5.6), and MEs in a MEG belong to the same point-to-point T-MPLS connection or to the same pointto-multipoint T-MPLS connection. For a point-to-point T-MPLS connection, a MEG contains a single ME. For a point-to-multipoint T- MPLS connection containing n end-points, a MEG contains (n-1) MEs. 5.4 MEG End Point (MEP) A MEG End Point (MEP) marks the end point of a T-MPLS MEG that is capable of initiating and terminating OAM packets for fault management and performance monitoring. The OAM packets are distinct from the transported T-MPLS packets. The OAM packets are inserted in T-MPLS connection and it is assumed that they are subject to the same forwarding treatment as the T-MPLS packets being monitored. A MEP does not add a new forwarding identifier to the transported T- MPLS packets. A MEP of a tandem connection does not terminate the T-MPLS connection, though it can monitor its connectivity (e.g. count packets). A MEP of a network connection terminates the T-MPLS connection and monitors its connectivity (e.g. count packets). A MEP may be described using atomic functions, as per [ITU-T G.8121]. These are outside the scope of this Recommendation Server MEP A Server MEP represents the compound function of the Server layer termination function and Server/TM adaptation function which is used to notify the T-MPLS layer MEPs upon failure detection by the Server layer termination function or Server/TM adaptation function, where the Server layer termination function is expected to run OAM mechanisms specific to the Server layer. NOTE - A Server MEP needs to support TM-AIS function, as described in sub-clause 7.2, where the Server/TM adaptation function is required to issue packets with TM-AIS information upon detection of defect at the Server layer by the Server layer termination and/or adaptation function. A Server MEP may be described using atomic functions, as per [ITU-T G.8121], that are outside the scope of this Recommendation. 5.5 MEG Intermediate Point (MIP) A MEG Intermediate Point (MIP) is an intermediate point in a MEG that is capable of reacting to some OAM packets. A MIP does not initiate OAM packets. A MIP takes no action on the T-MPLS connection. A MIP may be described using atomic functions, as per [ITU-T G.8121]. These are outside the scope of this Recommendation. 5.6 MEG Level (MEL) In case MEGs are nested, the OAM packets of each MEG have to be clearly identifiable and separable from the OAM packets of the other MEGs. In case the OAM packets are not

11 distinguishable by the T-MPLS layer encapsulation itself, the MEG Level in the OAM packet distinguishes between the OAM packets of nested MEGs. Eight MEG Levels (from 0 to 7) are available to accommodate different network deployment scenarios. Each MEG Level is operated at MEL=0: o Each MEP generates and processes OAM packets at the MEL=0. o Each MIP is able to process and reply to OAM packets at the MEL=0. o Each MEP generates AIS and LCK at the MEL=0 for alarm suppression at the client MEG Level. In order to distinguish OAM packets of nested MEGs, each MEP tunnels incoming OAM packets by incrementing the MEL in the source direction and decrementing it in the sink direction. Note A source MEP drops all the incoming OAM packets with MEL=7 in order to avoid overflowing of the MEL field. 5.7 OAM transparency OAM [LC1-3] Transparency refers to the ability to allow transparent carrying of OAM packets belonging to higher level MEGs across other lower level MEGs when the MEGs are nested. OAM packets belonging to an administrative domain originate and terminate in MEPs present at the boundary of that administrative domain. A MEP prevents OAM packets corresponding to a MEG in the administrative domain, from leaking outside that administrative domain. However, when a MEP is not present or is faulty, the associated OAM packets could leave the administrative domain. Similarly, a MEP present at the boundary of an administrative domain protects the administrative domain from OAM packets belonging to other administrative domains. The MEP allows OAM packets from outside administrative domains to pass transparently by incrementing the MEL field before they enter the administrative domain and decrementing it before they leave the administrative domain. OAM packets can be prevented from leaking by implementing an OAM filtering process in the MEP atomic functions. 5.8 Value of reserved field: The value of a field, which is reserved or reserved for future international standardization shall be set to all "0" and ignored at reception. 6 OAM relationships 6.1 MEs, MEPs, and MIPs relations [IETF-38] Appendix I provides different network scenariosan example of a network scenario to show how MEGs, MEPs and MIPs at different MEG Levels as well as at different T-MPLS layer network instances can be deployed. [IETF-38] NOTE Appendix I provides also networks scenarios to showalso shows how MEGs, MEPs and MIPs in the client layer network can be deployed. 6.2 MEGs and MEG relations All the MEPs operate at the MEG Level 0 irrespectively at their position in the MEG stack.

12 Inter-domain MEPs, associated with MEGs between two administrative domains, do not require any MEG Level agreement between the two administrative domains, the MEG Level stacking solution ensures that inter-domain OAM packets are prevented from leaking into either administrative domain. 6.3 MEPs and MIPs configurations MEPs and MIPs are configured via the management plane and/or control plane. The management plane configurations may be carried out through manual local administration of each device or via Network Management Systems (NMS). This configuration is outside the scope of this Recommendation. 6.4 OAM support in uni-directional/bi-directional connections OAM [LC1-4] [LC1-6 (vi)] packets can always be inserted and extracted in the forward direction of uni-directional and bi-directional connections. However OAM functions relying on OAM packets returned to the origination OAM function require a return path. Within a connection traffic units sent from the single source are constrained to stay within the connection under defect-free conditions. During misconnectivity defects a connection can no longer be assumed to be constrained and traffic units (and by implication also OAM packets) can 'leak' unidirectionally outside a connection. Therefore during misconnectivity defects it is not possible to rely on OAM which uses a request/response mechanism, and so for this reason such OAM should be treated with caution if used for diagnostic purposes. This applies to both end to end OAM (i.e. between true trail termination points) and for nested TCM OAM. A return path could be the backward direction of a bi-directional connection. The return path for uni-directional connections is for further study. Note [LC3-3] [ITU-T Y.1372/G.8113] does not require any OAM function that needs a return path to monitor uni-directional connections. 6.5 Generic OAM packet identification in MEPs and MIPs An OAM [LC1-5] [LC2-1] packet is identified by: - an OAM specific label stack entry header containing: - a 20-bit label field with the reserved value OAM Alert label (label: 14) [IETF-9] - a 3-bit MEG level field - a 1-bit bottom of stack (S) bit with value 0b1 - a 8-bit TTL field with value 0x01 or MIPhops+1 - an OAM message specific Function Type containing: - a 8-bit OAM PDU function type codepoint - [IETF-10] an OAM MEG Level: - a 3-bit MEG level field - an optional (i.e. function type dependent) MEP or MIP data-plane identifier TLV containing one of the following identifier formats: - 48-bit MAC address, - 13 character MEG ID and a 13 bit MEP/MIP ID, bit IPv6 address.

13 OAM packets addressed to a MEP: A receiving MEP should be able to identify OAM packets it has to process by recognizing them as being OAM packets (due to the presence of the OAM Alert label value) with the MEL field equal to 0[IETF-10]. The value in the TTL field of the OAM label stack entry is ignored. [IETF-10] A MEP that sends an OAM packet addressed to another MEP, should set the TTL field in the OAM alert label stack entry equal to 0x01. Mechanisms for a receiving MIP to identify OAM packets it has to process are for further study. A MIP should transparently pass through all the OAM packets at its MEG Level (i.e. a packet with the OAM alert label stack entry and MEL field equal to 0) having the TTL field of the OAM label stack entry equal to 0x01. OAM packets (e.g. Loopback) addressed to a MIP: A receiving MIP should be able to identify OAM packets it has to process by recognizing them as being OAM packets (due to the presence of the OAM Alert label value) with the MEL field equal to 0, a Function type that is supported by the MIP and a data-plane identifier that identifies this MIP. In order to simplify MIP operations (not to require deep packet inspection inside the OAM PDU), an additional mechanism for MIP identification is defined. A MEP that sends an OAM packet addressed to a MIP, should set the TTL field in the OAM alert label stack entry according to the following formula: TTL = MIP hops + 1 where MIP hops stand for the number of MIP hops from the source MEP to the target MIP. A receiving MIP should be able to identify OAM packets it has to process by recognizing them as being OAM packets (due to the presence of the OAM Alert label value) with the MEL field equal to 0 and with the TTL field in the OAM label stack entry equal to 0x02. A MIP should pass through all the received OAM packets at its MEG Level (i.e. a packet with the OAM Alert label value and MEL field equal to 0) with the TTL field of the OAM label stack decremented by 1 if it was greater than 0x02. 7 OAM functions for fault management OAM functions for Fault Management allow detection, verification, localization and notification of multiple defect conditions. 7.1 Continuity and Connectivity Check (CC) Continuity and Connectivity Check function (CC) is used for proactive monitoring. It is used to detect loss of continuity (LOC) between any pair of MEPs in a MEG. CC also allows detection of unintended connectivity between two MEGs (Mismerge), unintended connectivity within the MEG with an unexpected MEP (Unexpected MEP), and other defect conditions (e.g. Unexpected Period, etc.). CC is applicable for fault management, performance monitoring, or protection switching applications. Note: [ITU-T Y.1711] refers to the Continuity and Connectivity Check function as a Continuity Verification function. The TTSI [LC3-8] formats are specified in sub-clause A MEP must always report reception of packet with unexpected CC information, see sub-clause CC transmission may be enabled or disabled in a MEG. When CC transmission is enabled in

14 a MEG, all MEPs are enabled to periodically transmit packets with CC information to all other MEPs in the MEG. The CC transmission period is the same for all MEPs in the MEG. In a bidirectional connection, when a MEP is enabled to generate packets with CC information, it also expects to receive packets with CC information from its peer MEPs in the MEG. In a unidirectional connection, only the source MEPs can be enabled to generate packets with CC information. This MEP does not expect to receive any packets with CC information from its peer MEPs in the MEG. When CC transmission is disabled in a MEG, all MEPs are disabled to transmit packets with CC information. Specific configuration information required by each MEP to support CC is the following: MEG ID identifies the MEG to which the MEP belongs MEP ID MEP s own identity in the MEG List of peer MEP IDs list of peer MEPs in the MEG. For a point-to-point MEG with a single ME, the list would consist of a single MEP ID for the peer. CC transmission period this is application dependent. CC has 3 different applications (for each application, a default transmission period is specified): - Fault Management: default transmission period is 1s (i.e. transmission rate of 1 packet/second) - Performance Monitoring: default transmission period is 100ms (i.e. transmission rate of 10 packets/second) - Protection Switching: default transmission period is 3.33ms (i.e. transmission rate of 300 packets/second) PHB identifies the per-hop behaviour of packet with CC information. By default, the packet with CC information is transmitted with the "minimum loss-probability PHB". Otherwise, the PHB can be configured. A MIP is transparent to the CC information and therefore does not require any configuration information to support CC. The OAM PDU used for CC information is CV, as described in sub-clause Packets which carry the CV PDU are called CV packets CV (with CC information) Transmission When [LC1-7] CC is enabled, a MEP periodically transmits CV packets as often as the configured transmission period. Transmission period can be one of the following seven values: 3.33ms: default transmission period for protection switching application (transmission rate of 300 packets/second) 10ms: (transmission rate is 100 packets/second) 100ms: default transmission period for performance monitoring application (transmission rate of 10 packets/second) 1s: default transmission period for fault management application (transmission rate of 1 packet/second) 10s: (transmission rate of 6 packets/minute) 1 min: (transmission rate of 1 packet/minute) 10 min: (transmission rate of 6 packets/hour)

15 NOTE - Even though 7 different values are specified for transmission period, the default values are recommended based on the application area for which CC is being used. When a transmission period other than the default value for an application area is used, the behaviour of the intended application is not guaranteed. In particular care has to be taken when provisioning the period across nested T-MPLS sublayers. The period field in CV is transmitted with a value of transmission period configured at the transmitting MEP, so that a receiving MEP can detect Unexpected Period, if the transmission period is not the same across the transmitting and receiving MEPs CV (with CC information) Reception When a MEP receives a CV packet, it examines it to ensure that its MEG ID matches the configured MEG ID in the receiving MEP, and that the MEP ID in the CV packet is one from the configured list of peer MEP IDs. The information in the CV packet is catalogued in the receiving MEP. CV packets allow detection of different defect conditions, which include: If no CV packets from a peer MEP are received within the interval equal to 3.5 times the receiving MEP s CC transmission period, loss of continuity with peer MEP is detected. If a CV packet with MEG level 0 and with a MEG ID different than the receiving MEP s own MEG ID is received, Mismerge is detected. If a CV packet with with MEG level 0 and a correct MEG ID but with an incorrect MEP ID, including the receiving MEP s own MEP ID, is received, Unexpected MEP is detected. If a CV packet is received with a with MEG level 0 and a correct MEG ID, a correct MEP ID, but with a period field value different than the receiving MEP s own CC transmission period, Unexpected Period is detected. A receiving MEP must notify the equipment fault management process when it detects the above defect conditions. 7.2 Alarm Indication Signal (AIS) Alarm Indication Signal function (AIS) is used to suppress alarms following detection of defect conditions at the server (sub) layer. Packets with AIS information can be issued at a MEP, including a Server MEP, upon detecting defect conditions. For example, the defect conditions may include: Signal fail conditions in the case that CC is enabled AIS condition or LCK condition in the case that CC is disabled. NOTE - Since a Server MEP does not run CC, a Server MEP can transmit packets with AIS information upon detection of any signal fail condition. Only a MEP, including a Server MEP, is configured to issue packets with AIS information. Upon detection of a signal fail condition as specified in [ITU-T G.8121] the MEP can immediately start transmitting packets with AIS information periodically with the MEG Level set to 0. A MEP continues to transmit periodic packets with AIS information until the signal fail condition is cleared. Upon receiving a packet with AIS information a MEP detects an AIS defect condition and suppresses loss of continuity alarms associated with all its peer MEPs. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of AIS condition.

16 Specific configuration information required by a MEP to support AIS transmission is the following: PHB identifies the per-hop behaviour of packet with AIS information. A MIP is transparent to packets with AIS information and therefore does not require any information to support AIS functionality. The PDU used for AIS information is FDI, as described in sub-clause Packets carrying the FDI PDU are called FDI packets FDI/AIS Transmission A MEP, upon detecting a signal fail condition as specified in [ITU-T G.8121], can transmit FDI packets in a direction opposite to its peer MEP(s). The periodicity of FDI packets transmission is one second. The first FDI packet must always be transmitted immediately following the detection of a defect condition. The client (sub) layer may consist of multiple MEGs that should be notified to suppress alarms resulting from defect conditions detected by the server (sub) layer MEP. The server (sub) layer MEP, upon detecting the signal fail condition, needs to send FDI packets to each of these client (sub) layer MEGs. In such cases, the first FDI packet for all client (sub) layer MEGs must be transmitted within 1 second of defect condition FDI/AIS Reception Upon [LC1-8] receiving an FDI packet with MEG level 0, the MEP detects AIS defect condition. Following detection of AIS defect condition, if no FDI packets are received within an interval of 3 consecutive seconds, the MEP clears AIS defect condition. Note: Care has to be taken when provisioning the CV period across nested T-MPLS sublayers because this affects the performance of the FDI/AIS detection. 7.3 Remote Defect Indication (RDI) The RDI information can be used by a MEP to communicate to its peer MEPs that a defect condition associated with a signal fail condition as specified in [ITU-T G.8121] has been encountered. RDI is used only in bidirectional connections when CV packet generation is enabled. RDI has the following two applications: Single-ended fault management: The receiving MEP detects an RDI defect condition, which gets correlated with other defect conditions in this MEP and may become a fault cause. The absence of received RDI information in a single MEP indicates the absence of defects associated with signal fail conditions in the other MEPs. Contribution to far-end performance monitoring: It reflects that there was a defect condition associated with a signal fail condition in the far-end that is used as an input to the performance monitoring process. A MEP that is in a defect condition associated with a signal fail condition transmits packets with RDI information. A MEP, upon receiving packets with RDI information, determines that its peer MEP has encountered a defect condition associated with asignal fail condition. Specific configuration information required by a MEP to support RDI function is the following: RDI transmission period application dependent and is configured to be the same as CC transmission period.

17 PHB identifies the per-hop behaviour of packet with RDI information. It is the same as CC PHB. A MIP is transparent to packets with RDI information and therefore does not require any configuration information to support RDI functionality. The PDU used to carry RDI information is CV, as described in sub-clause The RDI OAM function can also be performed by using BDI PDUs for backward compatibility, see Annex A for the description of BDI CV (with RDI information) Transmission A MEP, upon detecting a signal fail condition as specified in [ITU-T G.8121], sets the RDI bit in the CV packets for the duration of the signal fail condition. CV packets, as described in sub-clause 7.1.1, are transmitted periodically based on the CC transmission period, when the MEP is enabled for CV packets transmission. When the signal fail condition clears, the MEP clears the RDI bit in the CV packets in subsequent transmissions CV (with RDI information) Reception Upon receiving a CV packet with MEG level 0, a MEP examines it to detect RDI condition if the RDI bit is set. For a point-to-point connection, a MEP can clear the RDI condition when it receives the first CV packet from its peer MEP with the RDI bit cleared. Note RDI is not applicable to unidirectional connections. 7.4 LoopBack (LB) The Loopback function (LB) is used to verify the connectivity of a MEP with a MIP or peer MEP(s) LB in bi-directional point-to-point T-MPLS connections (LB) LB is an on-demand OAM function that can be used for the following applications: To verify bidirectional connectivity of a MEP with a MIP or a peer MEP. To perform a bidirectional in-service or out-of-service diagnostics test between a pair of peer MEPs. This includes verifying bandwidth throughput, detecting bit errors, etc. When used to verify bidirectional connectivity, a MEP sends a packet with LB request information and expects to receive a packet with LB reply information from a MIP or peer MEP within a specified period of time. The MIP or peer MEP is identified by its data-plane identifier. This dataplane identifier is encoded in the Target MIP/MEP data-plane identifier field of the request packet. If the MEP does not receive the packet with LB reply information within the specified period of time, loss of connectivity with the MIP or peer MEP can be inferred. LB can also be used to test the bidirectional connectivity with different packet sizes between a MEP and a MIP or peer MEP. When used for performing bidirectional diagnostics tests, a MEP sends packets with LB request information to a peer MEP. This LB request information includes test patterns. When out-of-service diagnostic tests are performed, data traffic is not delivered on either side of the diagnosed MEG. Instead the MEPs are configured to send packets with LCK information, as described in sub-clause 7.5, on either side of the ME.

18 NOTE 1 LB can be used to perform only one of the two applications at any time. It must finish the pending on-demand command related to one application (either connectivity verification or diagnostic test) before it can act on a new on-demand command for the other application. NOTE 2 The maximum rate at which packets with LB information can be sent without adversely impacting the data traffic for in-service bidirectional connectivity verification or in-service bidirectional diagnostic tests is outside the scope of this Recommendation. Specific configuration information required by a MEP to support LB is the following: data-plane identifier of remote MIP or MEP to which LB is intended. [IETF-10] Hop Count It represents the number of MIP hops from the source MEP to the target MIP for Loopback. Data - Optional element whose length and contents are configurable at the MEP. The contents can be a test pattern and an optional checksum. Examples of test patterns include pseudo-random bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8 of [ITU-T O.150], all 0 pattern, etc. For bidirectional diagnostic test application, configuration is required for a test signal generator and a test signal detector associated with the MEP. PHB identifies the per-hop behaviour of packet with LB information. [IETF-10] NOTE 3 Mechanisms to send LB request information from a MEP to a MIP are for further study. New specific configuration information can be required in future version of this Recommendation in order to support these mechanisms. [IETF-10] NOTE 3 4 Additional configuration information elements may be needed for repetitive transmission, e.g. repetition rate, total interval of repetition, etc. These additional configuration information elements are outside the scope of this Recommendation. A remote MIP or MEP, upon receiving the packet with LB request information which is addressed to the MIP or MEP, responds with a packet with LB reply information. There is no specific configuration information required by a MIP to support LB. The OAM PDU used for LB request information is LBM, as described in sub-clause The OAM PDU used for LB reply information is LBR, as described in sub-clause Packets carrying the LBM PDU are called LBM packets. Packets carrying the LBR PDU are called LBR packets LBM Transmission LBM packets are transmitted by a MEP on an on-demand basis. When used for bidirectional connectivity verification, a MEP transmits a LBM packet addressed to the remote MIP or remote peer MEP with a specific Transaction ID inserted in the Transaction ID/Sequence Number field. After LBM packet transmission, a MEP expects to receive a LBR packet within 5 seconds. The transmitted Transaction ID is therefore retained by the MEP for at least 5 seconds after the LBM packet is transmitted. A different Transaction ID must be used for every LBM packet, and no Transaction ID from the same MEP may be repeated within one minute. A MEP can optionally use a Data TLV or Test TLV. When configured for checking the successful transmission of different packet sizes, the MEP uses a Data TLV. However, when used for diagnostic tests, a MEP transmits a LBM packet addressed to the remote peer MEP with a Test TLV. The Test TLV is used to carry the test pattern generated by a test signal generator associated with the MEP. When the MEP is configured for an out-of-service diagnostic test, the MEP also generates LCK packets, as described in sub-clause 7.5, at the client MEG Level in a direction opposite to the direction where LBM packets are issued.

19 LBM Reception and LBR Transmission Whenever a valid LBM packet is received by a MIP or MEP, an LBR packet is generated and transmitted to the requesting MEP. A LBM packet with MEG level 0 and with the LB Target MIP/MEP data-plane identifier field equal to the data-plane identifier of receiving MIP or MEP is considered to be a valid LBM packet. Every field in the LBM packet is copied to the LBR packet with the following exception: The Function Type field is changed from LBM to LBR. Further, when a receiving MEP is configured for an out-of-service diagnostic test, it also generates LCK packets, as described in sub-clause 7.5, at the client MEG Level in a direction opposite to the direction where LBR packets are issued LBR Reception When a MEP configured for connectivity verification receives an LBR packet with MEG level 0 and with the LB Source MEP data-plane identifier equal to its data-plane identifier, with an expected Transaction ID and within 5 seconds after transmitting the LBM packet, the LBR packet is valid. Otherwise the LBR packet addressed to it is invalid and is discarded. When a MEP configured for a diagnostics test receives an LBR packet with MEG level 0 and with the LB Source MEP data-plane identifier equal to its data-plane identifier, the LBR packet is valid. The test signal receiver associated with MEP may also validate the received Sequence Number against expected Sequence Numbers. If a MEP receives an LBR packet with MEG level 0 with the LB Source MEP data-plane identifier different from its data-plane identifier, such an LBR packet is invalid LB in uni-directional T-MPLS connections The Loopback application is not supported in unidirectional (point-to-point and point-to-multipoint) connections. 7.5 Lock (LCK) LCK is used to communicate the administrative locking of a server (sub-) layer MEP and consequential interruption of data traffic forwarding towards the MEP expecting this traffic. It allows a MEP receiving packets with LCK information to differentiate between a defect condition and an administrative locking action at the server (sub-) layer MEP. An example of an application that would require administrative locking of a MEP is the out-of-service TST, as described in subclause 7.6. A MEP continues to periodically transmit packets with LCK information until the administrative/diagnostic condition is removed. A MEP extracts packets with LCK information and detects a LCK condition, which contributes to the signal fail condition of the MEP. The signal fail condition may result in the transmission of FDI packets to its client MEPs. Specific configuration information required by a MEP to support LCK transmission is the following: PHB identifies the per-hop behaviour of packet with LCK information.

20 A MIP is transparent to the packets with LCK information and therefore does not require any information to support LCK functionality. The PDU used for LCK information is LCK, as described in sub-clause Packets carrying the LCK PDU are called LCK packets LCK Transmission A source MEP, when administratively locked, transmits LCK packets in in the direction towards its peer MEPs, while a sink MEP, when administratively locked, transmits LCK packets in a direction opposite to its peer MEP(s). The periodicity of LCK packets transmission is one second. The first LCK packet must always be transmitted immediately following the administrative/diagnostic action LCK Reception Upon receiving an LCK packet with MEG level 0, the MEP detects an LCK condition. Following detection of an LCK condition, if no LCK packets are received within an interval of 3consecutive seconds, the MEP clears the LCK condition. 7.6 Test (TST) TST is used to perform one-way on-demand in-service or out-of-service diagnostics tests. This includes verifying bandwidth throughput, packet loss, bit errors, etc. When configured to perform such tests, a MEP inserts packets with T-MPLS test information with specified throughput, packet size and transmission patterns. When out-of-service T-MPLS test function is performed, client data traffic is disrupted in the diagnosed entity. The MEP configured for the out-of-service test transmits LCK packets, as described in sub-clause 7.5, in the immediate client (sub-)layer. When an in-service T-MPLS test function is performed, data traffic is not disrupted and the packets with T-MPLS test information are transmitted such that a limited part of the service bandwidth is utilized. This rate of transmission for TST packets is pre-determined for in-service T-MPLS test function. NOTE 1 - The maximum rate at which TST packets can be sent without adversely impacting the data traffic for an in-service T-MPLS test is outside the scope of this Recommendation. Specific provisioning required by a MEP to support TST is the following: Test TLV - Optional element whose length and contents are configurable at the MEP. The contents can be a test pattern and an optional checksum. Examples of test patterns include pseudo-random bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8 of [ITU-T O.150], all 0 pattern, etc. At the transmitting MEP, provisioning is required for a test signal generator which is associated with the MEP. At a receiving MEP, provisioning is required for a test signal detector which is associated with the MEP. NOTE 2 - Additional provisioning elements may be needed, such as the transmission rate of TST packets, the total interval of the T-MPLS test, etc. These additional provisioning elements are outside the scope of this Recommendation. A MIP is transparent to the TST packets and therefore does not require any provisioning to support T-MPLS test functionality. A MEP inserts TST packets towards its peer MEPs. The receiving MEP detects these TST packets and performs the intended measurements.

21 The PDU used for T-MPLS Test is TST, as described in sub-clause Packets carrying the TST PDU are called TST packets TST Transmission A test signal generator connected to a MEP can transmit TST packets as often as the test signal generator configuration. Each TST packet is transmitted with a specific Sequence Number. A different Sequence Number must be used for every TST packet, and no Sequence Number from the same MEP may be repeated within one minute. When a MEP is configured for an out-of-service test, the MEP also generates LCK packets in the same direction where TST packets are transmitted TST Reception If the receiving MEP is configured for T-MPLS test function, the test signal detector connected to the MEP detects bit errors from e.g. the pseudo-random bit sequence of the received TST packets with MEG level 0 and reports such errors. Further, when the receiving MEP is configured for an out-of-service test, it also generates LCK packets a in the direction where the TST packets are received. 8 OAM functions for performance monitoring OAM [LC3-4] functions for performance monitoring allow measurement of different performance parameters. The performance parameters are defined for point-to-point and point-to-multipoint T- MPLS connections. This Recommendation covers the following performance parameters. Packet Loss Ratio Packet Loss Ratio is defined as a ratio, expressed as a percentage, of the number of service packets not delivered divided by the total number of service packets during time interval T, where the number of service packets not delivered is the difference between the number of service packets arriving at the ingress T-MPLS MEP and the number of service packets delivered at the egress T-MPLS MEP in a point-to-point or point-to-multipoint T-MPLS connection. One way Packet Delay Packet Delay can be specified as transfer delay for a packet, where Packet Delay is defined as the time elapsed since the start of transmission of the first bit of the packet by a source node until the reception of the [IETF-8]first last bit of the that packet by the destination node. Two way Packet Delay Packet Delay can be specified as round-trip delay for a packet, where Packet Delay is defined as the time elapsed since the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop backed packet by the same source node, when the loop back is performed at the packet s destination node. Packet Delay Variation Packet Delay Variation is a measure of the variations in the Packet Delay between a pair of service packets, where the service packets belong to the same PHB instance on a point-topoint or point-to-multipoint T-MPLS connection. [IETF-8]NOTE 1 Round trip measurements should exclude, as much as possible, the time required to create and send the loop-backed packet.

22 [IETF-42]NOTE 2 The one-way delay in the forward direction can differ from the one-way delay in the backward direction. The two-way delay actually measures the performance of two distinct paths (i.e.the forward and the backward direction) together. Performance parameters are applicable to Service packets. Service Packets are those packets that conform to an agreed-upon level of bandwidth profile conformance. Service packets are admitted at the ingress T-MPLS MEP of a point-to-point or point-to-multipoint T-MPLS connection and should be delivered to the egress T-MPLS MEP. Specification of bandwidth profile conformance is outside the scope of this Recommendation. NOTE - The definition of Availability is outside the scope of this Recommendation. However, the mechanisms defined in this Recommendation can contribute to Availability-related measurements. 8.1 Packet Loss Measurement (LM) LM [LC1-6 (v)] is used to collect counter values applicable for ingress and egress service packets where the counters maintain a count of transmitted and received service packets between a pair of MEPs. LM is performed by sending LM packets to a peer MEP and similarly receiving LM packets from the peer MEP. Each MEP performs packet loss measurements that contribute to unavailable time. Note: Loss measurement can be performed only on one of the CoS levels at the same time. Since [LC1-9] a bidirectional service is defined as unavailable if either of the two directions is declared unavailable, T-MPLS LM must facilitate each MEP to perform near-end packet loss measurements on unidirectional connections and near-end and far-end packet loss measurements on bidirectional connections. For a MEP, near-end packet loss refers to packet loss associated with ingress data packets while farend packet loss refers to packet loss associated with egress data packets. Both near-end and far-end packet loss measurements contribute to near-end severely errored seconds (Near-End SES) and farend severely errored seconds (Far-End SES) respectively which together contribute to unavailable time, in a manner similar to [ITU-T G.826] and [ITU-T G.7710]. A MEP maintains the following two local counters for each peer MEP and for each Per-Hob Behaviour (PHB) being monitored in a ME for which loss measurements are to be performed: TxPCl: counter for service packets belonging to a specific PHB transmitted towards the peer MEP. RxPCl: counter for service packets belonging to a specific PHB received from the peer MEP. TxPCl and RxPCl counters do not count the OAM packets transmitted or received by the MEP at the MEP s MEG Level (MEL=0). However, the counters do count OAM packets from the higher MEG Levels that pass through the MEPs in a manner similar to the data packets. The method of loss measurement involving pairs of consecutive LM packets, as shown in subclause and sub-clause , alleviates lack of synchronization across the initial counter values at the transmitting and receiving MEPs. Further, when a MEP detects a loss-of-continuity defect condition, it ignores loss measurements during the defect condition and assumes 100% loss. NOTE 1 - [LC2-2] The level of accuracy in the loss measurements is dependent on how LM packets are added to the data stream after the counter values are copied in the LM PDU. For example, if additional data packets get transmitted and/or received between the time of reading the counter values and adding the LM packet containing the counter values to the data stream, the counter values copied in the LM packet become