MPLS Working Group R. Ram
Internet Draft D. Cohn
Intended status: Informational Orckit-Corrigent
Expires: November 2011
M. Daikoku
KDDI
M. Yuxia
Y. Jian
ZTE Corp.
A. D'Alessandro
Telecom Italia
May 31, 2011
SD detection and protection triggering in MPLS-TP
draft-rkhd-mpls-tp-sd-03.txt
Abstract
This document describes guidelines for Signal Degrade (SD) fault
condition detection at an arbitrary transport path (LSP or PW) and
the usage of MPLS-TP fault management [3] for triggering protection
switching as defined in the MPLS-TP survivability framework [2].
Status of this Memo
This Internet-Draft is submitted 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 in November 2011.
Ram, et al. Expires November 2011 [Page 1]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
Copyright Notice
Copyright (c) 2011 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.
Table of Contents
1. Introduction ................................................ 3
2. Conventions used in this document ........................... 3
3. Signal Degrade and MPLS-TP protection switching ............. 4
4. SD detection method ......................................... 4
4.1. Guidelines for SD detection ............................ 4
4.2. Examples for SD detection methods ...................... 6
5. Transmission of link degradation fault indication ........... 6
5.1. Lower layer Bit Error transmission ..................... 7
6. Handling of link degradation fault indication ............... 7
7. Security Considerations ..................................... 7
8. IANA Considerations ......................................... 7
9. Acknowledgments ............................................. 7
10. References ................................................. 7
10.1. Normative References .................................. 7
10.2. Informative References ................................ 8
Ram, et al. Expires November 2011 [Page 2]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
1. Introduction
Telecommunication carriers and network operators expect to replace
aged TDM Services (e.g. legacy VPN services) provided by legacy TDM
equipment by new VPN services provided by MPLS-TP equipment.
From a service level agreement (SLA) point of view, service quality
and availability degradation are not acceptable, even after migration
to MPLS-TP equipment.
In addition, from an operational point of view, comparable
performance monitoring features to those provided by TDM networks are
expected from MPLS-TP networks. For example, OAM maintenance points
should be the same after TDM to MPLS-TP migration, as SLA revision is
typically NOT feasible for telecommunication carriers and network
operators.
MPLS-TP transport path (i.e. LSP,PW) resiliency actions such as
protection switching can be triggered by fault conditions and
external manual commands. Fault conditions include Signal Failure
(SF) and Signal Degrade (SD). The SD condition could be detected at
an intermediate link, based on lower layer indications or other sub-
layer techniques.
Since the transport path protection switching is not necessarily
managed by the transport entity that detects the SD condition, an
indication of the link SD condition must be sent over the transport
paths that traverse the affected link.
This document describes guidelines for SD detection by lower layers
indication, and a mechanism for relaying the degraded transport path
condition to the network element handling the protection switching at
the appropriate transport path level.
2. Conventions used in this document
BER: Bit Error Rate
LSP: Label Switched Path
LSR: Label Switching Router
MEP: Maintenance End Point
Ram, et al. Expires November 2011 [Page 3]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile
OAM: Operations, Administration and Maintenance
OTN: Optical Transport Network
PCS: Physical Coding Sublayer
SF: Signal Failure
SD: Signal Degrade
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].
3. Signal Degrade and MPLS-TP protection switching
Network survivability, as defined in [2], is the ability of a
network to recover traffic delivery following failure or degradation
of network resources. [5] defines an LSP protection mechanism and
state machine that handles SF, SD and operator manual commands.
4. SD detection method
4.1. Guidelines for SD detection
Signal degrade is a transport path condition in which the expected
quality of transport service delivery is not provided. The signal
degrade condition can be used by operators to detect different types
of failures, especially those with slow externalization such as
optical device aging (e.g. photo detector and laser diode in line
amplifier, transponder or SFP), transmission medium external
impairment (e.g. temperature or pressure fluctuation, fiber
elongation), and time-variable optical impairments in fiber (e.g.
chromatic dispersion, polarization mode dispersion).
Signal degrade condition in a transport path is derived from bit
error detection in the traversed links.
Bit errors in a link are caused by the following phenomena:
1. Physical conditions such as bad electrical connections, low
received optical power, dispersion effects.
Ram, et al. Expires November 2011 [Page 4]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
2. Non-physical conditions such as network congestion, CPU overload,
selective packet discard, packet processing error.
The common basis for the guidelines set forth in this section is that
the SD condition SHOULD reflect only physical error conditions in the
traversed links, without any influence from non-physical conditions.
The following conditions SHOULD be met by the signal degrade
condition detection mechanism:
o Method for determining signal degrade MUST NOT affect the services
transmitted over the transport path (e.g. add delay or jitter to
real-time traffic)
o Criterion for determining signal degrade MUST be agnostic to the
length of transmitted frames
o Criterion for determining signal degrade MUST be agnostic to the
transmission rate of transmitted frames
o Criterion for determining signal degrade MUST be agnostic to the
type of service carried by the transmitted frames
o Criterion for determining signal degrade MUST be agnostic to the
traffic class of transmitted frames
o Criterion for determining signal degrade MUST be agnostic to drop-
precedence marking of transmitted frames
o Criterion for determining signal degrade MUST be agnostic to
congestion
o Criterion for determining signal degrade SHOULD be able to detect
low error levels (e.g. BER of 10E-8)
o Criterion for determining signal degrade SHOULD have low
misdetection probability
o Criterion for determining signal degrade SHOULD have low false
alarm probability
o Criterion for determining signal degrade SHOULD be agnostic to
number of transport paths (LSPs and PWs) transported over the
transmission link
o Signal degrade conditions MUST be monitored by the lowest server
layer or sub-layer that is not terminated between monitoring
points
Ram, et al. Expires November 2011 [Page 5]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
o Method for determining signal degrade SHOULD NOT require
transmission of additional packets
o Method for determining signal degrade SHOULD allow to localize
links that contribute to signal degrade
o Method for determining signal degrade MUST be able to exit signal
degrade condition when error rate returns to normal condition
o Method for determining signal degrade condition MUST be scalable
4.2. Examples for SD detection methods
o A Server MEP [4] related to SONET or SDH sub-layers can determine
SD condition based on error indication from parity information in
the path overhead.
o A Server MEP related to OTN sub-layer can determine SD condition
based on error indications from Forward-Error-Correction
functionality inherent in encapsulation.
o A Server MEP related to 10GE PCS sub-layer can determine SD
condition based on rate of errored 66-bit block headers. (a.k.a.
symbol errors)
o A Server MEP related to 1GE PCS sub-layer can determine SD
condition based on rate of 10-bit code violations dispersion
errors.
As specified in section 4.1, these examples assume that the layer
carrying the information used for SD detection is not terminated by
non-MPLS-TP-LSR entities (e.g. media converter).
5. Transmission of link degradation fault indication
When SD condition is detected, a link degradation fault indication
[3] SHOULD be transmitted over affected transport paths, in the
downstream direction from the detection point. The link degradation
indication will be transmitted immediately following the detection
and periodically until the SD condition is removed. The messages will
be terminated and handled by the downstream client MEP.
The encapsulation and mechanism defined in [3] is suitable for
transmission of link degradation fault indication. It is RECOMMENDED
that [3] will include this definition in future work.
Ram, et al. Expires November 2011 [Page 6]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
5.1. Lower layer Bit Error transmission
There are scenarios where the lower layer bit error rate in each of
the links traversed by the transport path is below the SD threshold,
while the accumulated end-to-end BER on the LSP is above the
threshold. This is possible in lower layer technologies where errored
information is dropped, so errors in one link will not be detected by
LSRs downstream of this link. An example of such a situation is when
an LSP is carried over multiple Ethernet links, and each link drops
errored Ethernet frames.
To enable SD detection in such scenarios, LSRs MAY optionally include
the measured BER in the link degradation fault indication message.
The client MEP may then receive multiple link degradation fault
indication messages from different LSRs. When this occurs, the client
MEP SHOULD compare the sum of the received BER values with the SD
threshold to decide on the LSP SD condition.
6. Handling of link degradation fault indication
LSR behavior upon receiving link degradation fault indication is out
of the scope of this document.
SD condition processing and prioritization for protection triggering
is out of the scope of this document.
SD clear condition processing and prioritization for protection
triggering is out of the scope of this document.
7. Security Considerations
To be added in a future version of the document.
8. IANA Considerations
<N/A>
9. Acknowledgments
The editors gratefully acknowledge the contributions of Amir Halperin
and Shachar Katz.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Ram, et al. Expires November 2011 [Page 7]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
10.2. Informative References
[2] Sprecher,N., and Farrel,A., "Multiprotocol Label Switching
Transport Profile Survivability Framework", draft-ietf-mpls-tp-
survive-fwk-06(work in progress), June 2010
[3] Swallow,G., Fulignoli,A., Vigoureux,M., Boutros,S., and
Ward,D., "MPLS Fault Management OAM", draft-ietf-mpls-tp-
fault-04 (work in progress), April 2011
[4] Busi,I. and Allan,D., "MPLS-TP OAM Framework", draft-ietf-mpls-
tp-oam-framework-11 (work in progress), February 2011
[5] Bryant,S., Osborne,E., Weingarten,Y., Sprecher,N.,
Fulignoli,A., "MPLS-TP Linear Protection", draft-ietf-mpls-tp-
linear-protection-06 (work in progress), March 2011
This document was prepared using 2-Word-v2.0.template.dot.
Ram, et al. Expires November 2011 [Page 8]
Internet-Draft draft-rkhd-mpls-tp-sd-03 May 2011
Authors' Addresses
Rafi Ram
Orckit-Corrigent
126 Yigal Alon St.
Tel Aviv
Israel
Email: rafir@orckit.com
Daniel Cohn
Orckit-Corrigent
126 Yigal Alon St.
Tel Aviv
Israel
Email: danielc@orckit.com
Masahiro Daikoku
KDDI
3-10-10, Iidabashi, Chiyoda-ku,
Tokyo
Japan
Email: ms-daikoku@kddi.com
Ma Yuxia
ZTE Corp.
China
Email: ma.yuxia@zte.com.cn
Yang Jian
ZTE Corp.
China
Email: yang.jian90@zte.com.cn
Alessandro D'Alessandro
Telecom Italia
Italy
Email: alessandro.dalessandro@telecomitalia.it
Contributors
Amir Halperin
Shachar Katz
Ram, et al. Expires November 2011 [Page 9]