MPLS Working Group Feng Huang (Editor) Internet Draft Lieven Levrau(Editor) Intended status: Standards Track Alcatel-Lucent Expires: May 2011 Han LI (Editor) China Mobile Ruiquan Jing (Editor) China Telecom November 30, 2010 Diagnostic tool-test for MPLS transport profile draft-flh-mpls-tp-oam-diagnostic-test-02 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]. 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- F.huang et al. Expires May 30, 2011 [Page 1] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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 May 30, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction................................................3 1.1. Authors................................................3 2. Terminology.................................................3 3. Mechanics of TST............................................4 3.1. General Requirements....................................4 3.2. Transmission...........................................5 3.3. Receive................................................7 4. TST data packet.............................................7 5. Security Considerations.....................................10 6. IANA Considerations........................................10 7. Acknowledgments............................................10 8. References.................................................11 8.1. Normative References...................................11 8.2. Informative References.................................11 Authors' Addresses............................................11 F.huang et al. Expires May 30, 2011 [Page 2] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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 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. 1.1. Authors Feng Huang, Lieven Levrau, Han Li and Ruiquan Jing. 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 F.huang et al. Expires May 30, 2011 [Page 3] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 PDU Payload Data Unit PRBS pseudo-random code stream PW Pseudo wire TLV Type Length Value TST Test 3. Mechanics of TST 3.1. General Requirements The proposed test tool can be used to perform one-way or two way on- demand in-service or out-of-service diagnostics tests, which include verifying throughput. Throughput in this document refers a capacity in terms of line rate; it is the amount of bits observed passing a point during a time interval. When the involved ingress and egress end nodes are configured to perform such tests, a MEP at the respective network layer, eg LSP tunnel, PW, inserts packets with MPLS-TP test information with specified throughput, packet size and transmission data patterns. For the one way test, the remote MEP receives the packet and calculates the packet loss. For the two way test, the remote MEP loops the packet back to the originating MEP, which calculates the packet loss. The configuration can be done via the management plane or via the control plane. The definition how this is achieved is out side the scope of this draft. The out-of-service MPLS-TP test function is service affecting, as the test function puts the remote MEP associated with the diagnosed entity into a LOCK, to make sure that the all the frames; including any user or client data frames and TST frames, are properly looped back to the ingress MEP. The source MEP configured for the out-of- service test transmits LCK packets in the immediate client (sub-) layer. Once the LCk is acknowledged, the source MEP gradually increase TST packet bandwidth either via increasing the transmit rate or via increasing frame size, until hitting a preconfigured/defined threshold TST packet traffic loss rate. For the in-service MPLS-TP test function the user data traffic is not disrupted and the MPLS-TP test packets are transmitted such that an only limited part of the service bandwidth is utilized. The rate and F.huang et al. Expires May 30, 2011 [Page 4] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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. Note: need to explicitly indicate that the test is between two MEPs and that testing is only done between those two points. 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, 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. This is shown in Figure 1: F.huang et al. Expires May 30, 2011 [Page 5] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 Alarm------ -----Alarm | | | | +---+ +---+ +---+ +---+ LCK---- | A |------| B | ----- | C |-------| D |----LCK +---+ +---+ +---+ +---+ | | |---------------TST----------------| | | Figure 1: out of service test LCK is configured by management, When an administrative/diagnostic lock is applied on a MEG, the related MEPs continues to periodically (once per 1s) transmit packets with LCK information until the administrative/diagnostic condition is removed. This allows a client MEP receiving packets with LCK information to differentiate between traffic interruption due to a defect condition and an administrative locking action at the server (sub-) layer MEP. In case of testing protection path status when it is used in protection switch, QoS of TST packet is setup as same as packet in work path. Record------ -----Record | | | | +---+ +---+ +---+ +---+ Configuration-- | A |------| B | ----- | C |-------| D | +---+ +---+ +---+ +---+ | | |---------------TST----------------| | | Figure 2: In service test When a MEP is configured for an in-service test, the MEP not generates any LCK packet. And TST packet transmission rate should be F.huang et al. Expires May 30, 2011 [Page 6] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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. TST configuration message is used to define TST data packet's information including send rate, duration, length etc. TST record message is sending once at end of duration to record send packet number, received packet number, and total duration is used, in order to detect packet loss rate. In order to test in line, TST configuration and record message carrying TST packet information in performance counter such as send rate, duration etc is defined. And TST packet that is transmitted MUST be also recorded by traffic condition performance monitor counter. The details will be updated in the next version. 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. 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. 4. TST data packet TST PDUs are encapsulated by using the ACH, according to RFC 5586 [5]. F.huang et al. Expires May 30, 2011 [Page 7] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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 3: 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 DATA Channel type: indicate it is TST data packet allocated by IANA. Tools TST use TST PDU to verify bandwidth that carries some information of TST TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Revered | Flag (0x00) | TLV offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TST TLV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End TLV | +-+-+-+-+-+-+-+-+ Figure 4: TST PDU The fields of the TST PDU format are as follows: F.huang et al. Expires May 30, 2011 [Page 8] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 Version: 4 bits, version number is set to 0 in present. Reserved: 12 bits, reserved for future international standardization, set to 00xx. Flags: none, set to 0x00. TLV Offset: set to 0x08 Sequence number: 4 octets 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. 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 5: 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. F.huang et al. Expires May 30, 2011 [Page 9] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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] 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 May 30, 2011 [Page 10] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 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: Lieven.Levrau@alcatel-lucent.com Han Li China Mobile Email : lihan@chinamobile.com F.huang et al. Expires May 30, 2011 [Page 11] Internet-Draft Diagnostic tool-test for MPLS-TP November 30, 2010 Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn F.huang et al. Expires May 30, 2011 [Page 12]