MPLS Working Group G. Swallow, Ed. Internet-Draft Cisco Systems, Inc. Intended status: Standards Track A. Fulignoli, Ed. Expires: February 16, 2012 Ericsson M. Vigoureux, Ed. Alcatel-Lucent S. Boutros Cisco Systems, Inc. D. Ward Juniper Networks, Inc. August 15, 2011 MPLS Fault Management OAM draft-ietf-mpls-tp-fault-06 Abstract This draft specifies OAM messages to indicate service disruptive conditions for MPLS based Transport Network Label Switched Paths (LSPs). The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance End Point (MEP). An MPLS Operation, Administration, and Maintenance (OAM) channel is defined along with messages to communicate various types of service disruptive conditions. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Swallow, et al. Expires February 16, 2012 [Page 1] Internet-Draft MPLS Fault Management OAM August 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. MPLS Fault Management Messages . . . . . . . . . . . . . . . . 4 2.1. MPLS Alarm Indication Signal . . . . . . . . . . . . . . . 5 2.1.1. MPLS Link Down Indication . . . . . . . . . . . . . . 5 2.2. MPLS Lock Report . . . . . . . . . . . . . . . . . . . . . 6 2.3. Propagation of MPLS Fault Messages . . . . . . . . . . . . 6 3. MPLS Fault Management Channel . . . . . . . . . . . . . . . . 7 4. MPLS Fault Management Message Format . . . . . . . . . . . . . 7 4.1. Fault Management Message TLVs . . . . . . . . . . . . . . 9 4.1.1. Interface Identifier TLV . . . . . . . . . . . . . . . 9 4.1.2. Global Identifier . . . . . . . . . . . . . . . . . . 10 5. Sending and Receiving Fault Management Messages . . . . . . . 10 5.1. Sending a Fault Management Message . . . . . . . . . . . . 10 5.2. Clearing a FM Indication . . . . . . . . . . . . . . . . . 11 5.3. Receiving a FM Indication . . . . . . . . . . . . . . . . 11 6. Minimum Implementation Requirements . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. Pseudowire Associated Channel Type . . . . . . . . . . . . 13 8.2. MPLS Fault OAM Message Type Registry . . . . . . . . . . . 13 8.3. MPLS Fault OAM TLV Registry . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Swallow, et al. Expires February 16, 2012 [Page 2] Internet-Draft MPLS Fault Management OAM August 2011 1. Introduction In traditional transport networks, circuits such as T1 lines are typically provisioned on multiple switches. When an event that causes disruption occurs on any link or node along the path of such a transport circuit, OAM indications are generated which may in turn suppress alarms and/or activate a backup circuit. The MPLS based Transport Network provides mechanisms equivalent to traditional transport circuits. Therefore a Fault Management (FM) capability 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 Operations, Administration and Maintenance Requirements as defined in RFC 5860 [2]. These mechanisms are intended to be applicable to 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. 1. Fault: the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted. 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 on an LSP. Within the Fault class, a further category, Defect is identified. A defect is the inability of a function to perform a required action. A defect is a persistent fault. This document specifies an MPLS OAM channel called an "MPLS-OAM Fault Management (FM)" channel. A single message format and a set of procedures are defined to communicate service disruptive conditions from the location where they occur to the endpoints of LSPs which are affected by those conditions. Multiple message types and flags are used to indicate and qualify the particular condition. Corresponding to the two classes of service disruptive conditions listed above, two messages are defined to communicate the type of condition. These are known as: Alarm Indication Signal (AIS) Lock Report (LKR) Swallow, et al. Expires February 16, 2012 [Page 3] Internet-Draft MPLS Fault Management OAM August 2011 1.1. Terminology ACH: Associated Channel Header CC: Continuity Check FM: Fault Management GAL: Generic Associated Channel Label LOC: Loss of Continuity LSP: Label Switched Path LSR: Label Switching Router MEP: Maintenance Entity Group End Point MPLS: Multi-Protocol Label Switching MPLS-TP: MPLS Transport Profile MS-PW: Multi-Segment Pseudowire OAM: Operations, Administration and Maintenance PHP: Penultimate Hop Pop PW: Pseudowire S-PE: PW Switching Provider Edge TLV: Type, Length, Value 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. MPLS Fault Management Messages This document defines messages to indicate service disruptive conditions. Two messages are defined, Alarm Indication Signal, and Lock Report. The semantics of the individual messages are described in subsections below. Fault OAM messages are applicable to LSPs used in the MPLS Transport Profile. Such LSPs are bound to specific Swallow, et al. Expires February 16, 2012 [Page 4] Internet-Draft MPLS Fault Management OAM August 2011 server layers based upon static configuration or signaling in a client/server relationship. Fault Management messages are carried in-band of the client LSP or MS-PW by using the Associated Channel Header (ACH). For LSPs other than PWs, the ACH is identified by the Generic Associated Channel Label (GAL) as defined in RFC5586 [4]. To facilitate recognition and delivery of Fault Management messages, the Fault Management Channel is identified by a unique ACH codepoint. Fault OAM messages are generated by server MEPs at intermediate nodes where a client LSP is switched. When a server (sub-)layer, (e.g. a link or bidirectional LSP) used by the client LSP fails, the intermediate node sends Fault Management messages downstream towards the endpoint of the LSP. Strictly speaking, when a server MEP detects a service disruptive condition, Fault Management messages are generated by the convergence server-to-client adaptation function. The messages are sent to the client MEPs by inserting them into the affected client LSPs in the direction downstream of the fault location. These messages are sent periodically until the condition is cleared. 2.1. MPLS Alarm Indication Signal The MPLS Alarm Indication Signal (AIS) message is generated in response to detecting faults in the server (sub-)layer. The AIS message SHOULD be sent as soon as the condition is detected. For example, an AIS message may be sent during a protection switching event and would cease being sent (or cease being forwarded by the protection switch selector) if the protection switch was successful in restoring the link. The primary purpose of the AIS message is to suppress alarms in 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 recovery mechanisms. 2.1.1. MPLS Link Down Indication 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 a defect in the server layer. The L-flag MUST NOT be set until the fault has been determined to be a defect. The L-flag MUST be set if 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 switch was unsuccessful in restoring the link within the expected repair time, the L-flag MUST be set. Swallow, et al. Expires February 16, 2012 [Page 5] Internet-Draft MPLS Fault Management OAM August 2011 The setting of the L-flag can be predetermined based on the protection state. For example, if a server layer is protected and both the working and protection paths are available, both the active and standby server MEPs should be programmed to send AIS with the L-flag clear upon detecting a fault condition. If the server layer is unprotected or the server layer is protected but only the active path is available, the active server MEP should be programmed to send 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 equivalent of loss of continuity (LOC) at the client layer. The choice of treatment is related to the rate at which the Continuity 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 milliseconds. In such an environment, the L-flag MAY be ignored and the AIS message is used solely for alarm suppression. In more general MPLS environments the CC function may be running at a much slower rate. In this environment, the Link Down Indication enables faster switch-over upon a failure occurring along the client LSP. 2.2. MPLS Lock Report The MPLS Lock Report (LKR) message is generated when a server (sub-)layer entity has been administratively locked. Its purpose is to communicate the locked condition to the client layer entities. When a server layer is administratively locked it is not available to carry client traffic. The purpose of the LKR message is to suppress alarms in the layer network above the level at which the administrative lock occurs and to allow the clients to differentiate the lock condition from a fault 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. 2.3. Propagation of MPLS Fault Messages If the CC function is disabled, a MEP SHOULD generate AIS messages toward any client when either the AIS or LKR indication is raised. Note that the L-flag is not automatically propagated. The rules of Section 2.1.1 apply. In particular, the L-flag is not set until a defect has been declared. Swallow, et al. Expires February 16, 2012 [Page 6] Internet-Draft MPLS Fault Management OAM August 2011 3. MPLS Fault Management Channel 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 Management (FM) code point = 0xHH. [HH to be assigned by IANA from the PW Associated Channel Type registry. Note: An early codepoint allocation has made: 0x0058 Fault OAM (TEMPORARY - expires 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xHH Fault Management Channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ MPLS Fault Management Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: ACH Indication of the MPLS Fault Management Channel 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 The format of the Fault Management message is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Resvd | Msg Type | Flags | Refresh Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total TLV Len | ~ +-+-+-+-+-+-+-+-+ TLVs ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MPLS Fault OAM Message Format Version Swallow, et al. Expires February 16, 2012 [Page 7] Internet-Draft MPLS Fault Management OAM August 2011 The Version Number is currently 1. Reserved This field MUST be set to zero on transmission and ignored on receipt. Message Type The Message Type indicates the type of condition as listed in the table below. Msg Type Description -------- ----------------------------- 0x0 Reserved 0x1 Alarm Indication Signal (AIS) 0x2 Lock Report (LKR) Refresh Timer The maximum time between successive FM messages specified in seconds. The range is 1 to 20. The value 0 is not permitted. Total TLV Length The total TLV length is the total of all included TLVs. Flags Two flags are defined. The reserved flags in this field MUST be set to zero on transmission and ignored on receipt. +-+-+-+-+-+-+-+-+ | Reserved |L|R| +-+-+-+-+-+-+-+-+ Figure 3: Flags L-flag 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 Swallow, et al. Expires February 16, 2012 [Page 8] Internet-Draft MPLS Fault Management OAM August 2011 setting this bit. R-flag The R-flag is normally set to zero. A setting of one indicates the removal of a previously sent FM condition. 4.1. Fault Management Message TLVs TLVs are used in Fault Management messages to carry information that may not pertain to all messages as well as to allow for extensibility. The TLVs currently defined are the IF_ID, and the Global_ID. TLVs (Type-Length-Value tuples) have the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | . . Value . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Fault TLV Format Type Encodes how the Value field is to be interpreted. Length Specifies the length of the Value field in octets. Value Octet string of Length octets that encodes information to be interpreted as specified by the Type field. 4.1.1. Interface Identifier TLV 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 0x8. Swallow, et al. Expires February 16, 2012 [Page 9] Internet-Draft MPLS Fault Management OAM August 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS-TP Node Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS-TP Interface Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Interface Identifier TLV Format 4.1.2. Global Identifier The Global Identifier (Global_ID) TLV carries the Global_ID as defined in draft-ietf-mpls-tp-identifiers [5]. The Type is 0x2. The length is 0x4. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPLS-TP Global Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Global Identifier TLV Format 5. Sending and Receiving Fault Management Messages 5.1. Sending a Fault Management Message Service disruptive conditions are indicated by sending FM messages. The message type is set to the value corresponding to the condition. The refresh timer is set to the maximum time between successive FM messages. This value MUST NOT be changed on successive FM messages reporting the same incident. If the optional clearing procedures are not used, then the default value is 1 second. Otherwise the default value is 20 seconds. A Global_ID MAY be included. If the R-flag clearing procedures are to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV MAY be included. The message is then sent. Assuming the condition persists, the Swallow, et al. Expires February 16, 2012 [Page 10] Internet-Draft MPLS Fault Management OAM August 2011 message MUST be retransmitted two more times at an interval of one second. Further retransmissions are made according to the value of the refresh timer. Retransmissions continue until the condition is cleared. 5.2. Clearing a FM Indication Ceasing to send FM messages will clear the indication after 3.5 times the refresh timer. To clear an indication more quickly, the 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 message is sent immediately and then retransmitted two more times at an interval of one second. 5.3. Receiving a FM Indication When a FM message is received, a MEP examines it to ensure that it is well formed. If the message type is reserved or unknown, the message is ignored. 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 condition is cleared. Otherwise the message is ignored. If the expiration-time expires, the condition is cleared. 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. 2. Support of setting the L-flag to indicated a defect. 3. Receiving AIS and LKR messages with any allowed Refresh Timer value. The following items are optional to implement. Swallow, et al. Expires February 16, 2012 [Page 11] Internet-Draft MPLS Fault Management OAM August 2011 1. Sending AIS and LKR message with other values of the Refresh Timer other than 1 second. 2. Support of receiving the L-flag. 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 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. Swallow, et al. Expires February 16, 2012 [Page 12] Internet-Draft MPLS Fault Management OAM August 2011 Spurious fault OAM messages form a vector for a denial of service attack. However, since these messages are carried in a control 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 attack. Since transport networks are usually operated as a walled garden, such threats are less likely. If external MPLS traffic is mapped to an LSP via a 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 fault OAM messages with the GAL label at the top of the label stack. 8. IANA Considerations 8.1. Pseudowire Associated Channel Type Fault OAM requires a unique Associated Channel Type which are assigned by IANA from the Pseudowire Associated Channel Types Registry. Registry: Value Description TLV Follows Reference ----------- ----------------------- ----------- --------- 0xHHHH Fault OAM No (This Document) 8.2. MPLS Fault OAM Message Type Registry This sections details the MPLS Fault OAM TLV Registry, a new name spaces to be managed by IANA. The Type space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in RFC 5226 [8]) and "Private Use". MPLS Fault OAM Message Types take values in the range 0-255. 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. Message Types defined in this document are: Msg Type Description -------- ----------------------------- 0x0 Reserved 0x1 Alarm Indication Signal (AIS) 0x2 Lock Report (LKR) Swallow, et al. Expires February 16, 2012 [Page 13] Internet-Draft MPLS Fault Management OAM August 2011 8.3. MPLS Fault OAM TLV Registry This sections details the MPLS Fault OAM TLV Registry, a new name spaces to be managed by IANA. The Type space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values: "Standards Action" (as defined in RFC 5226 [8]), "Specification Required" and "Private Use". MPLS Fault OAM TLVs which take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments 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. TLVs defined in this document are: Value TLV Name ----- ------- 0 Reserved 1 Interface Identifier TLV 2 Global Identifier 9. References 9.1. Normative References [1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [2] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [5] Bocci, M., Swallow, G., and E. Gray, "MPLS-TP Identifiers", draft-ietf-mpls-tp-identifiers-07 (work in progress), July 2011. [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 Swallow, et al. Expires February 16, 2012 [Page 14] Internet-Draft MPLS Fault Management OAM August 2011 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. 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 George Swallow (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States Email: swallow@cisco.com Annamaria Fulignoli (editor) Ericsson Email: annamaria.fulignoli@ericsson.com Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay, 91620 France Email: martin.vigoureux@alcatel-lucent.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA Email: sboutros@cisco.com Swallow, et al. Expires February 16, 2012 [Page 15] Internet-Draft MPLS Fault Management OAM August 2011 David Ward Juniper Networks, Inc. Email: dward@juniper.net Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK Email: stbryant@cisco.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com Swallow, et al. Expires February 16, 2012 [Page 16]