MPLS Working Group Feng Huang (Editor) Internet Draft Lieven Levrau(Editor) Intended status: Standards Track Alcatel-Lucent Expires: April 2010 Han LI (Editor) China Mobile Ruiquan Jing (Editor) China Telecom October 21, 2009 Diagnostic tool-test for MPLS transport profile draft-flh-mpls-tp-oam-diagnostic-test-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 21, 2010. Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license- F.huang et al. Expires April 21, 2010 [Page 1] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) diagnostic tool-TST (test), which is used to perform one-way, or two way on-demand out-of-service measuring throughput or in-service diagnostics tests for verifying throughput. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [ .1]. Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Mechanics of TST............................................4 3.1. General Requirements....................................4 3.2. Transmission...........................................5 3.3. Receive................................................5 3.4. Performance Monitoring counter and throughput calculation6 3.5. State machine..........................................6 4. TST Frame format (PDU).......................................6 5. Security Considerations......................................8 6. IANA Considerations.........................................9 7. Acknowledgments.............................................9 8. References.................................................10 8.1. Normative References...................................10 8.2. Informative References.................................10 Authors' Addresses............................................10 1. Introduction MPLS-TP is technology of packet transport network, which requirement is defined in MPLS-TP requirement [2], and OAM is its most important function. MPLS-TP OAM requirement [3] define diagnostic tools that MAY be used for PW, LSP and Section, such as consists in looping the traffic at an Intermediate Point or End point back to the originating F.huang et al. Expires April 21, 2010 [Page 2] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 End Point-loopback. And another example of such diagnostic tool-test (TST) consists in estimating the bandwidth or throughput of transport path e.g., an LSP. This document defines one diagnostic tool-TST (test) for bandwidth estimating, measuring or verifying. And it describes TST OAM frame format and the procedures for the transmission, receive of such OAM frames. The TST function SHOULD be performed between End Points of PWs, LSPs and Sections. 2. Terminology CRC Cyclic Redundancy Check G-ACh Generic Associated Channel ACH Associated Channel Header ITU-T International telecom union-Telecom LCK lock LSP Label Switch Path MEP ME Edge Point MIP ME Intermediated Point MPLS-TP MPLS transport profile OAM Operations Administration and Maintenance PDU Payload Data Unit PRBS pseudo-random code stream PW Pseudo wire TLV Type Length Value TST Test F.huang et al. Expires April 21, 2010 [Page 3] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 3. Mechanics of TST 3.1. General Requirements TST is used to perform one-way or two way on-demand in-service or out-of-service diagnostics tests. This includes verifying throughput, which is a capacity in terms of line rate; it is the amount of bits observed passing a point during a time interval. When configured to perform such tests, a MEP inserts packets with MPLS-TP test information with specified throughput, packet size and transmission patterns. For one way test, remote MEP receives the packet and calculates the packet loss. For two way test, the remote MEP loopback the packet to original MEP and calculates the packet loss. When out-of-service MPLS-TP test function is performed, client data traffic is disrupted in the diagnosed entity by LCK function. The MEP configured for the out-of-service test transmits LCK packets in the immediate client (sub-) layer. And gradually increase TST packet bandwidth until hitting a threshold TST packet traffic loss rate. When an in-service MPLS-TP test function is performed, data traffic is not disrupted and the packets with MPLS-TP test information are transmitted such that a limited part of the service bandwidth is utilized. This rate and QoS of transmission for TST packets is pre- determined for in-service MPLS-TP test function. The maximum rate at which TST packets can be sent without adversely impacting the data traffic for an in-service is should be calculated carefully. Observe TST packet that are transmitted, delivered, and or rejected on a PW, LSP or Section. When detect threshold of packet loss rate, calculated the throughput. In order to support TST, a Test TLV in TST PDU should be defined: 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) (231-1) as specified in sub-clause 5.8 of ITU-T O.150 [4], 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, F.huang et al. Expires April 21, 2010 [Page 4] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 provisioning is required for a test signal detector which is associated with the MEP. A MIP is transparent to the TST packets and therefore does not require any provisioning to support MPLS-TP test functionality. A MEP inserts TST packets towards its peer MEPs. The receiving MEP detects these TST packets and performs the intended measurements. 3.2. 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. And TST packet transmission rate should be increased gradually by step of x Kb/s and recorded TST packet transmitted, delivered or rejected. When a MEP is configured for an in-service test, the MEP not generates any LCK packet. And TST packet transmission rate should be increased gradually by step of x Kb/s, but it is less than Maximum bit rate. In order to verify the throughput, QoS of test packet should be considered, color, CIR/EIR should be carefully calculated in order not to impact the service. And service packet that is transmitted MUST be also recorded by traffic condition performance counter. 3.3. Receive If the receiving MEP is configured for MPLS-TP test function, the test signal detector connected to the MEP detects bit errors or packet loss rate from e.g. the pseudo-random bit sequence of the received TST packets 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. Detected the packet loss rates or bit errors of test packet, and record the rate of test packet transmission or rejected. F.huang et al. Expires April 21, 2010 [Page 5] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 When the receiving MEP is configured for an in service test, no any LCK packet is generated. At same time, record all service packet counters of transmitted, delivered, and or rejected. 3.4. Performance Monitoring counter and throughput calculation To be added. 3.5. State machine To be added. 4. TST Frame format (PDU) TST PDUs are encapsulated by using the ACH, according to RFC 5586 [5]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | TST Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: TST-ACH The first four bytes represent the ACH ([RFC 5586]): 0001: Indicate it is ACH Version: 00x0 Reserved: reversed for further standardization, it is 00xx TST Channel type: indicate it is test OAM packet allocated by IANA. Tools TST use TST PDU to verify bandwidth that carries some information of TST TLV. F.huang et al. Expires April 21, 2010 [Page 6] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flag (0x00) | TLV offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PM counter | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TST TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End TLV | +-+-+-+-+-+-+-+-+ Figure 2: TST PDU The fields of the TST PDU format are as follows: Reserved: 16 bits, reserved for future international standardization, set to 00xx. Flags: none, set to 0x00. TLV Offset: set to 0x08 Sequence number: 4 octets PM counter: record packet transmitted, delivered or rejected. Test TLV: to be inserted in this field, format sees below. End TLV: set to 0x00. TLV describe test pattern that is shown in Figure 3. F.huang et al. Expires April 21, 2010 [Page 7] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Pattern Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test Pattern (NULL, PRBS) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32(optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: TST TLV The fields of the Test TLV format are as follows: Type: 1 octet, the value for this TLV type is Test (32) Length: 2 octets, Identifies size, in octets, of the Value field containing the Test Pattern and the optional CRC-32 field. Pattern Type: 1 octet, identifies the Test pattern type; values are defined in Table 0x00 Null (all-zeroes) pattern without CRC-32 0x01 Null (all-zeroes) pattern with CRC-32 0x02 PRBS 2-31-1 pattern without CRC-32 0x03 PRBS 2-31-1 pattern with CRC-32 0x04-0xFF Reserved for future standardization Test Pattern: n octets, an n-octet (n . Length) test pattern as identified by the Pattern Type. CRC-32: 4 octets, an optional field, contains the CRC-32 calculated over all fields (from Type to last octet before CRC-32) 5. Security Considerations Refer to draft-fang-mpls-tp-security-framework [6] F.huang et al. Expires April 21, 2010 [Page 8] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 Mechanisms SHOULD be provided to ensure that unauthorized access is prevented from triggering any TST function. This will prevent unauthorized access to vital equipment and it will prevent third parties from learning about sensitive information about the transport network. TST messages MAY be authenticated. 6. IANA Considerations There is one channel type for TST by IANA actions required by this draft. 7. Acknowledgments The authors acknowledge the helpful inputs from Xiaobo YI and Italo busi, William Zhang and discussions with Xiaohua MA and Stephan ROULLOT. F.huang et al. Expires April 21, 2010 [Page 9] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] B. Niven-Jenkins, D. Brungard, M. Betts, N. Sprecher, S. Ueno, MPLS-TP Requirements, draft-ietf-mpls-tp-requirements [3] M. Vigoureux, D. Ward, M. Betts, Requirements for OAM in MPLS Transport Networks, draft-ietf-mpls-tp-oam-requirements [4] ITU-T O.150, General requirements for instrumentation for performance measurements on digital transmission equipment [5] M. Bocci, M. Vigoureux, S. Bryant, MPLS Generic Associated Channel, RFC 5586, June 2009 8.2. Informative References [6] Luyuan Fang, Ben Niven-Jenkins, MPLS-TP security framework, draft-fang-mpls-tp-security-framework Authors' Addresses Feng Huang Alcatel-Lucent shanghai Bell Email: feng.f.huang@alcatel-sbell.com.cn Lieven Levrau Alcatel-Lucent Email: llevrau@alcatel-lucent.fr Han Li China Mobile Email : lihan@chinamobile.com F.huang et al. Expires April 21, 2010 [Page 10] Internet-Draft Diagnostic tool-test for MPLS-TP October 21, 2009 Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn F.huang et al. Expires April 21, 2010 [Page 11]