MPLS Working Group R. Ram
Internet Draft S. Katz
Intended status: Standard Track A. Halperin
Orckit-Corrigent
M. Daikoku
KDDI
June 28, 2010
Expires: January 2011
SD detection and protection triggering in MPLS-TP
draft-rkhd-mpls-tp-sd-00.txt
Abstract
This document describes a guide lines for Signal Degrade (SD) link
fault condition detection and the use of MPLS-TP fault management [5]
for triggering protection switching as define in the MPLS-TP
survivability framework [3].
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 January 2011.
Ram, et al. Expires January 30, 2011 [Page 1]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 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.
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.......................5
5. Transmission of link degradation fault indication............6
6. Handling of link degradation fault indication................6
7. Security Considerations......................................6
8. IANA Considerations.........................................6
9. References..................................................6
9.1. Normative References....................................6
9.2. Informative References..................................6
Ram, et al. Expires January 30, 2011 [Page 2]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
1. Introduction
Telecommunication carriers expect to replace aged TDM Services (e.g.
legacy VPN services) provided by legacy TDM equipments to new VPN
services provided by MPLS-TP Equipments.
From service level agreement (SLA) point of view, any degradations of
service quality and service availability even after migration of
legacy TDM equipment are not allowed.
And, from viewpoint of operational feasibility, the same performance
monitoring granularity and unit are expected. This is because
customer's requirements for network are NOT changed even after
migrating from TDM to MPLS-TP.
MPLS-TP LSP protection switching can be triggered by fault conditions
and external manual commands. The 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 protection switching may be managed at a different
transport entity, an indication about the link condition is required
to be sent over each affected LSP.
This document describes the guidelines for SD detection oriented by
lower layers indications, and overview of mechanism from 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
FM: Fault Management
LM: Loss Measurement
LSP: Label Switched Path
LSR: Label Switching Router
MEP: Maintenance End Point
MIP: Maintenance Intermediate Point
MPLS: Multi-Protocol Label Switching
Ram, et al. Expires January 30, 2011 [Page 3]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
MPLS-TP: MPLS Transport Profile
OAM: Operations, Administration and Maintenance
PSC: Protection State Coordination
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
MPLS-TP survivability framework [3] ability of a network to recover
traffic delivery following degradation of network resources. draft-
ietf-mpls-tp-oam-requirements [6] defines LSP protections mechanism
and the state machine that prioritizes between SF, SD and operator
manual commands.
An LSP is considered to have SD fault, when at least one of the links
it forwarded through has rate of errored bits exceeding a
predetermined BER threshold.
4. SD detection method
4.1. Guidelines for SD detection
The following are principals for determining link signal degrade
condition:
o Method for determining signal degrade MUST not disrupt the
services transmitted over the link (e.g. add delay or jitter to
real time traffic)
o Criterion for determining signal degrade MUST be agnostic to the
length of frames transmitted over the link
o Criterion for determining signal degrade MUST be agnostic to the
rate of frames transmitted over the link
o Criterion for determining signal degrade MUST be agnostic to the
type of service carried by the frames transmitted over the link
Ram, et al. Expires January 30, 2011 [Page 4]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
o Criterion for determining signal degrade MUST be agnostic to the
traffic class of frames transmitted over the link
o Criterion for determining signal degrade MUST be agnostic to drop
precedence marking of frames transmitted over the link
o Criterion for determining signal degrade MUST be agnostic to link
congestion level
o Criterion for determining signal degrade SHOULD be able to detect
low BER condition (e.g. 10E-5)
o Criterion for determining signal degrade SHOULD have low miss-
detection 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 LSPs or PWs forwarded over the link
o Method for determining signal degrade is RECOMMENDED not to
require transmission of traffic exclusively dedicated for this
purpose
4.2. Examples for SD detection methods
A Server MEP [7] related to SONET or SDH sub-layers can determine SD
condition based on errors indication from parity information embedded
in encapsulation.
A Server MEP related to OTN sub-layer can determine SD condition
based on errors indication from Forward-Error-Correction
functionality embedded in encapsulation.
A Server MEP related to 10GE PCS sub-layer can determine SD condition
based on rate of errored 66bit block headers.
A Server MEP related to 1GE PCS sub-layer can determine SD condition
based on rate of 10bit code violations dispersion errors.
These examples would work as long as the layer carrying the
information used for SD detection is not terminated in between two
MPLS-TP transport entities (e.g. by use of media converter).
Ram, et al. Expires January 30, 2011 [Page 5]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
5. Transmission of link degradation fault indication
When SD condition is detected, a link degradation fault indication
[5] is transmitted over each affected LSP, in the down stream
direction from the detection point.
The encapsulation and mechanism for transmission of link degradation
fault indication OAM message [5] are out of the scope of this
document.
6. Handling of link degradation fault indication
The mechanism for entering link degraded fault condition [5] is out
of the scope of this document.
Processing SD fault condition for protection triggering and
prioritization [6] 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. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[2] Bocci,M., and Bryant,S., "A Framework for MPLS in Transport
Networks", draft-ietf-mpls-tp-framework-10 (Work in progress),
February 2010
[3] Sprecher,N., and Farrel,a., "Multiprotocol Label Switching
Transport Profile Survivability Framework", draft-ietf-mpls-tp-
survive-fwk-06(work in progress),
[4] Vigoureux,M., Ward,D., and Betts,M., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
06 (work in progress), March 2010
Ram, et al. Expires January 30, 2011 [Page 6]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
[5] Swallow,G., Fulignoli,A., and Vigoureux,M., "MPLS Fault
Management OAM", draft-ietf-mpls-tp-fault-01 (work in
progress), March 2010
[6] Bryant,S., Sprecher,N., Van Helvoort,H., Fulignoli,A., "MPLS-TP
Linear Protection", draft-ietf-mpls-tp-linear-protection-01
(work in progress), March 2010
[7] Busi,I., Niven-Jenkins,B., Allan,D., "MPLS-TP OAM Framework",
draft-ietf-mpls-tp-oam-framework-06 (work in progress), April
2010
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
Shachar Katz
Orckit-Corrigent
126 Yigal Alon st.
Tel Aviv
Israel
Email: shachark@orckit.com
Ram, et al. Expires January 30, 2011 [Page 7]
Internet-Draft draft-rkhd-mpls-tp-sd-00 June 2010
Amir Halperin
Orckit-Corrigent
126 Yigal Alon st.
Tel Aviv
Israel
Email: amirh@orckit.com
Masahiro Daikoku
KDDI
Email: ms-daikoku@kddi.com
Ram, et al. Expires January 30, 2011 [Page 8]