draft-ietf-mpls-tp-fault-02.txt   draft-ietf-mpls-tp-fault-03.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 6, 2011 Ericsson Expires: April 28, 2011 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.
July 5, 2010 October 25, 2010
MPLS Fault Management OAM MPLS Fault Management OAM
draft-ietf-mpls-tp-fault-02 draft-ietf-mpls-tp-fault-03
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 Transport Profile (MPLS-TP) 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 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 January 6, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 24 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4
2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . 5 2.1. MPLS-TP Alarm Indication Signal . . . . . . . . . . . . . 5
2.1.1. MPLS-TP Link Down Indication . . . . . . . . . . . . . 5 2.1.1. MPLS-TP Link Down Indication . . . . . . . . . . . . . 5
2.2. MPLS-TP Lock Report . . . . . . . . . . . . . . . . . . . 6 2.2. MPLS-TP Lock Report . . . . . . . . . . . . . . . . . . . 6
3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 6 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 6
4. MPLS Fault Management Message Format . . . . . . . . . . . . . 6 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7
4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 8 4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 8
4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9 4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9
4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 9 4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10
4.1.3. International Carrier Code . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11
5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 10 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Minimum Implementation Requirements . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 11 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 12
7.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 12 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 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 provisioned on multiple switches. When a disruption occurs on any
link or node along the path of such a transport circuit, OAM are link or node along the path of such a transport circuit, OAM are
generated which may in turn suppress alarms and/or activate a backup generated which may in turn suppress alarms and/or activate a backup
circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to circuit. The MPLS Transport Profile (MPLS-TP) provides mechanisms to
emulate traditional transport circuits. Therefore a Fault Management emulate traditional transport circuits. Therefore a Fault Management
(FM) capability must be defined for MPLS. This capability is being (FM) capability must be defined for MPLS. This capability is being
defined to meet the MPLS-TP requirements as defined in RFC 5654 [1], defined to meet the MPLS-TP requirements as defined in RFC 5654 [1],
and the MPLS-TP Operations, Administration and Maintenance and the MPLS-TP Operations, Administration and Maintenance
Requirements as defined in RFC 5860 [2]. However, this mechanism is Requirements as defined in RFC 5860 [2]. However, this mechanism is
intended to be applicable to other aspects of MPLS as well. intended to be applicable to other aspects of MPLS as well.
Two broad classes 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.
Within the Defect class, a further category, Fault is identified. A Within the Defect class, a further category, Fault is identified. A
fault is the inability of a function to perform a required action. A fault is the inability of a function to perform a required action. A
fault is a persistent defect. fault is a persistent defect.
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 three 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
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 ASN: Autonomous System Number
CC: Continuity Check
FM: Fault Management FM: Fault Management
GAL: Generic Associated Channel Label GAL: Generic Associated Channel Label
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 End Point
MIP: Maintenance Intermediate Point MIP: Maintenance Intermediate Point
MPLS: Multi-Protocol Label Switching MPLS: Multi-Protocol Label Switching
skipping to change at page 4, line 43 skipping to change at page 4, line 47
Requirements Language 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 Management messages are carried in-band by using the Associated Fault Management messages are carried in-band by using the Associated
Channel Header (ACH) and Generic Associated Channel Label (GAL) as Channel Header (ACH) and Generic Associated Channel Label (GAL) as
defined in RFC5586 [4]. To facilitate recognition and delivery of defined in RFC5586 [4]. To facilitate recognition and delivery of
Fault Management messages, the Fault Management Channel is identified Fault Management messages, the Fault Management Channel is identified
by a unique ACH codepoint. 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 an LSP
skipping to change at page 5, line 28 skipping to change at page 5, line 33
The MPLS-TP Alarm Indication Signal (AIS) message is generated in The MPLS-TP 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 layer. The AIS message
SHOULD be sent as soon as the condition is detected, that is before SHOULD be sent as soon as the condition is detected, that is before
any determination has been made as to whether the condition is any determination has been made as to whether the condition is
persistent and therefore fatal. For example, an AIS message may be persistent and therefore fatal. For example, an AIS message may be
sent during a protection switching event and would cease being sent sent during a protection switching event and would cease being sent
(or cease being forwarded by the protection switch selector) if the (or cease being forwarded by the protection switch selector) if the
protection switch was successful in restoring the link. protection switch was successful in restoring the link.
Its primary purpose is to suppress alarms in the MPLS-TP layer The primary purpose of the AIS message is to suppress alarms in the
network above the level at which the defect occurs. The AIS message MPLS-TP layer network above the level at which the defect occurs.
MAY be used to trigger recovery mechanisms. It should be noted that When the Link Down Indication is set, the AIS message MAY be used to
such use would be subject to false positives, e.g. unnecessary trigger recovery mechanisms.
protection switching events in the client layer.
2.1.1. MPLS-TP Link Down Indication 2.1.1. MPLS-TP Link Down Indication
The LDI flag is set in response to detecting a fatal failure in the The LDI flag is set in response to detecting a fatal failure in the
server layer. The LDI flag MUST NOT be set until the defect has been server layer. The LDI flag MUST NOT be set until the defect has been
determined to be fatal. For example during a protection switching determined to be fatal. The LDI flag MUST be set if the defect has
event the LDI flag is not set. However if the protection switch was been determined to be fatal. For example during a protection
unsuccessful in restoring the link within the expected repair time, switching event the LDI flag is not set. However if the protection
the LDI flag MUST be set. switch was unsuccessful in restoring the link within the expected
repair time, the LDI flag MUST be set.
The setting of the LDI flag can be predetermined based on the
protection state. If the Server Layer is protected and both the
working and protection paths are available, both the active and
standby MEPs should be programmed to send AIS with LDI clear upon
detecting a defect condition. If the Server Layer is unprotected or
the Server Layer is protected but only the active path is available,
the active MEP should be programmed to send AIS with LDI 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 LDI flag set MAY be treated as
the equivalent of loss of continuity at the client layer. The choice the equivalent of loss of continuity (LOC) at the client layer. The
of treatment is related to the rate at which the Continuity Check choice of treatment is related to the rate at which the Continuity
(CC) function is running. In a normal transport environment, CC is Check (CC) function is running. In a normal transport environment,
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, AIS messages with the LDI flag milliseconds. In such an environment, the LDI flag may be ignored.
set should be treated the same as any other AIS message, that is, AIS messages with the LDI flag set SHOULD be treated the same as any
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 LDI flag enables faster
switch-over upon a failure occurring along the LSP. switch-over upon a failure occurring along the LSP.
2.2. MPLS-TP Lock Report 2.2. MPLS-TP Lock Report
The MPLS-TP Lock Report (LKR) message is generated when a server The MPLS-TP Lock Report (LKR) message is generated when a server
layer entity has been administratively locked to communicated that layer entity has been administratively locked to communicated that
condition to inform the client layer entities of that condition. condition to inform the client layer entities of that condition.
When an MPLS-TP LSP is administratively locked it is not available to When an MPLS-TP LSP is administratively locked it is not available to
carry client traffic. Its purpose is to suppress alarms in the carry client traffic. The purpose of the LKR message is to suppress
MPLS-TP layer network above the level at which the defect occurs and alarms in the MPLS-TP layer network above the level at which the
to allow the clients to differentiate the lock condition from a defect occurs and to allow the clients to differentiate the lock
defect condition. condition from a defect condition.
The receipt of an LKR message MAY be treated as the equivalent of The primary purpose of the LKR message is to suppress alarms in the
loss of continuity at the client layer. Like AIS it also is used to MPLS-TP layer network above the level at which the defect occurs.
suppress alarms. Like AIS with the LDI flag set, the receipt of an LKR message MAY be
treated as the equivalent of loss of continuity at the client layer.
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.] The FM Channel does not the PW Associated Channel Type registry. Note: An early codepoint
use ACH TLVs and MUST not include the ACH TLV header. The FM ACH allocation has made: 0x0058 Fault OAM (TEMPORARY - expires
Channel is shown below. 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.
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 7, line 40 skipping to change at page 8, line 14
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)
Refresh Timer Refresh Timer
The maximum time between successive FM messages specified in The maximum time between successive FM messages specified in
seconds. The range is 1 to 65535. The value 0 is not permitted. seconds. The range is 1 to 20. The value 0 is not permitted.
Total TLV Length Total TLV Length
The total TLV length is the total of all included TLVs. At this The total TLV length is the total of all included TLVs.
time no TLVs are defined.
Flags Flags
Two flags are defined. The reserved flags in this field MUST be Two flags are defined. The reserved flags in this field MUST be
set to zero on transmission and ignored on receipt. set to zero on transmission and ignored on receipt.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |L|R| | Reserved |L|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 10, line 30 skipping to change at page 11, line 9
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 If the optional clearing procedures are not used, then the default
value is 1. Otherwise the default value is 20. value is 1. Otherwise the default value is 20.
A Global-ID TLV or an ICC TLV MAY be included. The IF_ID TLV SHOULD A Global-ID TLV or an ICC TLV MAY be included. The IF_ID TLV SHOULD
be included. If the R-Flag clearing procedures are to be used, the be included. If the R-Flag clearing procedures are to be used, the
IF_ID TLV MUST be included. IF_ID TLV MUST be included.
The message is then sent. The message MUST be refreshed twice at an The message is then sent. The message MUST be refreshed two more
interval of one second. Further refreshes are sent according to the times at an interval of one second. Further refreshes are sent
value of the refresh timer. Refreshing continues until the condition according to the value of the refresh timer. Refreshing continues
is cleared. 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 twice at an interval message is sent immediately and then refreshed two more times at an
of one second. 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 that
it is well formed. If the message type is unknown, the message is it is well formed. If the message type is unknown, the message is
ignored. If the R-Flag is zero, the condition corresponding to the ignored. If the R-Flag is zero, the condition corresponding to the
message type is entered. A timer is set to 3.5 times the refresh 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 timer. If the message is not refreshed within this period, the
condition is cleared. A message is considered a refresh if 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 message type and IF_ID match an existing condition and the R-Flag is
set to zero. 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 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.
6. Security Considerations 6. Minimum Implementation Requirements
At a minimum an implementation MUST support the following:
1. Sending AIS and LKR messages at a rate of 1 per second. In
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.
3. Receiving AIS and LKR messages with any allowed Refresh Timer
value.
The following items are optional to implement.
1. Support of receiving the LDI flag.
2. Support of receiving the R flag.
3. All TLVs.
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, one would have to gain access to a node providing the
service in order to effect such an attack. Since transport networks service in order to effect such an attack. Since transport networks
are usually operated as a walled garden, such threats are less are usually operated as a walled garden, such threats are less
likely. likely.
7. IANA Considerations 8. IANA Considerations
7.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)
7.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 [6]) 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)
7.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 [6]), "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
skipping to change at page 12, line 33 skipping to change at page 13, line 28
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 3 International Carrier Code
8. References 9. References
8.1. Normative 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. and G. Swallow, "MPLS-TP Identifiers", [5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers",
draft-ietf-mpls-tp-identifiers-01 (work in progress), draft-ietf-mpls-tp-identifiers-03 (work in progress),
March 2010. October 2010.
[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.
8.2. Informative References 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. 31 change blocks. 
67 lines changed or deleted 103 lines changed or added

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