One document matched: draft-he-mpls-tp-csf-02.txt
Differences from draft-he-mpls-tp-csf-01.txt
Network Working Group J.He
Internet Draft Huawei Technologies
Intended status: Standard Track
H.Li
China Mobile
E. Bellagamba
Ericsson
Expires: January 2011 July 12, 2010
Indication of Client Failure in MPLS-TP
draft-he-mpls-tp-csf-02.txt
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-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 12, 2011.
Abstract
This document describes a Multi-Protocol Label Switching Transport
Profile (MPLS-TP) Operations, Administration and Maintenance (OAM)
tool to propagate a client failure indication across an MPLS-TP
network in case the propagation of failure status in the client layer
is not supported.
He, et al. Expires January 12, 2011 [Page 1]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
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 [RFC2119].
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Mechanisms of CSF...........................................3
3.1. General................................................3
3.2. Transmission of CSF....................................5
3.3. Reception of CSF.......................................5
3.4. Configuration of CSF...................................5
4. Frame format of CSF.........................................6
5. Consequent actions..........................................7
6. Security Considerations.....................................7
7. IANA Considerations.........................................8
8. Acknowledgments.............................................8
9. References..................................................8
9.1. Normative References...................................8
9.2. Informative References.................................8
10. Authors' Addresses.........................................9
1. Introduction
In transport network OAM functionalities are important and
fundamental to ease operational complexity, enhance network
availability and meet service performance objectives by efficient and
automatic detection, handling, diagnosis and appropriate reporting of
defects and performance monitoring.
In the case of server layer defects detected in a transport network,
normally an AIS/FDI is generated for the downstream client signal as
an indication to the downstream network elements that the Client
signal is missing due to a server layer defect.
According to [MPLS-TP Framework], MPLS-TP clients include PW and
network layer clients. Examples of network layer clients include IP,
MPLS and MPLS-TP.
In cases the client service to be carried by MPLS-TP networks does
not provide mechanisms to propagate its failure information on top of
MPLS-TP networks (e.g. not needed in the original application of the
client signal, the signal was originally at the bottom of the layer
He, et al. Expires January 12, 2011 [Page 2]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
stack and it was not expected to be transported over a server layer),
while such an indication is needed by the downstream, it is necessary
that MPLS-TP OAM provides such a tool to help propagate client
failure indication to the far end on detection of a failure of the
ingress client signal.
This document defines a MPLS-TP OAM tool as Client Signal Fail
indication (CSF) to propagate client failures and their clearance
across a MPLS-TP domain.
2. Terminology
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 [RFC2119].
The reader is assumed to be familiar with the terminology in MPLS-TP.
The relationship between ITU-T and IETF terminologies on MPLS-TP can
be found in [Rosetta stone].
ACH: Associated Channel Header
AIS: Alarm Indication Signal
CSF: Client Signal Fail indication
FDI: Forward Defect Indication
LSR: Label Switching Router
MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point
OAM: Operations, Administration and Maintenance
MPLS-TP: MPLS Transport Profile
RDI: Remote Defect Indication
3. Mechanisms of CSF
3.1. General
Client Signal Fail indication (CSF) provides a function to enable a
MEP to propagate a client failure indication to its peer MEP across a
He, et al. Expires January 12, 2011 [Page 3]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
MPLS-TP network in case the client service itself does not support
propagation of its failure status.
Packets with CSF information can be issued by a MEP, upon receiving
failure information from its client service. Detection rules for
client failure events are client-specific and are therefore outside
the scope of this document.
+---+ +---+ +---+ +---+
| | | |-->CSF | | | |
| A |--X--| B |-----------------| C |------| D |
+---+ +---+ +---+ +---+
|<--MPLS-TP domain-->|
Figure 1 Use case of CSF
Figure 1 depicts a typical connection scenario between two client
network elements (Node A and Node D) interconnected through MPLS-TP
transport network. Client Node A connects to MPLS-TP Node B and
Client Node D connects to MPLS-TP Node C. Node B and C support MPLS-
TP MEP function.
If a failure is detected between Node A and Node B and is taken as a
native client failure condition, the MEP function in Node B will
initiate CSF signal and it will be sent to Node C through MPLS-TP
network. CSF signal will be extracted at Node C as an indication of
client signal failure. Further, this may be mapped back into native
client failure indication and regenerated towards client Node D.
Node B learns the failure between A and B either by direct detection
of signal fail (e.g. loss of signal) or by some fault indications
between A and B (e.g. RDI, AIS/FDI).
If the connection between Node A and B recovers, Node B may stop
sending CSF signals to Node C (implicit failure clearance mechanism)
or explicitly send failure clearance indication (e.g. by flags in CSF
PDU format) to Node C to help expedite clearance of native client
failure conditions.
Accordingly, Node C will clear client failure condition when a valid
client data frame is received and no CSF is received (implicit
failure clearance mechanism) or upon receiving explicit failure
clearance indication.
He, et al. Expires January 12, 2011 [Page 4]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
3.2. Transmission of CSF
Upon learning signal failure condition of its client-layer the MEP
can immediately start transmitting periodic packets with CSF
information. A MEP continues to transmit periodic packets with CSF
information until the client-layer signal failure condition is
cleared.
The clearance of CSF condition can be communicated to the peer MEP
via:
- stopping transmission of CSF signal or
- forwarding CSF PDU with clearance indication.
Transmission of packets with CSF information can be enabled or
disabled on a MEP.
Detection and clearance rules for CSF events are client and
application specific and outside the scope of this draft.
The period of CSF generation is client and application specific.
3.3. Reception of CSF
Upon receiving a packet with CSF information a MEP either declares or
clears a client-layer signal fail condition according to the received
CSF information and propagates this as a signal fail indication to
its client-layer.
3.4. Configuration of CSF
Specific configuration information required by a MEP to support CSF
transmission is the following:
CSF transmission period - this is application dependent.
PHB - identifies the per-hop behavior of packet with CSF information.
A MIP is transparent to packets with CSF information and therefore
does not require any information to support CSF functionality.
He, et al. Expires January 12, 2011 [Page 5]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
4. Frame format of CSF
Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated
using the ACH, according to [RFC 5586].
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|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CSF(0xXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Reserved 1 | Flags | Reserved 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Frame format of CSF
The first four bytes represent the G-ACH ([RFC 5586]):
- first nibble: set to 0001b to indicate a control channel
associated with a PW, a LSP or a Section;
- G-ACH Version(bits 4 to 7): set to 0, as specified in [RFC 5586]
- G-ACH Reserved (bits 8 to 15): set to 0 and ignored on
reception, as specified in [RFC 5586];
- G-ACH Channel Type (Bits 16 to 31): value 0xXX identifies the
payload as CSF PDU. To be assigned by IANA.
- CSF Version (Bits 32 to 39): Set to 0;
- CSF Reserved 1 (Bits 40 to 47): This field MUST be set to zero
on transmission and ignored on receipt;
- CSF Reserved 2 (Bits 56 to 63): This field MUST be set to zero
on transmission and ignored on receipt;
- Total TLV Length: Total of all included TLVs. No TLVs are
defined currently. The value is 0.
He, et al. Expires January 12, 2011 [Page 6]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Res | Type | Period |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 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;
- Type (Bits 50 to 52): Set to the following values to indicate
CSF types
Value Type
000 Client Signal Fail - Loss of Signal (CSF-LOS)
001 Client Signal Fail - Forward Defect Indication (CSF-FDI)
010 Client Signal Fail - Reverse Defect Indication (CSF-RDI)
011 Clearance of Client Signal Fail - (CSF-Clear)
- Period (Bits 53 to 55): CSF transmission period and can be
configured.
5. Consequent actions
The original usage of CSF is to transport a client signal fail
condition at the input of the transport network to the output port of
the transport network for clients that do not have AIS defined.
CSF allows the transport network to create a condition at the output
port of the transport network such that the customer input port is
able to detect and alarm that there is no data arriving i.e. the
connection is interrupted. In this case, customers may choose another
transport network or another port to continue communication.
6. Security Considerations
Malicious insertion of spurious CSF signals (e.g. DoS) is not quite
likely in a transport network since transport networks are usually
self-managed by operators and providers.
He, et al. Expires January 12, 2011 [Page 7]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
7. IANA Considerations
This document requests that IANA allocates a channel type of G-ACH
for CSF function to be used in MPLS-TP OAM.
8. Acknowledgments
To be added in a future version of the document
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5586] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal,
R., "MPLS Generic Associated Channel", RFC5586, June 2009
[ITU-T Recommendation G.7041] "Generic framing procedure (GFP)", ITU-
T G.7041, October 2008
[RFC 5654] Niven-Jenkins, B., Brungard, D., Betts, M., "Requirements
of an MPLS Transport Profile", RFC 5654, September 2009
[RFC 5860] Vigoureux, M., Ward, D., and Betts, M., "Requirements for
OAM in MPLS Transport Networks", RFC5860, May 2010
[RFC 5921] Bocci, M., Bryant, S., Frost, D., "A Framework for MPLS in
Transport Networks", RFC 5921, 2010
9.2. Informative References
[MPLS-TP OAM Frmk] Busi,I., Niven-Jenkins, B., Allan,D., "MPLS-TP OAM
Framework and Overview", draft-ietf-mpls-tp-oam-framework-
06(work in progress), April 2010
[Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A
Thesaurus for the Terminology used in Multiprotocol Label
Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-
T's Transport Network Recommendations", draft-ietf-mpls-tp-
rosetta-stone-02 (work in progress), May 2010
He, et al. Expires January 12, 2011 [Page 8]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
10. Authors' Addresses
Jia He
Huawei Technologies Co., Ltd.
Email: hejia@huawei.com
Han Li
China Mobile Communications Corporation
Email: lihan@chinamobile.com
Elisa Bellagamba
Ericsson
Email: elisa.bellagamba@ericsson.com
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
He, et al. Expires January 12, 2011 [Page 9]
Internet-Draft Indication of Client Failure in MPLS-TP July 2010
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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 Simplified BSD License.
He, et al. Expires January 12, 2011 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 05:32:56 |