draft-ietf-mpls-tp-fault-04.txt   draft-ietf-mpls-tp-fault-05.txt 
MPLS Working Group G. Swallow, Ed. MPLS Working Group G. Swallow, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Fulignoli, Ed. Intended status: Standards Track A. Fulignoli, Ed.
Expires: October 28, 2011 Ericsson Expires: January 12, 2012 Ericsson
M. Vigoureux, Ed. M. Vigoureux, Ed.
Alcatel-Lucent Alcatel-Lucent
S. Boutros S. Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
D. Ward D. Ward
Juniper Networks, Inc. Juniper Networks, Inc.
April 26, 2011 July 11, 2011
MPLS Fault Management OAM MPLS Fault Management OAM
draft-ietf-mpls-tp-fault-04 draft-ietf-mpls-tp-fault-05
Abstract Abstract
This draft specifies OAM messages to indicate service disruptive This draft specifies OAM messages to indicate service disruptive
conditions for MPLS Transport Profile (MPLS-TP) Label Switched Paths conditions for MPLS based Transport Network Label Switched Paths
(LSPs). The notification mechanism employs a generic method for a (LSPs). The notification mechanism employs a generic method for a
service disruptive condition to be communicated to a Maintenance End service disruptive condition to be communicated to a Maintenance End
Point (MEP). An MPLS Operation, Administration, and Maintenance Point (MEP). An MPLS Operation, Administration, and Maintenance
(OAM) channel is defined along with messages to communicate various (OAM) channel is defined along with messages to communicate various
types of service disruptive conditions. types of service disruptive conditions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on October 28, 2011. This Internet-Draft will expire on January 12, 2012.
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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 23 skipping to change at page 2, line 20
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4
2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . 5 2.1. MPLS Alarm Indication Signal . . . . . . . . . . . . . . . 5
2.1.1. MPLS-TP Link Down Indication . . . . . . . . . . . . . 5 2.1.1. MPLS Link Down Indication . . . . . . . . . . . . . . 5
2.2. MPLS-TP Lock Report . . . . . . . . . . . . . . . . . . . 6 2.2. MPLS Lock Report . . . . . . . . . . . . . . . . . . . . . 6
3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 6 2.3. Propagation of MPLS Fault Messages . . . . . . . . . . . . 6
3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 7
4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7
4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 8 4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 9
4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9 4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9
4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10 4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10
4.1.3. International Carrier Code . . . . . . . . . . . . . . 10
5. Sending and Receiving Fault Management Messages . . . . . . . 10 5. Sending and Receiving Fault Management Messages . . . . . . . 10
5.1. Sending a Fault Management Message . . . . . . . . . . . . 10 5.1. Sending a Fault Management Message . . . . . . . . . . . . 10
5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11
5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11
6. Minimum Implementation Requirements . . . . . . . . . . . . . 11 6. Minimum Implementation Requirements . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 12 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 12
8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 12 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 12
8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 13 8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In traditional transport networks, circuits such as T1 lines are In traditional transport networks, circuits such as T1 lines are
provisioned on multiple switches. When a disruption occurs on any typically provisioned on multiple switches. When an event that
link or node along the path of such a transport circuit, OAM are causes disruption occurs on any link or node along the path of such a
generated which may in turn suppress alarms and/or activate a backup transport circuit, OAM indications are generated which may in turn
circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to suppress alarms and/or activate a backup circuit. The MPLS based
emulate traditional transport circuits. Therefore a Fault Management Transport Network provides mechanisms equivalent to traditional
(FM) capability must be defined for MPLS. This capability is being transport circuits. Therefore a Fault Management (FM) capability
defined to meet the MPLS-TP requirements as defined in RFC 5654 [1], must be defined for MPLS. This capability is being defined to meet
and the MPLS-TP Operations, Administration and Maintenance the MPLS-TP requirements as defined in RFC 5654 [1], and the MPLS-TP
Requirements as defined in RFC 5860 [2]. However, this mechanism is Operations, Administration and Maintenance Requirements as defined in
intended to be applicable to other aspects of MPLS as well. RFC 5860 [2]. However, this mechanism is intended to be applicable
to other aspects of MPLS as well.
Two broad classes of service disruptive conditions are identified. Two broad classes of service disruptive conditions are identified.
1. Defect: the situation in which the density of anomalies has 1. Defect: the situation in which the density of anomalies has
reached a level where the ability to perform a required function reached a level where the ability to perform a required function
has been interrupted. has been interrupted.
2. Lock: an administrative status in which it is expected that only 2. Lock: an administrative status in which it is expected that only
test traffic, if any, and OAM (dedicated to the LSP) can be sent test traffic, if any, and OAM (dedicated to the LSP) can be sent
on an LSP. on an LSP.
skipping to change at page 3, line 52 skipping to change at page 4, line 9
condition. These are known as: condition. These are known as:
Alarm Indication Signal (AIS) Alarm Indication Signal (AIS)
Lock Report (LKR) Lock Report (LKR)
1.1. Terminology 1.1. Terminology
ACH: Associated Channel Header ACH: Associated Channel Header
ASN: Autonomous System Number
CC: Continuity Check CC: Continuity Check
FM: Fault Management FM: Fault Management
GAL: Generic Associated Channel Label GAL: Generic Associated Channel Label
LOC: Loss of Continuity LOC: Loss of Continuity
LSP: Label Switched Path LSP: Label Switched Path
LSR: Label Switching Router LSR: Label Switching Router
MEP: Maintenance End Point MEP: Maintenance Entity Group End Point
MIP: Maintenance Intermediate Point
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
MPLS-TP: MPLS Transport Profile MPLS-TP: MPLS Transport Profile
OAM: Operations, Administration and Maintenance MS-PW: Multi-Segment Pseudowire
P2MP: Point to Multi-Point
P2P: Point to Point OAM: Operations, Administration and Maintenance
PSC: Protection State Coordination PHP: Penultimate Hop Pop
PW: Pseudowire PW: Pseudowire
TLV: Type Length Value S-PE: PW Switching Provider Edge
TTL: Time To Live TLV: Type, Length, Value
Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. MPLS Fault Management Messages 2. MPLS Fault Management Messages
This document defines messages to indicate service disruptive This document defines messages to indicate service disruptive
conditions. Two messages are defined, Alarm Indication Signal, and conditions. Two messages are defined, Alarm Indication Signal, and
Lock Report. These semantics of the individual messages are Lock Report. These semantics of the individual messages are
described in subsections below. described in subsections below. Fault OAM messages are applicable to
Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires
(MS-PW). As MS-PWs are bidirectional LSPs, for simplicity we use the
term bidir-LSP to mean both of these. Applicability to other types
of LSPs is beyond the scope of this document.
Fault Management messages are carried in-band by using the Associated Fault Management messages are carried in-band of the LSP or MS-PW by
Channel Header (ACH) and Generic Associated Channel Label (GAL) as using the Associated Channel Header (ACH). For Bidirectional Co-
defined in RFC5586 [4]. To facilitate recognition and delivery of Routed LSPs the ACH is identified by the Generic Associated Channel
Fault Management messages, the Fault Management Channel is identified Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and
by a unique ACH codepoint. delivery of Fault Management messages, the Fault Management Channel
is identified by a unique ACH codepoint.
Fault OAM messages are generated by intermediate nodes where an LSP Fault OAM messages are generated by intermediate nodes where a bidir-
is switched. When a server layer, (e.g. a link) used by the LSP LSP is switched and bound to specific server layers based upon static
fails, the intermediate node sends Fault Management messages using configuration or signaling. When a server (sub-)layer, (e.g. a link
the LSP's Fault associated channel back to the endpoint of the LSP. or bidirectional LSP) used by the bidir-LSP fails, the intermediate
node sends Fault Management messages, using the bidir-LSP's Fault
associated channel, downstream to the endpoint of the bidir-LSP.
Strictly speaking, when a server MEP detects a service disruptive Strictly speaking, when a server MEP detects a service disruptive
condition, Fault Management messages are generated by the convergence condition, Fault Management messages are generated by the convergence
server-to-client adaptation function. The messages are sent to the server-to-client adaptation function. The messages are sent to the
client MEPs by inserting them into the affected LSPs in the direction client MEPs by inserting them into the affected bidir-LSPs in the
opposite to the detecting MEP's peer server MEP(s). The message is direction downstream of the fault location. The message is sent
sent periodically until the condition is cleared. periodically until the condition is cleared.
2.1. MPLS-TP Alarm Indication Signal 2.1. MPLS Alarm Indication Signal
The MPLS-TP Alarm Indication Signal (AIS) message is generated in The MPLS Alarm Indication Signal (AIS) message is generated in
response to detecting defects in the server layer. The AIS message response to detecting defects in the server (sub-)layer. The AIS
SHOULD be sent as soon as the condition is detected, that is before message SHOULD be sent as soon as the condition is detected. For
any determination has been made as to whether the condition is example, an AIS message may be sent during a protection switching
persistent and therefore fatal. For example, an AIS message may be event and would cease being sent (or cease being forwarded by the
sent during a protection switching event and would cease being sent protection switch selector) if the protection switch was successful
(or cease being forwarded by the protection switch selector) if the in restoring the link.
protection switch was successful in restoring the link.
The primary purpose of the AIS message is to suppress alarms in the The primary purpose of the AIS message is to suppress alarms in the
MPLS-TP layer network above the level at which the defect occurs. layer network above the level at which the defect occurs. When the
When the Link Down Indication is set, the AIS message MAY be used to Link Down Indication is set, the AIS message MAY be used to trigger
trigger recovery mechanisms. recovery mechanisms.
2.1.1. MPLS-TP Link Down Indication 2.1.1. MPLS Link Down Indication
The LDI flag is set in response to detecting a fatal failure in the The Link Down Indication (LDI) is communicated by setting the L-flag
server layer. The LDI flag MUST NOT be set until the defect has been to 1. The L-flag is set in the AIS message in response to detecting
determined to be fatal. The LDI flag MUST be set if the defect has a fault in the server layer. The L-flag MUST NOT be set until the
been determined to be fatal. For example during a protection defect has been determined to be a fault. The L-flag MUST be set if
switching event the LDI flag is not set. However if the protection the defect has been determined to be a fault. For example during a
switch was unsuccessful in restoring the link within the expected protection switching event the L-flag is not set. However if the
repair time, the LDI flag MUST be set. protection switch was unsuccessful in restoring the link within the
expected repair time, the L-flag MUST be set.
The setting of the LDI flag can be predetermined based on the The setting of the L-flag can be predetermined based on the
protection state. If the Server Layer is protected and both the protection state. For example, if a server layer is protected and
working and protection paths are available, both the active and both the working and protection paths are available, both the active
standby MEPs should be programmed to send AIS with LDI clear upon and standby server MEPs should be programmed to send AIS with the
detecting a defect condition. If the Server Layer is unprotected or L-flag clear upon detecting a defect condition. If the server layer
the Server Layer is protected but only the active path is available, is unprotected or the server layer is protected but only the active
the active MEP should be programmed to send AIS with LDI set upon path is available, the active server MEP should be programmed to send
detecting a defect condition. AIS with the L-flag set upon detecting a defect condition.
The receipt of an AIS message with the LDI flag set MAY be treated as The receipt of an AIS message with the L-flag set MAY be treated as
the equivalent of loss of continuity (LOC) at the client layer. The the equivalent of loss of continuity (LOC) at the client layer. The
choice of treatment is related to the rate at which the Continuity choice of treatment is related to the rate at which the Continuity
Check (CC) function is running. In a normal transport environment, Check (CC) function is running. In a normal transport environment,
CC is run at a high rate in order to detect a failure within 10s of CC is run at a high rate in order to detect a failure within 10s of
milliseconds. In such an environment, the LDI flag may be ignored. milliseconds. In such an environment, the L-flag MAY be ignored and
AIS messages with the LDI flag set SHOULD be treated the same as any the AIS message is used solely for alarm suppression.
other AIS message, that is, used solely for alarm suppression.
In more general MPLS environments the CC function may be running at a In more general MPLS environments the CC function may be running at a
much slower rate. In this environment, the LDI flag enables faster much slower rate. In this environment, the Link Down Indication
switch-over upon a failure occurring along the LSP. enables faster switch-over upon a failure occurring along the bidir-
LSP.
2.2. MPLS-TP Lock Report 2.2. MPLS Lock Report
The MPLS-TP Lock Report (LKR) message is generated when a server The MPLS Lock Report (LKR) message is generated when a server
layer entity has been administratively locked to communicated that (sub-)layer entity has been administratively locked. Its purpose is
condition to inform the client layer entities of that condition. to communicate the locked condition to the client layer entities.
When an MPLS-TP LSP is administratively locked it is not available to When a bidir-LSP is administratively locked it is not available to
carry client traffic. The purpose of the LKR message is to suppress carry client traffic. The purpose of the LKR message is to suppress
alarms in the MPLS-TP layer network above the level at which the alarms in the layer network above the level at which the
defect occurs and to allow the clients to differentiate the lock administrative lock occurs and to allow the clients to differentiate
condition from a defect condition. the lock condition from a defect condition. While the primary
purpose of the LKR message is to suppress alarms, similar to AIS with
the LDI (L-flag set), the receipt of an LKR message MAY be treated as
the equivalent of loss of continuity at the client layer.
The primary purpose of the LKR message is to suppress alarms in the 2.3. Propagation of MPLS Fault Messages
MPLS-TP layer network above the level at which the defect occurs.
Like AIS with the LDI flag set, the receipt of an LKR message MAY be If the CC function is disabled, a MEP SHOULD generate AIS messages
treated as the equivalent of loss of continuity at the client layer. toward any client when when in either the AIS or LCK indication is
raised. Note that the L-flag is not automatically propagated, i.e.
the rules of Section 2.1.1 apply, that is the L-flag is not set until
a fault has been declared.
3. MPLS Fault Management Channel 3. MPLS Fault Management Channel
The MPLS Fault Management channel is identified by the ACH as defined The MPLS Fault Management channel is identified by the ACH as defined
in RFC 5586 [4] with the Channel Type set to the MPLS Fault in RFC 5586 [4] with the Channel Type set to the MPLS Fault
Management (FM) code point = 0xHH. [HH to be assigned by IANA from Management (FM) code point = 0xHH. [HH to be assigned by IANA from
the PW Associated Channel Type registry. Note: An early codepoint the PW Associated Channel Type registry. Note: An early codepoint
allocation has made: 0x0058 Fault OAM (TEMPORARY - expires allocation has made: 0x0058 Fault OAM (TEMPORARY - expires
2011-07-16)] The FM Channel does not use ACH TLVs and MUST not 2011-07-16)] The FM Channel does not use ACH TLVs and MUST NOT
include the ACH TLV header. The FM ACH Channel is shown below. include the ACH TLV header. The FM ACH Channel is shown below.
0 1 2 3 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 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|Version| Reserved | 0xHH Fault Management Channel | |0 0 0 1|Version| Reserved | 0xHH Fault Management Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ | ~
~ MPLS Fault Management Message ~ ~ MPLS Fault Management Message ~
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of the MPLS-TP Fault Management Channel Figure 1: ACH Indication of the MPLS Fault Management Channel
The Fault Management Channel is 0xHH (to be assigned by IANA) The first three fields are defined in RFC 5586 [4].
The Fault Management Channel is 0xHH (to be assigned by IANA).
4. MPLS Fault Management Message Format 4. MPLS Fault Management Message Format
The format of the Fault Management message is shown below. The format of the Fault Management message is shown below.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Resvd | Msg Type | Flags | Refresh Timer | | Vers | Resvd | Msg Type | Flags | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~ | Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~ +-+-+-+-+-+-+-+-+ TLVs ~
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP OAM Message Format Figure 2: MPLS Fault OAM Message Format
Version Version
The Version Number is currently 1. The Version Number is currently 1.
Reserved Reserved
This field MUST be set to zero on transmission and ignored on This field MUST be set to zero on transmission and ignored on
receipt. receipt.
Message Type Message Type
The Message Type indicates the type of condition as listed in the The Message Type indicates the type of condition as listed in the
skipping to change at page 8, line 33 skipping to change at page 8, line 44
set to zero on transmission and ignored on receipt. set to zero on transmission and ignored on receipt.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |L|R| | Reserved |L|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: Flags Figure 3: Flags
L-flag L-flag
Link Down Indication. See section Section 2.1.1 for details on Link Down Indication. The L-flag only has significance in the
AIS message. For the LKR message the L-flag MUST be set to
zero and ignored on receipt. See Section 2.1.1 for details on
setting this bit. setting this bit.
R-flag R-flag
The R-flag is normally set to zero. A setting of one indicates The R-flag is normally set to zero. A setting of one indicates
the removal of a previously sent FM condition. the removal of a previously sent FM condition.
4.1. Fault Management Message TLVs 4.1. Fault Management Message TLVs
TLVs are used in fault OAM to carry information that may not pertain TLVs are used in Fault Management messages to carry information that
to all messages as well as to allow for extensibility. The TLVs may not pertain to all messages as well as to allow for
currently defined are the IF_ID, Global-ID, and ICC. extensibility. The TLVs currently defined are the IF_ID, and the
Global_ID.
TLVs (Type-Length-Value tuples) have the following format: TLVs (Type-Length-Value tuples) have the following format:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | | Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| . | .
. Value . . Value .
skipping to change at page 9, line 32 skipping to change at page 9, line 47
Specifies the length of the Value field in octets. Specifies the length of the Value field in octets.
Value Value
Octet string of Length octets that encodes information to be Octet string of Length octets that encodes information to be
interpreted as specified by the Type field. interpreted as specified by the Type field.
4.1.1. Interface Identifier TLV 4.1.1. Interface Identifier TLV
This TLV carries the Interface Identifier as defined in The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in
draft-ietf-mpls-tp-identifiers [5]. The Type is 0x1. The length is draft-ietf-mpls-tp-identifiers [5]. The Type is 0x1. The length is
0x8. 0x8.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier | | MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number | | MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Interface Identifier TLV Format Figure 5: Interface Identifier TLV Format
4.1.2. Global Identifier 4.1.2. Global Identifier
This TLV carries the Interface Identifier as defined in The Global Identifier (Global_ID) TLV carries the Global_ID as
draft-ietf-mpls-tp-identifiers [5]. The Type is 0x2. The length is defined in draft-ietf-mpls-tp-identifiers [5]. The Type is 0x2. The
0x4. length is 0x4.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global Identifier | | MPLS-TP Global Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Global Identifier TLV Format Figure 6: Global Identifier TLV Format
4.1.3. International Carrier Code
This TLV carries the International Carrier Code. The Type is 0x3.
The length is 0x8. The value is an Octet string padded with nulls.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| International Carrier Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| International Carrier Code (Cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: International Carrier Code
5. Sending and Receiving Fault Management Messages 5. Sending and Receiving Fault Management Messages
5.1. Sending a Fault Management Message 5.1. Sending a Fault Management Message
Service disruptive conditions are indicated by sending FM messages. Service disruptive conditions are indicated by sending FM messages.
The message type is set to the value corresponding to the condition. The message type is set to the value corresponding to the condition.
The refresh timer is set to the maximum time between successive FM The refresh timer is set to the maximum time between successive FM
messages. This value MUST not be changed on successive FM messages. messages. This value MUST NOT be changed on successive FM messages
If the optional clearing procedures are not used, then the default reporting the same incident. If the optional clearing procedures are
value is 1. Otherwise the default value is 20. not used, then the default value is 1 second. Otherwise the default
value is 20 seconds.
A Global-ID TLV or an ICC TLV MAY be included. The IF_ID TLV SHOULD A Global_ID MAY be included. If the R-flag clearing procedures are
be included. If the R-Flag clearing procedures are to be used, the to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV
IF_ID TLV MUST be included. MAY be included.
The message is then sent. The message MUST be refreshed two more The message is then sent. Assuming the condition persists, the
times at an interval of one second. Further refreshes are sent message MUST be retransmitted two more times at an interval of one
according to the value of the refresh timer. Refreshing continues second. Further retransmissions are made according to the value of
until the condition is cleared. the refresh timer. Retransmissions continue until the condition is
cleared.
5.2. Clearing a FM Indication 5.2. Clearing a FM Indication
Ceasing to send FM messages will clear the indication after 3.5 times Ceasing to send FM messages will clear the indication after 3.5 times
the Refresh Timer. To clear an indication more quickly, the the refresh timer. To clear an indication more quickly, the
following procedure is used. The R-Flag of the FM message is set to following procedure is used. The R-flag of the FM message is set to
one. Other fields of the FM message SHOULD NOT be modified. The one. Other fields of the FM message SHOULD NOT be modified. The
message is sent immediately and then refreshed two more times at an message is sent immediately and then retransmitted two more times at
interval of one second. an interval of one second.
5.3. Receiving a FM Indication 5.3. Receiving a FM Indication
When a FM message is received, a MEP examines it to ensure that that When a FM message is received, a MEP examines it to ensure that it is
it is well formed. If the message type is unknown, the message is well formed. If the message type is reserved or unknown, the message
ignored. If the R-Flag is zero, the condition corresponding to the is ignored.
message type is entered. A timer is set to 3.5 times the refresh
timer. If the message is not refreshed within this period, the
condition is cleared. A message is considered a refresh if the
message type and IF_ID match an existing condition and the R-Flag is
set to zero.
If the R-Flag is set to one, the MEP checks to see if a condition If the R-flag is set to zero, the MEP checks to see if a condition
matching the message type and IF_ID exists. If it does not, the
condition to the message type is entered. An expiration-timer is set
to 3.5 times the refresh timer. If the message type and IF_ID match
an existing condition, message is considered a refresh and the
expiration-timer is reset.
If the R-flag is set to one, the MEP checks to see if a condition
matching the message type and IF_ID exists. If it does, that matching the message type and IF_ID exists. If it does, that
condition is cleared. Otherwise the message is ignored. condition is cleared. Otherwise the message is ignored.
If the expiration-time expires, the condition is cleared.
6. Minimum Implementation Requirements 6. Minimum Implementation Requirements
At a minimum an implementation MUST support the following: At a minimum an implementation MUST support the following:
1. Sending AIS and LKR messages at a rate of 1 per second. In 1. Sending AIS and LKR messages at a rate of 1 per second.
particular other values of the Refresh Timer and setting the R
bit to value other than zero need not be supported.
2. Support of the sending the LDI flag. 2. Support of setting the L-flag to indicated a fault.
3. Receiving AIS and LKR messages with any allowed Refresh Timer 3. Receiving AIS and LKR messages with any allowed Refresh Timer
value. value.
The following items are optional to implement. The following items are optional to implement.
1. Support of receiving the LDI flag. 1. Sending AIS and LKR message with other values of the Refresh
Timer other than 1 second.
2. Support of receiving the R flag. 2. Support of receiving the L-flag.
3. All TLVs. 3. Support of setting the R-flag to a value other than zero.
4. Support of receiving the R-flag.
5. All TLVs.
7. Security Considerations 7. Security Considerations
Spurious fault OAM messages form a vector for a denial of service Spurious fault OAM messages form a vector for a denial of service
attack. However, since these messages are carried in a control attack. However, since these messages are carried in a control
channel, one would have to gain access to a node providing the channel, except of one case discussed below, one would have to gain
service in order to effect such an attack. Since transport networks access to a node providing the service in order to effect such an
are usually operated as a walled garden, such threats are less attack. Since transport networks are usually operated as a walled
likely. garden, such threats are less likely. If external MPLS traffic is
mapped to a bidirectional LSP via PHP forwarding operation, it is
possible to insert a GAL label followed by a fault OAM message. In
such a situation an operator SHOULD filter any frames with the GAL
label at the top of the label stack.
8. IANA Considerations 8. IANA Considerations
8.1. Pseudowire Associated Channel Type 8.1. Pseudowire Associated Channel Type
Fault OAM requires a unique Associated Channel Type which are Fault OAM requires a unique Associated Channel Type which are
assigned by IANA from the Pseudowire Associated Channel Types assigned by IANA from the Pseudowire Associated Channel Types
Registry. Registry.
Registry: Registry:
skipping to change at page 13, line 26 skipping to change at page 13, line 36
in the range 192-248 are made via "Specification Required"; values in in the range 192-248 are made via "Specification Required"; values in
the range 248-255 are for Private Use, and MUST NOT be allocated. the range 248-255 are for Private Use, and MUST NOT be allocated.
TLVs defined in this document are: TLVs defined in this document are:
Value TLV Name Value TLV Name
----- ------- ----- -------
0 Reserved 0 Reserved
1 Interface Identifier TLV 1 Interface Identifier TLV
2 Global Identifier 2 Global Identifier
3 International Carrier Code
9. References
9.1. Normative References 9. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S.
Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, Ueno, "Requirements of an MPLS Transport Profile", RFC 5654,
September 2009. September 2009.
[2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
Operations, Administration, and Maintenance (OAM) in MPLS Operations, Administration, and Maintenance (OAM) in MPLS
Transport Networks", RFC 5860, May 2010. Transport Networks", RFC 5860, May 2010.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers", [5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-04 (work in progress), draft-ietf-mpls-tp-identifiers-06 (work in progress), June 2011.
March 2011.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
9.2. Informative References
Authors' Addresses Authors' Addresses
George Swallow (editor) George Swallow (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
United States United States
Email: swallow@cisco.com Email: swallow@cisco.com
 End of changes. 65 change blocks. 
167 lines changed or deleted 170 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/