draft-ietf-mpls-tp-oam-requirements-04.txt   draft-ietf-mpls-tp-oam-requirements-05.txt 
MPLS Working Group M. Vigoureux, Ed. MPLS Working Group M. Vigoureux, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Standards Track D. Ward, Ed. Intended status: Standards Track D. Ward, Ed.
Expires: June 19, 2010 Cisco Systems, Inc. Expires: August 21, 2010 Juniper Networks
M. Betts, Ed. M. Betts, Ed.
Huawei ZTE Corporation
December 16, 2009 February 17, 2010
Requirements for OAM in MPLS Transport Networks Requirements for OAM in MPLS Transport Networks
draft-ietf-mpls-tp-oam-requirements-04 draft-ietf-mpls-tp-oam-requirements-05
Abstract Abstract
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
Operations, Administration and Maintenance of MPLS Transport Profile. Operations, Administration and Maintenance of MPLS Transport Profile.
These requirements apply to pseudowires, Label Switched Paths, and These requirements apply to pseudowires, Label Switched Paths, and
Sections. Sections.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 19, 2010. This Internet-Draft will expire on August 21, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language and Terminology . . . . . . . . . . 4 1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6 2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. OAM and IP Capabilities . . . . . . . . . . . . . . . 7 2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Interoperability and Interworking . . . . . . . . . . 7 2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.5. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7 2.1.5. Interoperability and Interworking . . . . . . . . . . 8
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8 2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8 2.2. Functional Requirements . . . . . . . . . . . . . . . . . 8
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9 2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9 2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 9
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10 2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10 2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 10
2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 10 2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11 2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11 2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 11
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12 2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12 2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 12
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13 2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13 2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 13 2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14 3. Congestion Considerations . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), In the context of MPLS Transport Profile (MPLS-TP, see [8] and [1]),
the rationales for Operations, Administration and Maintenance (OAM) the rationales for Operations, Administration and Maintenance (OAM)
are twofold as it can serve: are twofold as it can serve:
o as a network-oriented functionality, used by a transport network o as a network-oriented functionality, used by a transport network
operator to monitor his network infrastructure and to implement operator to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and internal mechanisms in order to enhance the general behaviour and
the level of performance of his network (e.g., protection the level of performance of his network (e.g., protection
mechanism in case of node or link failure). As an example, fault mechanism in case of node or link failure). As an example, fault
localization is typically associated with this use case. localization is typically associated with this use case.
skipping to change at page 3, line 52 skipping to change at page 3, line 52
domain environment and allows for the determination of service domain environment and allows for the determination of service
degradation due, for example, to packet delay or packet loss. degradation due, for example, to packet delay or packet loss.
1.1. Scope of this Document 1.1. Scope of this Document
This document lists architectural and functional requirements for the This document lists architectural and functional requirements for the
OAM functionality of MPLS-TP. These requirements apply to OAM functionality of MPLS-TP. These requirements apply to
pseudowires (PWs), Label Switched Paths (LSPs) and Sections. pseudowires (PWs), Label Switched Paths (LSPs) and Sections.
These requirements are derived from the set of requirements specified These requirements are derived from the set of requirements specified
by ITU-T and published in the ITU-T Supplement Y.Sup4 [10]. by ITU-T and published in the ITU-T Supplement Y.Sup4 [9].
By covering transport specificities, these requirements complement By covering transport specificities, these requirements complement
those identified in RFC 4377 [11], yet some requirements may be those identified in RFC 4377 [10], yet some requirements may be
similar. similar.
This document only lists architectural and functional OAM This document only lists architectural and functional OAM
requirements. It does not detail the implications of their requirements. It does not detail the implications of their
applicability to the various types (e.g., point-to-point, point-to- applicability to the various types (e.g., point-to-point, point-to-
multipoint, unidirectional, bidirectional ...) of PWs, LSPs and multipoint, unidirectional, bidirectional ...) of PWs, LSPs and
Sections. Furthermore, this document does not provide requirements Sections. Furthermore, this document does not provide requirements
on how the protocol solution(s) should behave to achieve the on how the protocol solution(s) should behave to achieve the
functional objectives. Please see [12] for further information. functional objectives. Please see [11] for further information.
Note that the OAM functions identified in this document may be used Note that the OAM functions identified in this document may be used
for fault management, performance monitoring and/or protection for fault management, performance monitoring and/or protection
switching applications. For example, connectivity verification can switching applications. For example, connectivity verification can
be used for fault management by detecting failure conditions, but may be used for fault management by detecting failure conditions, but may
also be used for performance monitoring through its contribution to also be used for performance monitoring through its contribution to
the evaluation of performance metrics (e.g., unavailability time). the evaluation of performance metrics (e.g., unavailability time).
Nevertheless, it is outside the scope of this document to specify Nevertheless, it is outside the scope of this document to specify
which function should be used for which application. which function should be used for which application.
skipping to change at page 7, line 9 skipping to change at page 7, line 9
running on the end-to-end PW or LSP. running on the end-to-end PW or LSP.
Furthermore, any OAM function applied to segment(s) of a PW or LSP Furthermore, any OAM function applied to segment(s) of a PW or LSP
SHOULD be independent of the OAM function(s) applied to other SHOULD be independent of the OAM function(s) applied to other
segment(s) of the same PW or LSP. segment(s) of the same PW or LSP.
Note: Independence should not be understood in terms of isolation as Note: Independence should not be understood in terms of isolation as
there can be interactions between OAM functions operated on e.g., there can be interactions between OAM functions operated on e.g.,
an LSP, and on another LSP or a PW. an LSP, and on another LSP or a PW.
2.1.3. OAM and IP Capabilities 2.1.3. Data Plane
The OAM functionality may be deployed in various environments. OAM functions operate in the data plane. OAM packets MUST run in-
band; that is, OAM packets for a specific PW, LSP or Section MUST
follow the exact same data path as user traffic of that PW, LSP or
Section. This is often referred to as fate sharing.
o In some environments (e.g., IP/MPLS environments), IP routing and It MUST be possible to discriminate user traffic from OAM packets.
forwarding capabilities are inherently present in the data plane. This includes a means to differentiate OAM packets from user traffic
as well as the capability to apply specific treatment to OAM packets,
at the nodes processing these OAM packets.
o In some environments (e.g., MPLS-TP environments), IP routing and As part of the design of OAM protocol solution(s) for MPLS-TP, a
forwarding capabilities may not necessarily be present in the data mechanism, for enabling the encapsulation and differentiation of OAM
plane. messages on a PW, LSP or Section, MUST be provided. Such mechanism
SHOULD also support the encapsulation and differentiation of existing
IP/MPLS and PW OAM messages.
In the former case, it MUST be possible to operate the OAM functions 2.1.4. OAM and IP Capabilities
by relying on IP routing and forwarding capabilities (e.g.,
encapsulation in IP header for (de)multiplexing purposes) while in There are environments where IP capabilities are present in the data
the latter case it MUST be possible to operate the OAM functions plane. IP/MPLS environments are examples of such environments.
without relying on IP routing and forwarding capabilities. There are also environments where IP capabilities may not be present
in the data plane. MPLS-TP environments are examples of environments
where IP capabilities might or might not be present.
Presence or absence of IP capabilities is deployment scenario
dependent.
It MUST be possible to deploy the OAM functionality in any of these
environments. As a result, it MUST be possible to operate OAM
functions with or without relying on IP capabilities and it MUST be
possible to choose to make use of IP capabilities when these are
present.
Furthermore, the mechanism required for enabling the encapsulation
and differentiation of OAM messages (see Section 2.1.3) MUST support
the capability to differentiate OAM messages of an OAM function
operated by relying on IP capabilities (e.g., using encapsulation in
an IP header) from OAM messages of an OAM function operated without
relying on any IP capability.
Note that IP capabilities include the capability to form a standard
IP header, to encapsulate a payload in an IP header, to parse and
analyse the fields of an IP header and to take actions based on the
content of these fields.
For certain functions, OAM messages need to incorporate For certain functions, OAM messages need to incorporate
identification information (e.g., of source and/or destination identification information (e.g., of source and/or destination
nodes). The protocol solution(s) MUST at least support nodes). The protocol solution(s) MUST at least support
identification information in the form of an IP addressing structure identification information in the form of an IP addressing structure
and MUST also be extensible to support additional identification and MUST also be extensible to support additional identification
schemes. schemes.
2.1.4. Interoperability and Interworking 2.1.5. Interoperability and Interworking
It is REQUIRED that OAM interoperability is achieved between distinct It is REQUIRED that OAM interoperability is achieved between distinct
domains materializing the environments described in Section 2.1.3. domains materializing the environments described in Section 2.1.4.
It is also REQUIRED that the first two requirements of Section 2.1.3 It is also REQUIRED that the first two requirements of Section 2.1.4
still hold and MUST still be met when interoperability is achieved. still hold and MUST still be met when interoperability is achieved.
When MPLS-TP is run with IP routing and forwarding capabilities, it When MPLS-TP is run with IP routing and forwarding capabilities, it
MUST be possible to operate any of the existing IP/MPLS and PW OAM MUST be possible to operate any of the existing IP/MPLS and PW OAM
protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5] and VCCV-BFD protocols (e.g., LSP-Ping [4], MPLS-BFD [12], VCCV [5] and VCCV-BFD
[14]). [13]).
2.1.5. Data Plane
OAM functions operate in the data plane. OAM packets MUST run in-
band; that is, OAM packets for a specific PW, LSP or Section MUST
follow the exact same data path as user traffic of that PW, LSP or
Section. This is often referred to as fate sharing.
It MUST be possible to discriminate user traffic from OAM packets.
This includes a means to differentiate OAM packets from user traffic
as well as the capability to apply specific treatment to OAM packets,
at the nodes processing these OAM packets.
As part of the design of OAM protocol solution(s) for MPLS-TP, a
mechanism, for enabling the encapsulation and differentiation of OAM
messages on a PW, LSP or Section, MUST be provided. Such mechanism
SHOULD also support the encapsulation and differentiation of existing
IP/MPLS and PW OAM messages.
2.1.6. Configuration 2.1.6. Configuration
OAM functions MUST operate and be configurable even in the absence of OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, it SHOULD be possible to configure as a control plane. Conversely, it SHOULD be possible to configure as
well as enable/disable the capability to operate OAM functions as well as enable/disable the capability to operate OAM functions as
part of connectivity management and it SHOULD also be possible to part of connectivity management and it SHOULD also be possible to
configure as well as enable/disable the capability to operate OAM configure as well as enable/disable the capability to operate OAM
functions after connectivity has been established. functions after connectivity has been established.
skipping to change at page 9, line 39 skipping to change at page 9, line 50
Protocol solution(s) developed to meet these requirements may rely on Protocol solution(s) developed to meet these requirements may rely on
information exchange. Information exchange between various nodes information exchange. Information exchange between various nodes
involved in the operation of an OAM function SHOULD be reliable such involved in the operation of an OAM function SHOULD be reliable such
that, for example, defects or faults are properly detected or that that, for example, defects or faults are properly detected or that
state changes are effectively known by the appropriate nodes. state changes are effectively known by the appropriate nodes.
2.2.2. Continuity Checks 2.2.2. Continuity Checks
The MPLS-TP OAM toolset MUST provide a function to enable an End The MPLS-TP OAM toolset MUST provide a function to enable an End
Point to monitor the liveness of a PW, LSP or Section. Point to monitor the liveliness of a PW, LSP or Section.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
This function SHOULD be performed pro-actively. This function SHOULD be performed pro-actively.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
skipping to change at page 13, line 27 skipping to change at page 13, line 32
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
2.2.11. Packet Loss Measurement 2.2.11. Packet Loss Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of packet loss ratio over a PW, LSP or Section. quantification of packet loss ratio over a PW, LSP or Section.
Note that packet loss ratio is the ratio of the user packets not Packet loss ratio is defined to be the ratio of the user packets not
delivered to the total number of user packets transmitted during a delivered to the total number of user packets transmitted during a
defined time interval. The number of user packets not delivered is defined time interval. The number of user packets not delivered is
the difference between the number of user packets transmitted by an the difference between the number of user packets transmitted by an
End Point and the number of user packets received at an End Point. End Point and the number of user packets received at an End Point.
See also [6].
Note that RFC2680 [14] defines packet loss as well as provides
definitions for samples and statistics for packet loss.
This function MAY either be performed pro-actively or on-demand. This function MAY either be performed pro-actively or on-demand.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
It SHOULD be possible to rely on user traffic to perform that It SHOULD be possible to rely on user traffic to perform that
functionality. functionality.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs. unidirectional LSPs and point-to-multipoint LSPs.
2.2.12. Packet Delay Measurement 2.2.12. Packet Delay Measurement
The MPLS-TP OAM toolset MUST provide a function to enable the The MPLS-TP OAM toolset MUST provide a function to enable the
quantification of the one-way, and if appropriate, the two-way, delay quantification of the one-way, and if appropriate, the two-way, delay
of a PW, LSP or Section. of a PW, LSP or Section.
Note that o The one-way delay is defined in [6] to be the time elapsed from
o One-way delay is the time elapsed from the start of transmission the start of transmission of the first bit of a packet by an End
of the first bit of a packet by an End Point until the reception Point until the reception of the last bit of that packet by the
of the last bit of that packet by the other End Point. See also other End Point.
[7].
o Two-way delay is the time elapsed from the start of transmission o The two-way delay is defined in [7] to be the time elapsed from
of the first bit of a packet by a End Point until the reception of the start of transmission of the first bit of a packet by an End
the last bit of that packet by the same End Point. See also [8]. Point until the reception of the last bit of that packet by the
Two-way delay may be quantified using data traffic loopback at the same End Point.
remote End Point of the PW, LSP or Section (see Section 2.2.5).
Two-way delay may be quantified using data traffic loopback at the
remote End Point of the PW, LSP or Section (see Section 2.2.5).
Accurate quantification of one-way delay may require clock
synchronization, the means for which are outside the scope of this
document.
This function SHOULD be performed on-demand and MAY be performed pro- This function SHOULD be performed on-demand and MAY be performed pro-
actively. actively.
This function SHOULD be performed between End Points of PWs, LSPs and This function SHOULD be performed between End Points of PWs, LSPs and
Sections. Sections.
The protocol solution(s) developed to perform this function MUST also The protocol solution(s) developed to perform this function MUST also
apply to point-to-point associated bidirectional LSPs, point-to-point apply to point-to-point associated bidirectional LSPs, point-to-point
unidirectional LSPs and point-to-multipoint LSPs but only to enable unidirectional LSPs and point-to-multipoint LSPs but only to enable
skipping to change at page 16, line 5 skipping to change at page 16, line 16
equipment - Description methodology and generic functionality", equipment - Description methodology and generic functionality",
2009. 2009.
[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label [4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit [5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit
Connectivity Verification (VCCV): A Control Channel for Connectivity Verification (VCCV): A Control Channel for
Pseudowires", RFC 5085, December 2007. Pseudowires", RFC 5085, December 2007.
[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet [6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Loss Metric for IPPM", RFC 2680, September 1999.
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999. Metric for IPPM", RFC 2679, September 1999.
[8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay [7] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
Metric for IPPM", RFC 2681, September 1999. Metric for IPPM", RFC 2681, September 1999.
7.2. Informative References 7.2. Informative References
[9] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "A Framework [8] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A
for MPLS in Transport Networks", Framework for MPLS in Transport Networks",
draft-ietf-mpls-tp-framework-06 (work in progress), draft-ietf-mpls-tp-framework-10 (work in progress),
October 2009. February 2010.
[10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on [9] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on
transport requirements for T-MPLS OAM and considerations for transport requirements for T-MPLS OAM and considerations for
the application of IETF MPLS technology", 2008. the application of IETF MPLS technology", 2008.
[11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. [10] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements for Matsushima, "Operations and Management (OAM) Requirements for
Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, Multi-Protocol Label Switched (MPLS) Networks", RFC 4377,
February 2006. February 2006.
[12] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM [11] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM
Framework", draft-ietf-mpls-tp-oam-framework-04 (work in Framework", draft-ietf-mpls-tp-oam-framework-04 (work in
progress), December 2009. progress), December 2009.
[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD [12] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD
For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress), For MPLS LSPs", draft-ietf-bfd-mpls-07 (work in progress),
June 2008. June 2008.
[14] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding [13] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding
Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Detection (BFD) for the Pseudowire Virtual Circuit Connectivity
Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in Verification (VCCV)", draft-ietf-pwe3-vccv-bfd-07 (work in
progress), July 2009. progress), July 2009.
[14] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
Authors' Addresses Authors' Addresses
Martin Vigoureux (editor) Martin Vigoureux (editor)
Alcatel-Lucent Alcatel-Lucent
Route de Villejust Route de Villejust
Nozay, 91620 Nozay, 91620
France France
Email: martin.vigoureux@alcatel-lucent.com Email: martin.vigoureux@alcatel-lucent.com
David Ward (editor) David Ward (editor)
Cisco Systems, Inc. Juniper Networks
170 W. Tasman Dr.
San Jose, CA 95134
USA
Email: dward@cisco.com Email: dward@juniper.net
Malcolm Betts (editor) Malcolm Betts (editor)
Huawei ZTE Corporation
Email: malcolm.betts@huawei.com Email: malcolm.betts@zte.com.cn
 End of changes. 40 change blocks. 
86 lines changed or deleted 100 lines changed or added

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