MPLS Working Group M. Vigoureux (Editor)
Internet Draft Alcatel-Lucent
Intended status: Informational
Expires: January 2009 D. Ward (Editor)
Cisco Systems, Inc.
M. Betts (Editor)
Nortel Networks
July 7, 2008
Requirements for OAM in MPLS Transport Networks
draft-vigoureux-mpls-tp-oam-requirements-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 7, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Vigoureux et al. Expires January 7, 2009 [Page 1]
Internet-Draft OAM Requirements for MPLS-TP July 2008
Abstract
This document specifies requirements for OAM (Operations and
Management) functionality in MPLS networks that are used for packet
transport services and network operations. The use of the term MPLS
in this document refers to both MPLS PSNs and pseudowire
technologies.
These requirements are derived from the set of requirements specified
by ITU-T and first published in the ITU-T Supplement Y.Sup4 [6].
Conventions used in this document
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 [1].
Table of Contents
1. Introduction...................................................3
1.1. Terminology...............................................3
1.2. Definitions...............................................4
1.3. Context and Motivations...................................5
1.3.1. Transport Profile of MPLS............................5
1.3.2. Motivations..........................................6
2. OAM Requirements...............................................7
2.1. Architectural Requirements................................8
2.2. Functional Requirements...................................9
2.3. Performance Requirements.................................12
3. Security Considerations.......................................12
4. Congestion Considerations.....................................12
5. IANA Considerations...........................................12
6. Acknowledgments...............................................13
APPENDIX A : OAM Functions Information.........................14
A.1. Continuity Check.........................................14
A.2. Connectivity Verification................................14
A.3. Alarm Suppression........................................14
A.4. Lock Indication..........................................15
A.5. Packet Loss Measurement..................................15
A.6. Diagnostic Test..........................................15
A.7. Trace-route..............................................15
A.8. Delay Measurement........................................16
A.9. Remote Defect Indication.................................16
A.10. Client Signal Fail......................................16
APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document17
7. References....................................................18
7.1. Normative References.....................................18
Vigoureux et al. Expires January 7, 2009 [Page 2]
Internet-Draft OAM Requirements for MPLS-TP July 2008
7.2. Informative References...................................18
Authors' Addresses...............................................18
Contributing Authors' Addresses..................................19
Intellectual Property Statement..................................20
Disclaimer of Validity...........................................21
1. Introduction
This document specifies requirements for OAM (Operations and
Management) functionality in MPLS networks that are used for packet
transport services and network operations. The use of the term MPLS
in this document refers to both MPLS PSNs and pseudowire
technologies.
These requirements may be met by one or more toolsets. The definition
or selection of these toolsets is outside the scope of this document.
1.1. Terminology
AC Attachment Circuit
CSF Client Signal Fail
FCAPS Fault, Configuration, Accounting, Performance, Security
LER Label Edge Router
LSP Label Switch Path
LSR Label Switching Router
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MP Maintenance Point
MS-PW Multi Segment Pseudowire
OAM Operations and Management
PE Provider Edge
PSN Packet Switched Network
Vigoureux et al. Expires January 7, 2009 [Page 3]
Internet-Draft OAM Requirements for MPLS-TP July 2008
PW Pseudowire
SLA Service Level Agreement
SS-PW Single Segment Pseudowire
S-PE Switching Provider Edge
T-PE Terminating Provider Edge
TCME Tandem Connection Maintenance Entity
1.2. Definitions
In this document we refer to a fault as the inability of a function
to perform a required action. This does not include an inability due
to preventive maintenance, lack of external resources, or planned
actions. See also ITU-T G.806 [3].
In this document we refer to a defect to as the situation for which
density of anomalies has reached a level where the ability to perform
a required function has been interrupted. See also ITU-T G.806 [3].
In this document, we refer to MPLS Transport Profile (MPLS-TP) as a
set of MPLS functions used to support packet transport services and
network operations.
In this document we refer to a MPLS Section as a network segment
between two LSRs that are immediately adjacent at the MPLS layer.
OAM packets can be inserted and extracted at various reference
points, referred to as Maintenance Points (MP). These MPs are further
characterized with regard to their position along the entity being
monitored. The MPs can be end-points (Maintenance End Point, MEP) or
intermediate points (Maintenance Intermediate Point, MIP). A MEP is
capable of initiating and terminating OAM packets for fault
management and performance monitoring. A MIP is capable of reacting
to some OAM packets but does not initiate OAM packets. Therefore,
LERs and T-PEs can be MEPs while LSRs and S-PEs can be MIPs. In case
of Tandem Connection Maintenance Entity (defined below), LSRs and S-
PEs can be MEPs.
This document defines the following Maintenance Entities:
o The PW Maintenance Entity, corresponding to end-to-end PW
monitoring (between T-PEs).
Vigoureux et al. Expires January 7, 2009 [Page 4]
Internet-Draft OAM Requirements for MPLS-TP July 2008
o The LSP Maintenance Entity, corresponding to end-to-end LSP
monitoring (between LERs).
o The Tandem Connection Maintenance Entity (TCME), corresponding to
one or more segment(s) of a PW or to a segment (a.k.a. sub-path)
of a LSP.
Note that:
- A TCME could be defined between the two T-PEs of a SS-PW but
there is no specific relevance to define such a TCME as it
corresponds to the PW Maintenance Entity.
- A TCME can be defined between a T-PE and any S-PE (and vice-
versa) or between any two S-PEs on a given MS-PW. A TCME can span
several PW segments, i.e. the PEs (T-PEs or S-PEs) where MEPs are
located need not be adjacent on the MS-PW.
- A TCME can be defined between a LER and any LSR (and vice-versa)
or between any two LSRs, for that LSP. These points (LERs, LSRs)
where MEPS are located do not need to be adjacent on the LSP. A
TCME defined between the two LERs of a LSP corresponds to the LSP
Maintenance Entity.
- The LSP or MS-PW segment(s) that the TCME covers may however be
dependant on administrative boundaries in case the LSP or the MS-
PW spans multiple domains.
- End-points of a TCME are MEPs, not MIPs.
A Maintenance Entity can be viewed as the association of two (or
more) Maintenance End Points that should be provisioned and managed.
Each OAM flow is associated to a unique ME. MEPs of a given ME
generate and/or terminate the OAM messages associated to the ME.
The monitoring of a Maintenance Entity can only be performed at
points where the Label associated with the Maintenance Entity is the
top most label of the stack.
TCMEs MAY be nested but MUST NOT overlap.
1.3. Context and Motivations
1.3.1. Transport Profile of MPLS
This section does not give any requirement on MPLS-TP. Its sole
intent is to describe the context in which the OAM requirements could
fit and is for information only. The authors intend to move it to
another draft at a later stage.
A transport network must provide a means to commit, to the client
signal, the quality of service and availability objectives. These
objectives can be expressed in the form of a Service Level Agreement
Vigoureux et al. Expires January 7, 2009 [Page 5]
Internet-Draft OAM Requirements for MPLS-TP July 2008
(SLA). A transport network must also provide a means to monitor
compliance to an agreed quality of service.
Two important attributes of MPLS-TP (as in any transport network
technology) are that
o it is independent from both client and server networks. That is,
demarcation points exist between MPLS-TP and the customer layer,
and between MPLS-TP and the underlying tunnelling or point-to-
point technology.
o it is consistent with existing transport network operations and
management models [8].
The purpose of a transport network is to transparently carry client
signals (i.e. the stream of client PDUs or client bits), across the
network, between ingress and egress (typically over several nodes). A
key characteristic of transport networks is their ability to monitor
and therefore maintain the integrity of the client signal between
ingress and egress ports of the transport network.
Networks deploying MPLS-TP are configured so as not to use specific
MPLS capabilities such as ECMP, label merging (i.e. for mp2p
purposes) and PHP. In the case of bidirectional connectivity, the
forward and backward directions are congruent (i.e. they follow the
same path and the pairing relationship between the forward and the
backward directions is known in each node traversed by bidirectional
LSPs).
Just as for other transport technologies and associated transport
networks, the presence of a distributed control plane in support of
network operations is optional, and the absence of such control plane
should not affect the ability to operate the network and to use MPLS-
TP forwarding, OAM and protection capabilities.
Finally, some MPLS-TP specific recovery mechanisms are independent of
a control plane. They rely on OAM capabilities such as APS to trigger
protection switching in the absence of a control plane.
1.3.2. Motivations
In the context of MPLS Transport Profile the rationales for OAM
mechanisms are twofold as they can serve as:
Vigoureux et al. Expires January 7, 2009 [Page 6]
Internet-Draft OAM Requirements for MPLS-TP July 2008
o As a network-oriented mechanism (used by a transport network
operator) to monitor his network infrastructure and to implement
internal mechanisms in order to enhance the general behaviour and
the level of performances of his network (e.g. protection
mechanism in case of node or link failure). For example fault
localization is typically associated to this use case.
o As a service-oriented mechanism (used by a transport service
provider) to monitor his offered services to end customers it
order to be able to react rapidly in case of a problem and to be
able to verify some of the SLA parameters (i.e. performance
monitoring) negotiated with the end customer. A transport service
could be provided over several networks or administrative domains
that may not be all owned and managed by the transport service
provider.
More generally, OAM is an important and fundamental functionality in
transport networks as it contributes to
o the reduction of operational complexity and costs, by allowing
efficient and automatic detection, localisation, handling, and
diagnosis of defects, and by minimizing service interruptions,
operational repair times, and operational resources.
o the enhancement of network availability, by ensuring that defects
resulting in misdirected customer traffic are detected/diagnosed
and can lead to appropriate consequent actions minimizing the
number of defects that are not detected automatically before a
customer reports the problem.
o meet service and performance objectives, by running OAM
functionality which allows SLA verification in a multi-maintenance
domain environment and allows the determination of service
degradation due to, for example, packet delay or packet loss.
This is achieved through the support of FCAPS functionality, as
described in ITU-T M.3400 [2], itself relying on OAM related
information.
2. OAM Requirements
This section lists the requirements by which the OAM functionality of
MPLS-TP should abide. Some requirements for this application are
similar to some of those listed in RFC 4377 [7].
The requirements listed below may be met by one or more toolsets, the
definition or selection of these toolsets is outside the scope of
Vigoureux et al. Expires January 7, 2009 [Page 7]
Internet-Draft OAM Requirements for MPLS-TP July 2008
this document. However, it is required that the specified solution
MUST inter-work with the existing MPLS and PW OAM toolset.
2.1. Architectural Requirements
OAM functions SHOULD be independent of the underlying tunnelling or
point-to-point technology.
OAM functions SHOULD be independent of the service a pseudowire may
emulate (e.g. Ethernet).
The set of OAM functions operated on each Maintenance Entity SHOULD
be independent one from another. The set of OAM functions must be a
self-sufficient set that does not require external capabilities to
achieve the OAM objectives.
Note that independence should not be understood here in terms of
isolation but in terms of separate running processes. There should be
one OAM process running per Maintenance Entity but different OAM
running processes could interact (e.g. alarm summarization).
OAM functions MUST operate and be configurable even in the absence of
a control plane. Conversely, OAM functions SHOULD be configurable as
part of connectivity (LSP or PW) management. Note that means for
configuring OAM functions and connectivity management are outside the
scope of this document.
The service emulated by a single segment of multi-segment pseudowire
may span multiple domains. The LSP itself, supporting the pseudo-
wire(s), may span multiple domains. It MUST be possible to perform
OAM functions on a per domain basis and across multiple domains.
Furthermore, in case of a fault or defect on the service, means MUST
be available for the service provider to be informed of the fault
even if the fault is located outside its domain.
OAM functions operate at the data plane. OAM packets MUST run in-
band. That is, OAM packets for a specific destination MUST follow the
same data path as data traffic for this destination. This is known as
fate sharing.
It MUST be possible to discriminate data traffic from OAM packets.
This includes a means to differentiate OAM packets from data traffic
as well as the capability to apply specific treatment to OAM packets.
OAM functionality MUST NOT be dependent on IP routing and forwarding
capabilities as these may not be available in networks where MPLS-TP
is deployed.
Vigoureux et al. Expires January 7, 2009 [Page 8]
Internet-Draft OAM Requirements for MPLS-TP July 2008
OAM functions MUST be able to be used for PWs and LSPs and Section.
Furthermore, since LSPs MAY be stacked, OAM functions MUST be able to
be run at each network layer (i.e. any level of the label stack).
OAM functions MUST be applicable to bidirectional point-to-point
connections, and a subset of these OAM functions MUST be applicable
to unidirectional point-to-point and point-to-multipoint connections.
This subset is based on the nature of both the OAM functions and the
connections to which they can apply. The tables below (Table 1 and
Table 2) summarize the applicability of OAM functions.
OAM functions SHOULD continue to meet their objectives regardless of
congestion conditions. See also ITU-T Y.1541 [4].
2.2. Functional Requirements
In cases where the OAM of the native service of an AC or a PW type
does not provide mechanisms to propagate failure conditions
information, while a downstream indication of such state is needed,
MPLS-TP OAM SHOULD provide mechanisms for propagating AC failures and
their clearance across a MPLS-TP domain.
If a defect or fault occurs, mechanisms MUST be provided to detect
it, diagnose it, localize it, and notify the appropriate entities.
Corrective actions SHOULD be taken according to the type of defect or
fault.
In the case of the PW Maintenance Entity, OAM mechanisms provided
SHOULD ensure that customers do not have to detect faults. The OAM
functions SHOULD allow the service provider to automatically detect
and notify the faults associated with a PW Maintenance Entity.
An alarm suppression and summarization mechanism MUST be provided.
For example, a fault detected at the LSP level MUST NOT trigger
various alarms at the PW level.
The following two tables describe the required OAM functions
constituting the MPLS-TP OAM toolset for Fault Management and
Performance Management applications. In these tables, MEP stands for
monitoring from MEP to MEP, MIP stands for monitoring from MEP to
MIP, U stands for unidirectional, B stands for bidirectional. Crosses
(x) indicate a required function, numbers indicate a required
function while pointing to a footnote providing additional details.
Appendix A provides a short description of the OAM functions
typically supported in ITU-T defined transport networks. It is the
expectation that MPLS-TP will provide an equivalent set.
Vigoureux et al. Expires January 7, 2009 [Page 9]
Internet-Draft OAM Requirements for MPLS-TP July 2008
+-------------------------------------------+
| Fault Management |
|-------------------------------------------|
| on-demand | proactive |
|---------------------+----------+----------|
| MEP | MIP | MEP | MIP |
|----------+----------+----------+----------|
| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
|-----+----+----------+----------+-----+----|
|U |B | U |U |B | U |U |B | U |U |B | U |
+---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|continuity check | |x | | |x | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|connectivity verif. | |x | | |x | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|alarm suppression | | | | | | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|lock indication | | | | | | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|packet loss meas. | | | | | | |x |2 | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|diagnostic test |x |1 | x | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|trace-route | |x | | |x | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|delay measurement | | | | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|remote defect indic. | | | | | | | |x | | | | |
+---------------------+-------------------------------------------+
1: unidirectional and bidirectional test
2: in both directions of the bi-directional connection
Table 1 : OAM Functions for Fault Management
Vigoureux et al. Expires January 7, 2009 [Page 10]
Internet-Draft OAM Requirements for MPLS-TP July 2008
+-------------------------------------------+
| Performance Management |
|-------------------------------------------|
| on-demand | proactive |
|---------------------+----------+----------|
| MEP | MIP | MEP | MIP |
|----------+----------+----------+----------|
| P2P |P2MP| P2P |P2MP| P2P |P2MP| P2P |P2MP|
|-----+----+----------+----------+-----+----|
|U |B | U |U |B | U |U |B | U |U |B | U |
+---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|continuity check | | | | | | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|connectivity verify. | | | | | | |x |x | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|alarm suppression | | | | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|lock indication | | | | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|packet loss meas. | |1 | | | | |x |3 | x | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|diagnostic test | | | | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|trace-route | | | | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|delay measurement |x |2 |x | | | | | | | | | |
|---------------------+--+--+----+--+--+----+--+--+----+--+--+----|
|remote defect indic. | | | | | | | |x | | | | |
+---------------------+-------------------------------------------+
1: single-ended packet loss measurements
2: one-way and two-way packet delay measurements
3: in both directions of the bi-directional connection
Table 2 : OAM Functions for Performance Management
Note: In case a misconnection is detected, proactive Performance
Management MUST be suspended until the misconnection has been
repaired; i.e. all request/response OAM needs to be treated with
caution as it cannot be assumed to function reliably, e.g. if traffic
is leaking in a unidirectional sense with no return path.
The use of OAM functions SHOULD be optional for the operator. A
network operator SHOULD be able to choose which OAM functions to use
Vigoureux et al. Expires January 7, 2009 [Page 11]
Internet-Draft OAM Requirements for MPLS-TP July 2008
and which Maintenance Entity to apply them to. However, it is
recommended that connectivity verification is performed on every
Maintenance Entity in order to reliably detect connectivity defects.
OAM functions such as Continuity Check (CC) and Connectivity
Verification (CV) MUST NOT rely on user traffic. Dedicated OAM CV and
CC flows SHOULD be used to detect continuity and connectivity
defects. See also ITU-T G.806 [3].
As part of the design of OAM mechanisms for MPLS-TP, a mechanism MUST
be provided enabling the realization of a channel for general purpose
signalling, e.g. for control, management and OAM information, that is
associated with the data plane paths.
The design of OAM mechanisms for MPLS-TP MUST allow the ability to
support vendor specific and experimental OAM functions.
Finally, the OAM mechanisms in support of these requirements SHALL be
extensible and thus SHALL NOT preclude additional OAM functions in
the future.
2.3. Performance Requirements
To be incorporated in a future revision of this document
3. Security Considerations
Mechanisms SHOULD be provided to ensure that unauthorized access is
prevented from triggering any OAM function.
OAM messages MAY be authenticated.
An OAM packet for a Maintenance Entity MUST NOT leak out of the ME,
i.e. go beyond the terminating MEP.
Architectural aspects for security concerning MPLS-TP are described
in Clause 13 of ITU-T G.8110.1 [5].
4. Congestion Considerations
A mechanism (e.g. rate limiting) MUST be provided to prevent OAM
messages from causing congestion in the PSN.
5. IANA Considerations
There are no IANA actions required by this draft.
Vigoureux et al. Expires January 7, 2009 [Page 12]
Internet-Draft OAM Requirements for MPLS-TP July 2008
6. Acknowledgments
The authors would like to thank all members of the teams (the Joint
Working Team, the MPLS Interoperability Design Team in IETF and the
T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
specification of MPLS Transport Profile.
Vigoureux et al. Expires January 7, 2009 [Page 13]
Internet-Draft OAM Requirements for MPLS-TP July 2008
APPENDIX A : OAM Functions Information
This Appendix provides a short description of the OAM functions
typically supported in ITU-T defined transport networks.
A.1. Continuity Check
Continuity Check (CC) is a function that is used to detect loss of
continuity between MEPs.
CC is useful for applications like Fault Management, Performance
Monitoring and Protection Switching, etc.
CC should be supported both in pro-active and on-demand modes. In
pro-active mode it may be supported for both bidirectional and
unidirectional connections.
In on-demand mode, CC should be supported for bidirectional
connections both between MEPs and between a MEP and a particular MIP
along the connection.
A.2. Connectivity Verification
Connectivity Verification (CV) is a function that is used to check
connectivity between MEPs in a single maintenance domain.
CV should be supported both in pro-active and on-demand modes. In
pro-active mode it may be supported for both unidirectional and bi-
directional connections.
In on-demand mode, CV should be supported for bidirectional
connections both between MEPs and between a MEP and a particular MIP
along the connection.
A.3. Alarm Suppression
Alarm Suppression is a function that is used by a server layer MEP to
notify a failure condition to its client layer MEP(s) in order to
suppress alarms that may be generated by maintenance domains of the
client layer as a result of the failure condition in the server
layer.
Alarm Suppression should be supported in proactive mode only, for all
both unidirectional and bi-directional connections.
Vigoureux et al. Expires January 7, 2009 [Page 14]
Internet-Draft OAM Requirements for MPLS-TP July 2008
A.4. Lock Indication
Lock Indication is a function that is used to indicate an
administrative locking of a server layer MEP which may result in
consequential interruption of data traffic forwarding towards the
client layer MEP(s) expecting this traffic. The reception of a Lock
Indication allows a MEP to differentiate between a defect condition
and an administrative locking action at the server layer MEP.
Lock indication should be supported in pro-active mode only.
A.5. Packet Loss Measurement
Packet Loss Measurement is a function that is used to measure packet
loss ratio between a pair of MEPs. Packet Loss Ratio is the ratio of
the service packets not delivered to the total number of service
packets transmitted during a set time interval. The number of service
packets not delivered is the difference between the number of service
packets transmitted by the source node and the number of service
packets received at the destination node.
Packet loss Measurements can be performed by a MEP to measure near-
end packet loss on unidirectional connections and near-end and far-
end packet loss on bidirectional connections. Where, near-end packet
loss refers to packet loss associated with ingress data packets while
far-end packet loss refers to packet loss associated with egress data
packets.
The measurement of packet loss ratio should be supported in pro-
active mode for both unidirectional and bi-directional connections.
A.6. Diagnostic Test
A diagnostic test is a function that is used between MEPs to verify
bandwidth throughput, packet loss, bit errors, etc.
This function may be used in on-demand mode for either unidirectional
or bi-directional connections.
A.7. Trace-route
Trace-route is a function that is used to determine the route of a
connection across the MPLS transport network.
Trace-route should be supported in on-demand mode for bi-directional
connections between a pair of MEPs or between a MEP and a MIP.
Vigoureux et al. Expires January 7, 2009 [Page 15]
Internet-Draft OAM Requirements for MPLS-TP July 2008
A.8. Delay Measurement
Delay Measurement is a function that is used to measure one-way or
two-way delay of a packet transmission between a pair of MEPs. Where,
o One-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the first bit of that packet by the destination
node.
o Two-way packet delay is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.
This function may be used in on-demand mode.
A.9. Remote Defect Indication
Remote Defect Indication (RDI) is a function that used by a MEP to
notify its peer MEP of a detection of a defect on a bi-directional
connection between them.
This function should be supported in pro-active mode.
A.10. Client Signal Fail
Client Signal Fail function (CSF) is used to propagate a Client
Failure indication to the far-end sink when alarm suppression in the
client layer is not supported. Upon receiving a packet with CSF
information a MEP detects a client-layer failure condition and
notifies its client-layer.
Upon receiving signal fail indication from its client-layer the MEP
should immediately start transmitting periodic packets with CSF
information. A MEP should continue to transmit periodic packets with
CSF information until the client-layer failure indication is removed.
Transmission of packets with CSF information can be enabled or
disabled on a MEP.
Vigoureux et al. Expires January 7, 2009 [Page 16]
Internet-Draft OAM Requirements for MPLS-TP July 2008
APPENDIX B : Mapping between RFC 4377, Y.Sup4 and this document
To be defined at a later stage.
Vigoureux et al. Expires January 7, 2009 [Page 17]
Internet-Draft OAM Requirements for MPLS-TP July 2008
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] ITU-T Recommendation M.3400 (2000), TMN management functions
[3] ITU-T Recommendation G.806 (2006), Characteristics of transport
equipment - Description methodology and generic functionality
[4] ITU-T Recommendation Y.1541 (2006), Network performance
objectives for IP-based services
[5] ITU-T Recommendation G.8110.1/Y.1370.1 (2007), Architecture of
Transport MPLS (T-MPLS) Layer Network
[6] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-
MPLS OAM and considerations for the application of IETF MPLS
Technology
7.2. Informative References
[7] Nadeau, T., et al., "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS)
Networks", RFC 4377, February 2006
[8] Response to liaisons on G.8110.1 (from ITU-T SG 15 to IETF)
https://datatracker.ietf.org/liaison/265/
Authors' Addresses
Martin Vigoureux
Alcatel-Lucent
Email: martin.vigoureux@alcatel-lucent.com
David Ward
Cisco Systems, Inc.
Email: dward@cisco.com
Vigoureux et al. Expires January 7, 2009 [Page 18]
Internet-Draft OAM Requirements for MPLS-TP July 2008
Malcolm Betts
Nortel Networks
Email: betts01@nortel.com
Contributing Authors' Addresses
Matthew Bocci
Alcatel-Lucent
Email: matthew.bocci@alcatel-lucent.co.uk
Italo Busi
Alcatel-Lucent
Email: italo.busi@alcatel-lucent.it
Huub van Helvoort
Huawei Technologies Co.Ltd.
Email: hhelvoort@huawei.com
Marc Lasserre
Alcatel-Lucent
Email: mlasserre@alcatel-lucent.com
Lieven Levrau
Alcatel-Lucent
Email: llevrau@alcatel-lucent.com
Han Li
China Mobile Communications Corporation (CMCC)
Email: lihan@chinamobile.com
Vigoureux et al. Expires January 7, 2009 [Page 19]
Internet-Draft OAM Requirements for MPLS-TP July 2008
Julien Meuric
Orange
Email: julien.meuric@orange-ftgroup.com
Philippe Niger
Orange
Email: philippe.niger@orange-ftgroup.com
Jing Ruiquan
China Telecom
Email: jingrq@ctbri.com.cn
Nurit Sprecher
Nokia-Siemens Networks
Email: nurit.sprecher@nsn.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Yaacov Weingarten
Nokia-Siemens Networks
Email: yaacov.weingarten@nsn.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Vigoureux et al. Expires January 7, 2009 [Page 20]
Internet-Draft OAM Requirements for MPLS-TP July 2008
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Vigoureux et al. Expires January 7, 2009 [Page 21]