draft-ietf-mpls-tp-fault-05.txt   draft-ietf-mpls-tp-fault-06.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: January 12, 2012 Ericsson Expires: February 16, 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.
August 15, 2011
July 11, 2011
MPLS Fault Management OAM MPLS Fault Management OAM
draft-ietf-mpls-tp-fault-05 draft-ietf-mpls-tp-fault-06
Abstract Abstract
This draft specifies OAM messages to indicate service disruptive This draft specifies OAM messages to indicate service disruptive
conditions for MPLS based Transport Network 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.
skipping to change at page 1, line 44 skipping to change at page 1, line 43
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 January 12, 2012. This Internet-Draft will expire on February 16, 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 38 skipping to change at page 2, line 36
4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7
4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 9 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
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 . . . . . . . . . . . . . . . . . . . . . 13
8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 12 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 13
8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 12 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 13
8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 13 8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
In traditional transport networks, circuits such as T1 lines are In traditional transport networks, circuits such as T1 lines are
typically provisioned on multiple switches. When an event that typically provisioned on multiple switches. When an event that
causes disruption occurs on any link or node along the path of such a causes disruption occurs on any link or node along the path of such a
transport circuit, OAM indications are generated which may in turn transport circuit, OAM indications are generated which may in turn
suppress alarms and/or activate a backup circuit. The MPLS based suppress alarms and/or activate a backup circuit. The MPLS based
Transport Network provides mechanisms equivalent to traditional Transport Network provides mechanisms equivalent to traditional
transport circuits. Therefore a Fault Management (FM) capability transport circuits. Therefore a Fault Management (FM) capability
must be defined for MPLS. This capability is being defined to meet must be defined for MPLS. This capability is being defined to meet
the MPLS-TP requirements as defined in RFC 5654 [1], and the MPLS-TP the MPLS-TP requirements as defined in RFC 5654 [1], and the MPLS-TP
Operations, Administration and Maintenance Requirements as defined in Operations, Administration and Maintenance Requirements as defined in
RFC 5860 [2]. However, this mechanism is intended to be applicable RFC 5860 [2]. These mechanisms are intended to be applicable to
to other aspects of MPLS as well. other aspects of MPLS as well. However, applicability to other types
of LSPs is beyond the scope of this document.
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. Fault: 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.
Within the Defect class, a further category, Fault is identified. A Within the Fault class, a further category, Defect is identified. A
fault is the inability of a function to perform a required action. A defect is the inability of a function to perform a required action.
fault is a persistent defect. A defect is a persistent fault.
This document specifies an MPLS OAM channel called an "MPLS-OAM Fault This document specifies an MPLS OAM channel called an "MPLS-OAM Fault
Management (FM)" channel. A single message format and a set of Management (FM)" channel. A single message format and a set of
procedures are defined to communicate service disruptive conditions procedures are defined to communicate service disruptive conditions
from the location where they occur to the endpoints of LSPs which are from the location where they occur to the endpoints of LSPs which are
affected by those conditions. Multiple message types and flags are affected by those conditions. Multiple message types and flags are
used to indicate and qualify the particular condition. used to indicate and qualify the particular condition.
Corresponding to the two classes of service disruptive conditions Corresponding to the two classes of service disruptive conditions
listed above, two messages are defined to communicate the type of listed above, two messages are defined to communicate the type of
skipping to change at page 4, line 49 skipping to change at page 4, line 49
1.2. 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. The semantics of the individual messages are described
described in subsections below. Fault OAM messages are applicable to in subsections below. Fault OAM messages are applicable to LSPs used
Bidirectional Co-Routed LSPs and to Multi-Segment Pseudowires in the MPLS Transport Profile. Such LSPs are bound to specific
(MS-PW). As MS-PWs are bidirectional LSPs, for simplicity we use the server layers based upon static configuration or signaling in a
term bidir-LSP to mean both of these. Applicability to other types client/server relationship.
of LSPs is beyond the scope of this document.
Fault Management messages are carried in-band of the LSP or MS-PW by Fault Management messages are carried in-band of the client LSP or
using the Associated Channel Header (ACH). For Bidirectional Co- MS-PW by using the Associated Channel Header (ACH). For LSPs other
Routed LSPs the ACH is identified by the Generic Associated Channel than PWs, the ACH is identified by the Generic Associated Channel
Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and
delivery of Fault Management messages, the Fault Management Channel delivery of Fault Management messages, the Fault Management Channel
is identified by a unique ACH codepoint. is identified by a unique ACH codepoint.
Fault OAM messages are generated by intermediate nodes where a bidir- Fault OAM messages are generated by server MEPs at intermediate nodes
LSP is switched and bound to specific server layers based upon static where a client LSP is switched. When a server (sub-)layer, (e.g. a
configuration or signaling. When a server (sub-)layer, (e.g. a link link or bidirectional LSP) used by the client LSP fails, the
or bidirectional LSP) used by the bidir-LSP fails, the intermediate intermediate node sends Fault Management messages downstream towards
node sends Fault Management messages, using the bidir-LSP's Fault the endpoint of the LSP. Strictly speaking, when a server MEP
associated channel, downstream to the endpoint of the bidir-LSP. detects a service disruptive condition, Fault Management messages are
Strictly speaking, when a server MEP detects a service disruptive generated by the convergence server-to-client adaptation function.
condition, Fault Management messages are generated by the convergence The messages are sent to the client MEPs by inserting them into the
server-to-client adaptation function. The messages are sent to the affected client LSPs in the direction downstream of the fault
client MEPs by inserting them into the affected bidir-LSPs in the location. These messages are sent periodically until the condition
direction downstream of the fault location. The message is sent is cleared.
periodically until the condition is cleared.
2.1. MPLS Alarm Indication Signal 2.1. MPLS Alarm Indication Signal
The MPLS 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 (sub-)layer. The AIS response to detecting faults in the server (sub-)layer. The AIS
message SHOULD be sent as soon as the condition is detected. For message SHOULD be sent as soon as the condition is detected. For
example, an AIS message may be sent during a protection switching example, an AIS message may be sent during a protection switching
event and would cease being sent (or cease being forwarded by the event and would cease being sent (or cease being forwarded by the
protection switch selector) if the protection switch was successful protection switch selector) if the protection switch was successful
in restoring the link. 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
layer network above the level at which the defect occurs. When the layer network above the level at which the fault occurs. When the
Link Down Indication is set, the AIS message MAY be used to trigger Link Down Indication is set, the AIS message MAY be used to trigger
recovery mechanisms. recovery mechanisms.
2.1.1. MPLS Link Down Indication 2.1.1. MPLS Link Down Indication
The Link Down Indication (LDI) is communicated by setting the L-flag The Link Down Indication (LDI) is communicated by setting the L-flag
to 1. The L-flag is set in the AIS message in response to detecting to 1. The L-flag is set in the AIS message in response to detecting
a fault in the server layer. The L-flag MUST NOT be set until the a defect in the server layer. The L-flag MUST NOT be set until the
defect has been determined to be a fault. The L-flag MUST be set if fault has been determined to be a defect. The L-flag MUST be set if
the defect has been determined to be a fault. For example during a the fault has been determined to be a defect. For example during a
protection switching event the L-flag is not set. However if the protection switching event the L-flag is not set. However if the
protection switch was unsuccessful in restoring the link within the protection switch was unsuccessful in restoring the link within the
expected repair time, the L-flag MUST be set. expected repair time, the L-flag MUST be set.
The setting of the L-flag can be predetermined based on the The setting of the L-flag can be predetermined based on the
protection state. For example, if a server layer is protected and protection state. For example, if a server layer is protected and
both the working and protection paths are available, both the active both the working and protection paths are available, both the active
and standby server MEPs should be programmed to send AIS with the and standby server MEPs should be programmed to send AIS with the
L-flag clear upon detecting a defect condition. If the server layer L-flag clear upon detecting a fault condition. If the server layer
is unprotected or the server layer is protected but only the active is unprotected or the server layer is protected but only the active
path is available, the active server MEP should be programmed to send path is available, the active server MEP should be programmed to send
AIS with the L-flag set upon detecting a defect condition. AIS with the L-flag set upon detecting a LOC condition. Note again
that the L-flag is not until a defect has been declared. Thus if
there is any hold-off timer associated with the LOC, then the L-flag
is not set until that timer has expired.
The receipt of an AIS message with the L-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 L-flag MAY be ignored and milliseconds. In such an environment, the L-flag MAY be ignored and
the AIS message is used solely for alarm suppression. the AIS message 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 Link Down Indication much slower rate. In this environment, the Link Down Indication
enables faster switch-over upon a failure occurring along the bidir- enables faster switch-over upon a failure occurring along the client
LSP. LSP.
2.2. MPLS Lock Report 2.2. MPLS Lock Report
The MPLS Lock Report (LKR) message is generated when a server The MPLS Lock Report (LKR) message is generated when a server
(sub-)layer entity has been administratively locked. Its purpose is (sub-)layer entity has been administratively locked. Its purpose is
to communicate the locked condition to the client layer entities. to communicate the locked condition to the client layer entities.
When a bidir-LSP is administratively locked it is not available to When a server layer 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 layer network above the level at which the alarms in the layer network above the level at which the
administrative lock occurs and to allow the clients to differentiate administrative lock occurs and to allow the clients to differentiate
the lock condition from a defect condition. While the primary the lock condition from a fault condition. While the primary purpose
purpose of the LKR message is to suppress alarms, similar to AIS with of the LKR message is to suppress alarms, similar to AIS with the LDI
the LDI (L-flag set), the receipt of an LKR message MAY be treated as (L-flag set), the receipt of an LKR message MAY be treated as the
the equivalent of loss of continuity at the client layer. equivalent of loss of continuity at the client layer.
2.3. Propagation of MPLS Fault Messages 2.3. Propagation of MPLS Fault Messages
If the CC function is disabled, a MEP SHOULD generate AIS messages If the CC function is disabled, a MEP SHOULD generate AIS messages
toward any client when when in either the AIS or LCK indication is toward any client when either the AIS or LKR indication is raised.
raised. Note that the L-flag is not automatically propagated, i.e. Note that the L-flag is not automatically propagated. The rules of
the rules of Section 2.1.1 apply, that is the L-flag is not set until Section 2.1.1 apply. In particular, the L-flag is not set until a
a fault has been declared. defect 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 2012-07-20)] 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 ~
~ | ~ |
skipping to change at page 11, line 43 skipping to change at page 11, line 43
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. 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. 1. Sending AIS and LKR messages at a rate of 1 per second.
2. Support of setting the L-flag to indicated a fault. 2. Support of setting the L-flag to indicated a defect.
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. Sending AIS and LKR message with other values of the Refresh 1. Sending AIS and LKR message with other values of the Refresh
Timer other than 1 second. Timer other than 1 second.
2. Support of receiving the L-flag. 2. Support of receiving the L-flag.
3. Support of setting the R-flag to a value other than zero. 3. Support of setting the R-flag to a value other than zero.
4. Support of receiving the R-flag. 4. Support of receiving the R-flag.
5. All TLVs. 5. All TLVs.
7. Security Considerations 7. Security Considerations
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of
the security model of MPLS. MPLS networks make the assumption that
it is very hard to inject traffic into a network, and equally hard to
cause traffic to be directed outside the network. The control plane
protocols utilize hop-by-hop security, and assume a "chain-of-trust"
model such that end-to-end control plane security is not used. For
more information on the generic aspects of MPLS security, see RFC
5920 [6].
This document describes a protocol carried in the G-ACh RFC 5586 [4],
and so is dependent on the security of the G-ACh, itself. The G-ACh
is a generalization of the Associated Channel defined in RFC 4385
[7]. Thus, this document relies heavily on the security mechanisms
provided for the Associated Channel and described in those two
documents.
A specific concern for the G-ACh is that is can be used to provide a
covert channel. This problem is wider than the scope of this
document and does not need to be addressed here, but it should be
noted that the channel provides end-to-end connectivity and SHOULD
NOT be policed by transit nodes. Thus, there is no simple way of
preventing any traffic being carried between in the G-ACh consenting
nodes.
A good discussion of the data plane security of an associated channel
may be found in RFC 5085 [9]. That document also describes some
mitigation techniques.
It should be noted that the G-ACh is essentially connection-oriented
so injection or modification of control messages specified in this
document require the subversion of a transit node. Such subversion
is generally considered hard in MPLS networks, and impossible to
protect against at the protocol level. Management level techniques
are more appropriate.
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, except of one case discussed below, one would have to gain channel, except of one case discussed below, one would have to gain
access to a node providing the service in order to effect such an access to a node providing the service in order to effect such an
attack. Since transport networks are usually operated as a walled attack. Since transport networks are usually operated as a walled
garden, such threats are less likely. If external MPLS traffic is garden, such threats are less likely.
mapped to a bidirectional LSP via PHP forwarding operation, it is
possible to insert a GAL label followed by a fault OAM message. In If external MPLS traffic is mapped to an LSP via a PHP forwarding
such a situation an operator SHOULD filter any frames with the GAL operation, it is possible to insert a GAL label followed by a fault
label at the top of the label stack. OAM message. In such a situation an operator SHOULD filter any fault
OAM messages 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:
Value Description TLV Follows Reference Value Description TLV Follows Reference
----------- ----------------------- ----------- --------- ----------- ----------------------- ----------- ---------
0xHHHH Fault OAM No (This Document) 0xHHHH Fault OAM No (This Document)
8.2. MPLS Fault OAM Message Type Registry 8.2. MPLS Fault OAM Message Type Registry
This sections details the MPLS Fault OAM TLV Registry, a new name This sections details the MPLS Fault OAM TLV Registry, a new name
spaces to be managed by IANA. The Type space is divided into spaces to be managed by IANA. The Type space is divided into
assignment ranges; the following terms are used in describing the assignment ranges; the following terms are used in describing the
procedures by which IANA allocates values: "Standards Action" (as procedures by which IANA allocates values: "Standards Action" (as
defined in RFC 5226 [6]) and "Private Use". defined in RFC 5226 [8]) and "Private Use".
MPLS Fault OAM Message Types take values in the range 0-255. MPLS Fault OAM Message Types take values in the range 0-255.
Assignments in the range 0-251 are via Standards Action; values in Assignments in the range 0-251 are via Standards Action; values in
the range 251-255 are for Private Use, and MUST NOT be allocated. the range 251-255 are for Private Use, and MUST NOT be allocated.
Message Types defined in this document are: Message Types defined in this document are:
Msg Type Description Msg Type Description
-------- ----------------------------- -------- -----------------------------
0x0 Reserved 0x0 Reserved
0x1 Alarm Indication Signal (AIS) 0x1 Alarm Indication Signal (AIS)
0x2 Lock Report (LKR) 0x2 Lock Report (LKR)
skipping to change at page 13, line 22 skipping to change at page 14, line 11
0x0 Reserved 0x0 Reserved
0x1 Alarm Indication Signal (AIS) 0x1 Alarm Indication Signal (AIS)
0x2 Lock Report (LKR) 0x2 Lock Report (LKR)
8.3. MPLS Fault OAM TLV Registry 8.3. MPLS Fault OAM TLV Registry
This sections details the MPLS Fault OAM TLV Registry, a new name This sections details the MPLS Fault OAM TLV Registry, a new name
spaces to be managed by IANA. The Type space is divided into spaces to be managed by IANA. The Type space is divided into
assignment ranges; the following terms are used in describing the assignment ranges; the following terms are used in describing the
procedures by which IANA allocates values: "Standards Action" (as procedures by which IANA allocates values: "Standards Action" (as
defined in RFC 5226 [6]), "Specification Required" and "Private Use". defined in RFC 5226 [8]), "Specification Required" and "Private Use".
MPLS Fault OAM TLVs which take values in the range 0-255. MPLS Fault OAM TLVs which take values in the range 0-255.
Assignments in the range 0-191 are via Standards Action; assignments Assignments in the range 0-191 are via Standards Action; assignments
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
9. Normative References 9. References
9.1. 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-06 (work in progress), June 2011. draft-ietf-mpls-tp-identifiers-07 (work in progress), July 2011.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] Fang, L., "Security Framework for MPLS and GMPLS Networks",
RFC 5920, July 2010.
[7] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN", RFC 4385, February 2006.
[8] 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
[9] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007.
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. 32 change blocks. 
68 lines changed or deleted 122 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/