draft-ietf-mpls-tp-csf-00.txt   draft-ietf-mpls-tp-csf-01.txt 
Network Working Group J.He Network Working Group J.He
Internet Draft Huawei Technologies Internet Draft Huawei Technologies
Intended status: Standard Track Intended status: Standard Track
H.Li H.Li
China Mobile China Mobile
E. Bellagamba E. Bellagamba
Ericsson Ericsson
Expires: August 2011 February 10, 2011 Expires: September 2011 March 14, 2011
Indication of Client Failure in MPLS-TP Indication of Client Failure in MPLS-TP
draft-ietf-mpls-tp-csf-00.txt draft-ietf-mpls-tp-csf-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 10, 2011. This Internet-Draft will expire on September 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document describes a Multi-Protocol Label Switching Transport This document describes a Multi-Protocol Label Switching Transport
Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
tool to propagate a client failure indication across an MPLS-TP protocol to propagate a client failure indication across an MPLS-TP
network in case the propagation of failure status in the client layer network in the case that propagation of failure status in the client
is not supported as required in [RFC5860]. layer is not supported as required in [RFC5860].
Table of Contents Table of Contents
1. Introduction................................................. 2 1. Introduction ................................................ 2
2. Conventions used in this document............................ 3 2. Conventions used in this document............................ 3
2.1. Terminology............................................. 3 2.1. Terminology ............................................ 3
3. Mechanisms of CSF............................................ 4 3. Mechanisms of CSF ........................................... 4
3.1. General................................................. 4 3.1. General ................................................ 4
3.2. Transmission of CSF..................................... 5 3.2. Transmission of CSF..................................... 5
3.3. Reception of CSF........................................ 6 3.3. Reception of CSF........................................ 6
3.4. Configuration of CSF.................................... 6 3.4. Configuration of CSF.................................... 6
4. Frame format of CSF.......................................... 6 4. Frame format of CSF ......................................... 7
5. Consequent actions........................................... 8 5. Consequent actions .......................................... 8
6. Security Considerations...................................... 8 6. Security Considerations...................................... 9
7. IANA Considerations.......................................... 8 7. IANA Considerations ......................................... 9
8. Acknowledgments.............................................. 8 8. Acknowledgments ............................................. 9
9. References................................................... 8 9. References .................................................. 9
9.1. Normative References.................................... 8 9.1. Normative References.................................... 9
9.2. Informative References.................................. 9 9.2. Informative References................................. 10
10. Authors' Addresses ......................................... 9 10. Authors' Addresses ........................................ 10
1. Introduction 1. Introduction
In transport network OAM functionalities are important and In transport networks, OAM functions are important and fundamental to
fundamental to ease operational complexity, enhance network ease operational complexity, enhance network availability and meet
availability and meet service performance objectives by efficient and service performance objectives. This is achieved through automatic
automatic detection, handling, diagnosis and appropriate reporting of detection, handling, diagnosis, appropriate reporting of defects and
defects and performance monitoring. performance monitoring.
As defined in [RFC 5860] MPLS-TP OAM MUST provide a function to As defined in [RFC 5860] MPLS-TP OAM MUST provide a function to
enable the propagation, from edge to edge of an MPLS-TP network, of enable the propagation, from edge to edge of an MPLS-TP network, of
information pertaining to a client (i.e., external to the MPLS-TP information pertaining to a client (i.e., external to the MPLS-TP
network) defect or fault condition detected at an End Point of a PW network) defect or fault condition detected at an End Point of a PW
or LSP, if the client layer OAM functionality does not provide an or LSP, if the client layer OAM functionality does not provide an
alarm notification/propagation functionality (e.g. not needed in the alarm notification/propagation functionality (e.g. not needed in the
original application of the client signal, or the signal was original application of the client signal, or the signal was
originally at the bottom of the layer stack and it was not expected originally at the bottom of the layer stack and it was not expected
to be transported over a server layer), while such an indication is to be transported over a server layer), while such an indication is
needed by the downstream. needed by the downstream.
This document defines such a MPLS-TP OAM tool as Client Signal Fail This document defines a Client Signal Fail (CSF) indication protocol
indication (CSF) to propagate client failures and their clearance in order to propagate client failures and their clearance across a
across a MPLS-TP domain. MPLS-TP domain.
According to [RFC 5921], MPLS-TP supports two native service According to [RFC 5921], MPLS-TP supports two native service
adaptation mechanisms via: adaptation mechanisms via:
1) a PW, to emulate certain services, for example, Ethernet, Frame 1) a Pseudowire, to emulate certain services, for example, Ethernet,
Relay, or PPP / High-Level Data Link Control (HDLC). Frame Relay, or PPP / High-Level Data Link Control (HDLC).
2) an LSP, to provide adaptation for any native service traffic type 2) an LSP, to provide adaptation for any native service traffic type
supported by [RFC3031] and [RFC3032]. Examples of such traffic supported by [RFC3031] and [RFC3032]. Examples of such traffic
types include IP packets and MPLS-labeled packets (PW over LSP, or types include IP packets and MPLS-labeled packets (i.e.: PW over
IP over LSP). LSP, or IP over LSP).
As to the first adaptation mechanism via a PW, the mechanism of CSF As to the first adaptation mechanism via a PW, the mechanism of CSF
function to support propagation of client failure indication follows function to support propagation of client failure indication follows
[static-pw-status]. The PW status relevant to CSF function is AC [static-pw-status]. The PW status relevant to CSF function is AC
fault as defined in [RFC 4447] and [RFC 4446]. fault as defined in [RFC 4447] and [RFC 4446].
As to the second adaptation mechanism via LSP, the mechanism is As to the second adaptation mechanism via LSP, the mechanism is
detailed in this draft and is used in case the client of MPLS-TP can detailed in this draft and is used in case the client of MPLS-TP can
not provide itself with such failure notification/propagation. not provide itself with such failure notification/propagation.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
LSR: Label Switching Router LSR: Label Switching Router
MEP: Maintenance Entity Group End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point MIP: Maintenance Entity Group Intermediate Point
OAM: Operations, Administration, and Maintenance OAM: Operations, Administration, and Maintenance
MPLS-TP: MPLS Transport Profile MPLS-TP: MPLS Transport Profile
PW: Pseudowire
RDI: Remote Defect Indication RDI: Remote Defect Indication
3. Mechanisms of CSF 3. Mechanisms of CSF
3.1. General 3.1. General
Client Signal Fail indication (CSF) provides a function to enable a Client Signal Fail(CSF) indication provides a function to enable a
MEP to propagate a client failure indication to its peer MEP across a MEP to propagate a client failure indication to its peer MEP across a
MPLS-TP network in case the client service itself does not support MPLS-TP network in case the client service itself does not support
propagation of its failure status. propagation of its failure status. A MIP is not intended to generate
or process CSF information.
Packets with CSF information can be issued by a MEP, upon receiving Packets with CSF information can be issued by a MEP, upon receiving
failure information from its client service. Detection rules for failure information from its client service. Detection rules for
client failure events are client-specific and are therefore outside client failure events are client-specific and are therefore outside
the scope of this document. the scope of this document.
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | |-->CSF | | | | | | | |-->CSF | | | |
| A |--X--| B |-----------------| C |------| D | | A |--X--| B |-----------------| C |------| D |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 5, line 29 skipping to change at page 5, line 31
PDU format) to Node C to help expedite clearance of native client PDU format) to Node C to help expedite clearance of native client
failure conditions. failure conditions.
Accordingly, Node C will clear client failure condition when a valid Accordingly, Node C will clear client failure condition when a valid
client data frame is received and no CSF is received (implicit client data frame is received and no CSF is received (implicit
failure clearance mechanism) or upon receiving explicit failure failure clearance mechanism) or upon receiving explicit failure
clearance indication. clearance indication.
3.2. Transmission of CSF 3.2. Transmission of CSF
Upon learning signal failure condition of its client-layer the MEP When CSF function is enabled, upon learning signal failure condition
can immediately start transmitting periodic packets with CSF of its client-layer, the MEP can immediately start transmitting
information. A MEP continues to transmit periodic packets with CSF periodic packets with CSF information to its peer MEP. A MEP
information until the client-layer signal failure condition is continues to transmit periodic packets with CSF information until the
cleared. client-layer signal failure condition is cleared.
The clearance of CSF condition can be communicated to the peer MEP The clearance of CSF condition can be communicated to the peer MEP
via: via:
- Stopping transmission of CSF signal but forwarding client data - Stopping of the transmission of CSF signal but forwarding client
frames, or data frames, or
- Forwarding CSF PDU with clearance indication. - Forwarding CSF PDUs with a clearance indication.
Transmission of packets with CSF information can be enabled or Transmission of packets with CSF information can be enabled or
disabled on a MEP. disabled on a MEP (e.g. through management plane).
Detection and clearance rules for CSF events are client and Detection and clearance rules for CSF events are client and
application specific and outside the scope of this draft. application specific and outside the scope of this draft.
The period of CSF generation is client and application specific and The period of CSF transmission is client and application specific.
outside the scope of this draft. Examples are as follows:
- 3.33ms: for protection switching application.
- 1s: for fault management application.
However, the value 0 is invalid.
3.3. Reception of CSF 3.3. Reception of CSF
Upon receiving a packet with CSF information a MEP either declares or Upon receiving a packet with CSF information a MEP either declares or
clears a client-layer signal fail condition according to the received clears a client-layer signal fail condition according to the received
CSF information and propagates this as a signal fail indication to CSF information and propagates this as a signal fail indication to
its client-layer. its client-layer.
CSF condition is cleared when the receiving MEP
- does not receive CSF signal within an interval of N times the CSF
transmission period (Suggested value of N is 3.5), or
- receives a valid client data frame, or
- receives CSF PDU with CSF-Clear information
3.4. Configuration of CSF 3.4. Configuration of CSF
Specific configuration information required by a MEP to support CSF Specific configuration information required by a MEP to support CSF
transmission is the following: transmission is the following:
CSF transmission period - this is application dependent. CSF transmission period - this is application dependent. Examples are
3.3 ms and 1s.
PHB - identifies the per-hop behavior of packet with CSF information. PHB - identifies the per-hop behavior of packet with CSF information.
A MIP is transparent to packets with CSF information and therefore A MIP is transparent to packets with CSF information and therefore
does not require any information to support CSF functionality. does not require any information to support CSF functionality.
4. Frame format of CSF 4. Frame format of CSF
Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated
using the ACH, according to [RFC 5586]. GAL is used as an alert based using the ACH, according to [RFC 5586]. GAL is used as an alert based
skipping to change at page 7, line 27 skipping to change at page 7, line 50
- CSF Reserved 1 (Bits 40 to 47): This field MUST be set to zero - CSF Reserved 1 (Bits 40 to 47): This field MUST be set to zero
on transmission and ignored on receipt; on transmission and ignored on receipt;
- CSF Reserved 2 (Bits 56 to 63): This field MUST be set to zero - CSF Reserved 2 (Bits 56 to 63): This field MUST be set to zero
on transmission and ignored on receipt; on transmission and ignored on receipt;
- Total TLV Length: Total of all included TLVs. No TLVs are - Total TLV Length: Total of all included TLVs. No TLVs are
defined currently. The value is 0. defined currently. The value is 0.
- TLVs: No TLVs are defined currently.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Res | Type | Period | | Res | Type | Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Format of Flags in CSF PDU Figure 3 Format of Flags in CSF PDU
Figure 3 depicts the format of Flags in CSF PDU. Figure 3 depicts the format of Flags in CSF PDU.
- Flag Reserved (Bits 48 to 49): Set to 0; - Flag Reserved (Bits 48 to 49): Set to 0;
skipping to change at page 8, line 29 skipping to change at page 9, line 13
network or another port to continue communication. network or another port to continue communication.
6. Security Considerations 6. Security Considerations
Malicious insertion of spurious CSF signals (e.g. DoS) is not quite Malicious insertion of spurious CSF signals (e.g. DoS) is not quite
likely in a transport network since transport networks are usually likely in a transport network since transport networks are usually
self-managed by operators and providers. self-managed by operators and providers.
7. IANA Considerations 7. IANA Considerations
This document requests that IANA allocates a new Associated Channel MPLS-TP CSF function requires a new Associated Channel Type to be
Type for CSF function to be used in MPLS-TP OAM. assigned by IANA from the Pseudowire Associated Channel Types
Registry.
Registry:
Value Description
----- -----------------------
0xXX MPLS-TP Client Signal Fail indication (CSF)
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Haiyan Zhang, Adrian Farrel, Loa The authors would like to thank Haiyan Zhang, Adrian Farrel, Loa
Andersson, Matthew Bocci and Andy Malis for their guidance to this Andersson, Matthew Bocci, Andy Malis and Thomas D. Nadeau for their
work. guidance and input to this work.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
skipping to change at page 9, line 31 skipping to change at page 10, line 28
September 2009 September 2009
[RFC 5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [RFC 5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
OAM in MPLS Transport Networks", RFC5860, May 2010 OAM in MPLS Transport Networks", RFC5860, May 2010
[RFC 5921] Bocci, M., Bryant, S., and D. Frost, "A Framework for MPLS [RFC 5921] Bocci, M., Bryant, S., and D. Frost, "A Framework for MPLS
in Transport Networks", RFC 5921, July 2010 in Transport Networks", RFC 5921, July 2010
[static-pw-status] Martini, L., Swallow, G., Heron, G., and M. Bocci, [static-pw-status] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", draft-ietf- "Pseudowire Status for Static Pseudowires", draft-ietf-
pwe3-static-pw-status-01 (work in progress), October 2010 pwe3-static-pw-status-02 (work in progress), March 2011
9.2. Informative References 9.2. Informative References
[MPLS-TP OAM Frmk] Busi,I., and D. Allan, "MPLS-TP OAM Framework and [MPLS-TP OAM Frmk] Busi,I., and D. Allan, "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-09(work in Overview", draft-ietf-mpls-tp-oam-framework-11(work in
progress), October 2010 progress), February 2011
[Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A [Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A
Thesaurus for the Terminology used in Multiprotocol Label Thesaurus for the Terminology used in Multiprotocol Label
Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU- Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-
T's Transport Network Recommendations", draft-ietf-mpls-tp- T's Transport Network Recommendations", draft-ietf-mpls-tp-
rosetta-stone-02 (work in progress), May 2010 rosetta-stone-03 (work in progress), November 2010
10. Authors' Addresses 10. Authors' Addresses
Jia He Jia He
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
Email: hejia@huawei.com Email: hejia@huawei.com
Han Li Han Li
China Mobile Communications Corporation China Mobile Communications Corporation
 End of changes. 29 change blocks. 
59 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/