One document matched: draft-flh-mpls-tp-oam-diagnostic-test-01.txt
Differences from draft-flh-mpls-tp-oam-diagnostic-test-00.txt
MPLS Working Group Feng Huang (Editor)
Internet Draft Lieven Levrau(Editor)
Intended status: Standards Track Alcatel-Lucent
Expires: November 2010
Han LI (Editor)
China Mobile
Ruiquan Jing (Editor)
China Telecom
May 11, 2010
Diagnostic tool-test for MPLS transport profile
draft-flh-mpls-tp-oam-diagnostic-test-01
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 November 11, 2010 [Page 1]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 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 November 11, 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
3.4. Performance Monitoring counter and throughput calculation7
4. TST Frame format (PDU).......................................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 November 11, 2010 [Page 2]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 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 November 11, 2010 [Page 3]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 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 a
only limited part of the service bandwidth is utilized. The rate and
F.huang et al. Expires November 11, 2010 [Page 4]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 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.
Editor's Note TST in service will be updated in next version.
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.
F.huang et al. Expires November 11, 2010 [Page 5]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
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:
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.
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.
Editor's note: Details will be updated.
F.huang et al. Expires November 11, 2010 [Page 6]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
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.
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.
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]):
F.huang et al. Expires November 11, 2010 [Page 7]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
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.
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.
F.huang et al. Expires November 11, 2010 [Page 8]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
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 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)
F.huang et al. Expires November 11, 2010 [Page 9]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
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 November 11, 2010 [Page 10]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 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 November 11, 2010 [Page 11]
Internet-Draft Diagnostic tool-test for MPLS-TP May 11, 2010
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
F.huang et al. Expires November 11, 2010 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:24 |