MPLS Working Group R. Ram
Internet Draft D. Cohn
Intended status: Informational Orckit-Corrigent
Expires: September 13, 2011
M. Daikoku
KDDI
M. Yuxia
Yang Jian
ZTE Corp.
L. Levrau
Alcatel-Lucent
March 13, 2011
Link impairment and protection triggering in MPLS-TP
draft-rkhd-mpls-tp-sd-02.txt
Abstract
This document describes guidelines for link impairment fault
condition detection and the use 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 on September 13, 2011.
Ram, et al. Expires September 13, 2011 [Page 1]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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. SF/SD defects and MPLS-TP protection switching............... 4
4. Link impairment detection method ............................ 4
4.1. Guidelines for detection................................ 4
4.2. Examples for detection methods ......................... 5
5. Transmission of link degradation fault indication ........... 6
6. Handling of link failure and degradation fault indication ... 6
7. Security Considerations...................................... 6
8. IANA Considerations ......................................... 6
9. Acknowledgments ............................................. 6
10. References ................................................. 6
10.1. Normative References................................... 6
10.2. Informative References................................. 7
Ram, et al. Expires September 13, 2011 [Page 2]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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, the same performance
monitoring granularity provided by TDM networks is expected from
MPLS-TP networks. For example, OAM maintenance points should remain
in the same locations after TDM to MPLS-TP migration, as SLA revision
is typically NOT feasible for telecommunication carriers and network
operators.
MPLS-TP LSP protection switching can be triggered by fault conditions
and external manual commands. Fault conditions include Signal
Failure (SF) and Signal Degrade (SD). Both conditions can be
detected at an intermediate link based on lower layer indications or
other sub-layer techniques.
Since the protection switching is not necessarily managed by the
transport entity that detects the condition, an impaired link condition
indication must be sent over affected LSPs.
This document describes guidelines for BER-related SF and SD detection
by lower layers indication, and a mechanism for relaying the degraded
LSP condition to the network element handling the LSP protection
switching.
2. Conventions used in this document
BER: Bits Error Rate
LSP: Label Switched Path
LSR: Label Switching Router
MEP: Maintenance End Point
MPLS: Multi-Protocol Label Switching
Ram, et al. Expires September 13, 2011 [Page 3]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011
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. SF/SD defects 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.
In this document, SF refers exclusively to defects derived from
link impairment (i.e. high BER), as opposed to defects detected
through OAM mechanisms (e.g. LOC condition) which are outside the
scope of this document.
4. Link impairment detection method
4.1. Guidelines for detection
The common basis for the guidelines set forth in this section is that
SF and SD conditions SHOULD reflect only BER conditions in the LSP
lower layers, without any influence from non-BER-related conditions
such as network congestion, CPU overload, selective packet discard,
etc.
The following conditions SHOULD be met by the SF and SD condition
detection mechanism:
o Method for determining SF and SD MUST not disrupt the
services transmitted over the link (e.g. add delay or jitter to
real-time traffic)
o Criterion for determining SF and SD MUST be agnostic to the
length of frames transmitted over the link
o Criterion for determining SF and SD MUST be agnostic to the
transmission rate of frames transmitted over the link
Ram, et al. Expires September 13, 2011 [Page 4]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011
o Criterion for determining SF and SD MUST be agnostic to the
type of service carried by the frames transmitted over the link
o Criterion for determining SF and SD MUST be agnostic to the
traffic class of frames transmitted over the link
o Criterion for determining SF and SD MUST be agnostic to drop-
precedence marking of frames transmitted over the link
o Criterion for determining SF and SD MUST be agnostic to link
congestion level
o Criterion for determining SD SHOULD be able to detect low BER
levels (e.g. 10E-8)
o Criterion for determining SF and SD SHOULD have low
misdetection probability
o Criterion for determining SF and SD SHOULD have low false
alarm probability
o Criterion for determining SF and SD SHOULD be agnostic to
number of LSPs or PWs forwarded over the link
o SF and SD conditions MUST be monitored by the lowest server
layer or sub-layer that is not terminated between monitoring
points
o It is RECOMMENDED that the method for determining SF and SD
does not require transmission of additional traffic
Detection of SF and SD conditions is typically based on the same
information source. SF and SD conditions have each a different
associated error rate threshold.
4.2. Examples for detection methods
o A Server MEP [4] related to SONET or SDH sub-layers can determine
SF and SD conditions based on error indication from parity
information in the path overhead.
o A Server MEP related to OTN sub-layer can determine SF and SD
conditions based on error indications from Forward-Error-Correction
functionality inherent in encapsulation.
o A Server MEP related to 10GE PCS sub-layer can determine SF and SD
conditions based on rate of errored 66-bit block headers.
o A Server MEP related to 1GE PCS sub-layer can determine SF and SD
conditions based on rate of 10-bit code violations dispersion
errors.
Ram, et al. Expires September 13, 2011 [Page 5]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011
As specified in section 4.1, these examples assume that the layer
carrying the information used for SF and SD detection is not
terminated by non-MPLS-TP-LSR entities (e.g. media converter).
5. Transmission of link impairment fault indication
When SF condition is detected, a link failure fault indication
SHOULD be transmitted over affected LSPs, in the downstream
direction from the detection point. The link failure indication
will be transmitted immediately following the detection and
periodically until the SF condition is removed. The messages will be
terminated and handled by the downstream MEP.
When SD condition is detected, a link degradation fault indication
SHOULD be transmitted over affected LSPs, 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 MEP.
The encapsulation and mechanism defined in [3] is suitable for
transmission of link failure and degradation fault indications.
It is RECOMMENDED that [3] will include these definitions in future
work.
6. Handling of link failure and degradation fault indications
LSR behavior upon receiving link failure and degradation fault
indications is out of the scope of this document.
SF and SD condition processing and prioritization for protection
triggering is defined in [5].
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 September 13, 2011 [Page 6]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 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-03 (work in progress), October 2010
[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-04 (work in progress), January 2011
This document was prepared using 2-Word-v2.0.template.dot.
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 Corporation
3-11-11 Iidabashi, Chiyodaku
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
Lieven Levrau
Alcatel-Lucent
Email: llevrau@alcatel-lucent.com
Contributors
Amir Halperin
Ram, et al. Expires September 13, 2011 [Page 7]
Internet-Draft draft-rkhd-mpls-tp-sd-02 March 2011
Shachar Katz
Ram, et al. Expires September 13, 2011 [Page 8]