draft-ietf-mpls-oam-requirements-07.txt   rfc4377.txt 
Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow
Expires: June 2006 George Swallow
Cisco Systems, Inc.
David Allan Network Working Group T. Nadeau
Request for Comments: 4377 M. Morrow
Category: Informational G. Swallow
Cisco Systems, Inc.
D. Allan
Nortel Networks Nortel Networks
S. Matsushima
Satoru Matsushima
Japan Telecom Japan Telecom
February 2006
December 2005 Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks
Operations and Management Requirements
for Multi-Protocol Label Switched Networks
draft-ietf-mpls-oam-requirements-07.txt
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 Status of This Memo
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 This memo provides information for the Internet community. It does
months and may be updated, replaced, or obsoleted by other not specify an Internet standard of any kind. Distribution of this
documents at any time. It is inappropriate to use memo is unlimited.
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 Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document specifies Operations and Management requirements This document specifies Operations and Management (OAM) requirements
for Multi-Protocol Label Switching, as well as for applications for Multi-Protocol Label Switching (MPLS), as well as for
draft-ietf-mpls-oam-requirements-07 December 7, 2005 applications of MPLS, such as pseudo-wire voice and virtual private
network services. These requirements have been gathered from network
of Multi-Protocol Label Switching such as pseudo-wire voice and operators who have extensive experience deploying MPLS networks.
virtual private network services. These requirements
have been gathered from network operators who have extensive
experience deploying Multi-Protocol Label Switching networks.
Table of Contents Table of Contents
Abstract ....................................................1 1. Introduction ....................................................2
1. Introduction ................................................2 2. Document Conventions ............................................2
2. Document Conventions ........................................2 3. Motivations .....................................................4
2.1 Terminology .................................................2 4. Requirements ....................................................4
2.2 Acronyms ....................................................2 5. Security Considerations ........................................11
3. Motivations .................................................2 6. References .....................................................12
4. Requirements ................................................2 7. Acknowledgements ...............................................13
5. Security Considerations ....................................26
6. IANA considerations ........................................27
7. References .................................................27
7.1 Normative references .......................................27
7.2 Informative references .....................................29
8. Author's Addresses .........................................29
9. Intellectual Property Notice ...............................30
10. Full Copyright Statement ...................................29
1. Introduction 1. Introduction
This document describes requirements for user and data This document describes requirements for user and data plane
plane operations and management (OAM) for Multi-Protocol Operations and Management (OAM) for Multi-Protocol Label Switching
Label Switching (MPLS). These requirements have been gathered (MPLS). These requirements have been gathered from network operators
from network operators who have extensive experience deploying who have extensive experience deploying MPLS networks. This document
MPLS networks. This draft specifies OAM requirements specifies OAM requirements for MPLS, as well as for applications of
for MPLS, as well as for applications of MPLS. MPLS.
No specific mechanisms are proposed to address these
requirements at this time. The goal of this draft is to
identify a commonly applicable set of requirements for MPLS
OAM at this time. Specifically, a set of requirements that apply
to the most common set of MPLS networks deployed by service
provider organizations today at the time this document was
written. These requirements can then be used
as a base for network management tool development and to guide
the evolution of currently specified tools, as well as the
specification of OAM functions that are intrinsic to protocols
used in MPLS networks.
Comments should be made directly to the MPLS mailing list
at mpls@lists.ietf.org.
draft-ietf-mpls-oam-requirements-07 December 7, 2005 Currently, there are no specific mechanisms proposed to address these
requirements. The goal of this document is to identify a commonly
applicable set of requirements for MPLS OAM at this time.
Specifically, a set of requirements that apply to the most common set
of MPLS networks deployed by service provider organizations at the
time this document was written. These requirements can then be used
as a base for network management tool development and to guide the
evolution of currently specified tools, as well as the specification
of OAM functions that are intrinsic to protocols used in MPLS
networks.
2. Document Conventions 2. Document Conventions
2.1 Terminology 2.1. Terminology
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Queuing/buffering Latency: delay caused by packet queuing (value is Queuing/buffering Latency: The delay caused by packet queuing (value
variable since depending on the packet is variable since it is dependent on the
arrival rate in addition to the packet arrival rate, the packet length,
dependence on the packet length and the and the link throughput).
link throughput).
Probe-based-detection: Active measurement tool which can measure Probe-based-detection: Active measurement tool that can measure
the consistency of an LSP [LSPPING]. the consistency of an LSP [RFC4379].
Defect: Any error condition that prevents an Label Defect: Any error condition that prevents a Label
Switched Path functioning correctly. For Switched Path (LSP) from functioning
example, loss of an IGP path will most correctly. For example, loss of an
likely also result in a Label Switched Interior Gateway Protocol (IGP) path will
Path not being able to deliver traffic to most likely result in an LSP not being
its destination. Another example is the able to deliver traffic to its
breakage of a TE tunnel. These may be due destination. Another example is the
to physical circuit failures or failure interruption of the path for a TE tunnel.
of switching nodes to operate as expected. These may be due to physical circuit
failures or failure of switching nodes to
operate as expected.
Multi-vendor/multi-provider network Multi-vendor/multi-provider network
operation typically requires agreed upon operation typically requires agreed upon
definitions of defects (when it is broken definitions of defects (when it is broken
and when it is not) such that both and when it is not) such that both
recovery procedures and service level recovery procedures and service level
specification impacts can be specified. specification impact can be specified.
Head-end Label Switching Head-end Label Switching
Router (LSR): The beginning of a label switched path. A Router (LSR): The beginning of an LSP. A head-end LSR
head-end LSR is also referred to as an is also referred to as an ingress LSR.
ingress LSR.
Tail-end Label Switching Tail-end Label Switching
Router (LSR): The end of a label switched path. A Router (LSR): The end of an LSP. A tail-end LSR is also
tail-end LSR is also referred to as an referred to as an egress LSR.
egress LSR.
Propagation Latency: The delay added by the propagation of the Propagation Latency: The delay added by the propagation of the
draft-ietf-mpls-oam-requirements-07 December 7, 2005
packet through the link (fixed value that packet through the link (fixed value that
depends on the distance of the link and depends on the distance of the link and
the propagation speed). the propagation speed).
Transmission Latency: The delay added by the transmission of Transmission Latency: The delay added by the transmission of the
the packet over the link i.e. the time packet over the link, i.e., the time it
it takes put the packet over the media takes to put the packet over the media
(value that depends on the link (value that depends on the link throughput
throughput and packet length). and packet length).
Processing Latency: The delay added by all the operations Processing Latency: The delay added by all the operations
related to the switching of labeled related to the switching of labeled
packet (value is node implementation packets (value is node implementation
specific and may be considered as fixed specific and may be considered fixed and
and constant for a given type of constant for a given type of equipment).
equipment).
Node Latency: The delay added by the network element Node Latency: The delay added by the network element
resulting from of the sum of the resulting from of the sum of the
transmission, processing and queuing/ transmission, processing, and
buffering latency queuing/buffering latency.
One-hop Delay: The fixed delay experienced by a packet One-hop Delay: The fixed delay experienced by a packet to
to reach the next hop resulting from the reach the next hop resulting from the of
of the propagation latency, the the propagation latency, the transmission
transmission latency and the processing latency, and the processing latency.
latency.
Minimum Path Latency: The sum of the one-hop delays experienced Minimum Path Latency: The sum of the one-hop delays experienced
by the packet when traveling from the by the packet when traveling from the
ingress to the egress LSR. ingress to the egress LSR.
Variable Path Latency: The sum of the delays caused by the Variable Path Latency: The variation in the sum of the delays
queuing latency experienced by the experienced by packets transiting the
packet at each node over the path. path, otherwise know as jitter.
Otherwise known as jitter.
2.2 Acronyms 2.2. Acronyms
ASBR: Autonomous System Border Router ASBR: Autonomous System Border Router
CE: Customer Edge CE: Customer Edge
PE: Provider Edge PE: Provider Edge
SP: Service Provider SP: Service Provider
draft-ietf-mpls-oam-requirements-07 December 7, 2005
ECMP: Equal Cost Multi-path ECMP: Equal-Cost Multi-path
LSP: Label Switched Path LSP: Label Switched Path
LSP Ping: Label Switched Path Ping LSP Ping: Label Switched Path Ping
LSR: Label Switching Router LSR: Label Switching Router
OAM: Operations and Management OAM: Operations and Management
RSVP: Resource reSerVation Protocol RSVP: Resource reSerVation Protocol
LDP: Label Distribution Protocol LDP: Label Distribution Protocol
DoS: Denial of service DoS: Denial of Service
3. Motivations 3. Motivations
This document was created in order to provide requirements This document was created to provide requirements that could be used
which could be used to create consistent and useful OAM to create consistent and useful OAM functionality that meets
functionality that meets operational requirements of those operational requirements of those service providers (SPs) who have
service providers who have or are deploying MPLS. deployed or are deploying MPLS.
4. Requirements 4. Requirements
The following sections enumerate the OAM requirements The following sections enumerate the OAM requirements gathered from
gathered from service providers who have deployed MPLS service providers who have deployed MPLS and services based on MPLS
and services based on MPLS networks. Each requirement is networks. Each requirement is specified in detail to clarify its
specified in detail to clarify its applicability. applicability. Although the requirements specified herein are
Although the requirements specified herein are defined by defined by the IETF, they have been made consistent with requirements
the IETF, they have been made consistent with requirements
gathered by other standards bodies such as the ITU [Y1710]. gathered by other standards bodies such as the ITU [Y1710].
4.1 Detection of Label Switched Path Defects 4.1. Detection of Label Switched Path Defects
The ability to detect defects in a broken Label Switched Path
(LSP) MUST not require manual hop-by-hop troubleshooting of
each LSR used to switch traffic for that LSP. For example,
it is not desirable to manually visit each LSR along the data
plane path used to transport an LSP; instead, this function
MUST be automated and able to be performed at some operator
specified frequency from the origination point of that LSP.
This implies solutions that are interoperable as to allow for
such automatic operation.
Furthermore, the automation of path liveliness is desired in The ability to detect defects in a broken LSP MUST not require manual
draft-ietf-mpls-oam-requirements-07 December 7, 2005 hop-by-hop troubleshooting of each LSR used to switch traffic for
that LSP. For example, it is not desirable to manually visit each
LSR along the data plane path transited by an LSP; instead, this
function MUST be automated and able to be performed at some operator
specified frequency from the origination point of that LSP. This
implies solutions that are interoperable to allow for such automatic
operation.
cases where large numbers of LSPs might be tested. For example, Furthermore, the automation of path liveliness is desired in cases
automated ingress LSR to egress LSR testing functionality is where large numbers of LSPs might be tested. For example, automated
desired for some LSPs. The goal is to detect LSP path defects ingress LSR to egress LSR testing functionality is desired for some
before customers do, and this requires detection and correction LSPs. The goal is to detect LSP path defects before customers do,
of LSP defects in a manner that is both predictable and which requires detection and correction of LSP defects in a manner
sufficiently within the constraints of the service level agreement that is both predictable and within the constraints of the service
under which the service is being offered. Simply put, the sum of level agreement under which the service is being offered. Simply
the time it takes an OAM tool to detect a defect and put, the sum of the time it takes an OAM tool to detect a defect and
the time needed for an operational support system to react to the time needed for an operational support system to react to this
this defect by possibly correcting it or notifying the customer, defect, by possibly correcting it or notifying the customer, must
must fall within the bounds of the service level agreement in fall within the bounds of the service level agreement in question.
question.
Synchronization of detection time bounds by tools used to detect Synchronization of detection time bounds by tools used to detect
broken LSPs is required. Failure to specify defect detection broken LSPs is required. Failure to specify defect detection time
time bounds may result in an ambiguity in test results. If the bounds may result in an ambiguity in test results. If the time to
time to detect is known, then automated responses can be specified detect broken LSPs is known, then automated responses can be
both with respect to and with regard to resiliency and service specified with respect and regard to resiliency and service level
level specification reporting. Further, if synchronization of specification reporting. Further, if synchronization of detection
detection time bounds is possible, an operational framework can be time bounds is possible, an operational framework can be established
established that can guide the design and specification of MPLS to guide the design and specification of MPLS applications.
applications.
Although ICMP-based ping [RFC792] can be sent through an LSP as Although an ICMP-based ping [RFC792] can be sent through an LSP as an
an IP payload, the use of this tool to verify the defect free IP payload, the use of this tool to verify the defect-free operation
operation of an LSP has the potential for returning erroneous of an LSP has the potential of returning erroneous results (both
results (both positive and negative) for a number of reasons. First, positive and negative) for a number of reasons. For example, in some
since the ICMP traffic is based on legally addressable IP addressing, cases, because the ICMP traffic is based on legally addressable IP
it is possible for ICMP messages that are originally transmitted addressing, it is possible for ICMP messages that are originally
inside of an LSP to "fall out of the LSP" at some point along transmitted inside of an LSP to "fall out of the LSP" at some point
the path. In these cases, since ICMP packets are routable along the path. In these cases, since ICMP packets are routable, a
a falsely positive response may be returned. In other cases falsely positive response may be returned. In other cases, where the
where the data plane of a specific LSP needs to be tested, it data plane of a specific LSP needs to be tested, it is difficult to
is difficult to guarantee that traffic based on an ICMP ping guarantee that traffic based on an ICMP ping header is parsed and
header is parsed and hashed to the same equal-cost multi-paths hashed to the same equal-cost multi-paths (ECMP) as the data traffic.
as the data traffic.
Any detection mechanisms that depend on receiving status via a Any detection mechanisms that depend on receiving the status via a
return path SHOULD provide multiple return options with the return path SHOULD provide multiple return options with the
expectation that one of them will not be impacted by the original expectation that one of them will not be impacted by the original
defect. An example of a case where a false negative might occur defect. An example of a case where a false negative might occur
would be a mechanism that requires a functional MPLS return path. would be a mechanism that requires a functional MPLS return path.
Since MPLS LSPs are unidirectional, it is possible that although Since MPLS LSPs are unidirectional, it is possible that although the
the forward LSP which is the LSP under test, might be functioning, forward LSP, which is the LSP under test, might be functioning, the
the response from the destination LSR might be lost, thus giving response from the destination LSR might be lost, thus giving the
the source LSR the false impression that the forward LSP is source LSR the false impression that the forward LSP is defective.
defective. However, if an alternate return path could be However, if an alternate return path could be specified -- say IP for
draft-ietf-mpls-oam-requirements-07 December 7, 2005 example -- then the source could specify this as the return path to
the destination, and in this case, would receive a response
specified -- say IP for example -- then the source could indicating that the return LSP is defective.
specify this as the return path to the destination, and in
this case, would receive a response indicating to it that
the return LSP is defective.
The OAM packet MUST follow exactly the customer data path in order The OAM packet MUST follow the customer data path exactly in order to
to reflect path liveliness used by customer data. Particular cases reflect path liveliness used by customer data. Particular cases of
of interest are forwarding mechanisms such as equal cost multi-path interest are forwarding mechanisms, such as ECMP scenarios within the
(ECMP) scenarios within the operator's network whereby flows are operator's network, whereby flows are load-shared across parallel
load-shared across parallel (i.e., equal IGP cost) paths. Where paths (i.e., equal IGP cost). Where the customer traffic may be
the customer traffic may be spread over multiple paths, what is spread over multiple paths, the ability to detect failures on any of
required is to be able to detect failures on any of the path the path permutations is required. Where the spreading mechanism is
permutations. Where the spreading mechanism is payload specific, payload specific, payloads need to have forwarding that is common
payloads need to have forwarding that is common with the traffic with the traffic under test. Satisfying these requirements
under test. Satisfying these requirements introduces complexity introduces complexity into ensuring that ECMP connectivity
into ensuring that ECMP connectivity permutations are exercised, permutations are exercised and that defect detection occurs in a
and that defect detection occurs in a reasonable amount of time. reasonable amount of time.
4.2 Diagnosis of a Broken Label Switched Path 4.2. Diagnosis of a Broken Label Switched Path
The ability to diagnose a broken LSP and to isolate the failed The ability to diagnose a broken LSP and to isolate the failed
component (i.e., link or node) in the path is required. For component (i.e., link or node) in the path is required. For example,
example, note that specifying recovery actions for mis-branching note that specifying recovery actions for mis-branching defects in an
defects in an LDP network is a particularly difficult case. LDP network is a particularly difficult case. Diagnosis of defects
Diagnosis of defects and isolation of the failed component is and isolation of the failed component is best accomplished via a path
best accomplished via a path trace function which can return the trace function that can return the entire list of LSRs and links used
the entire list of LSRs and links used by a certain LSP (or at by a certain LSP (or at least the set of LSRs/links up to the
least the set of LSRs/links up to the location of the defect) is location of the defect). The tracing capability SHOULD include the
required. The tracing capability SHOULD include the ability to ability to trace recursive paths, such as when nested LSPs are used.
trace recursive paths, such as when nested LSPs are used. This This path trace function MUST also be capable of diagnosing LSP mis-
path trace function MUST also be capable of diagnosing LSP merging by permitting comparison of expected vs. actual forwarding
mis-merging by permitting comparison of expected vs. actual behavior at any LSR in the path. The path trace capability SHOULD be
forwarding behavior at any LSR in the path. The path trace capable of being executed from the head-end Label Switching Router
capability SHOULD be capable of being executed from both the (LSR) and may permit downstream path components to be traced from an
head-end Label Switching Router (LSR) and may permit downstream intermediate mid-point LSR. Additionally, the path trace function
path components to be traced from an intermediate mid-point LSR. MUST have the ability to support ECMP scenarios described in Section
Additionally, the path trace function MUST have the ability to 4.1.
support equal cost multi-path scenarios described above in
section 4.1.
4.3 Path characterization 4.3. Path Characterization
The path characterization function is the ability to reveal details The path characterization function is the ability to reveal details
of LSR forwarding operations. These details can then be compared of LSR forwarding operations. These details can then be compared
later during subsequent testing relevant to OAM functionality. during subsequent testing relevant to OAM functionality. This
This would include but is not limited to: includes but is not limited to:
draft-ietf-mpls-oam-requirements-07 December 7, 2005
- consistent use of pipe or uniform time to live (TTL) models by - consistent use of pipe or uniform time to live (TTL) models by
an LSR [RFC3443]. an LSR [RFC3443].
- sufficient details that allow the test origin to
excursive all path permutations related to load spreading - sufficient details that allow the test origin to exercise all
(e.g. ECMP). path permutations related to load spreading (e.g., ECMP).
- stack operations performed by the LSR, such as pushes, pops, - stack operations performed by the LSR, such as pushes, pops,
and TTL propagation at penultimate hop LSRs. and TTL propagation at penultimate hop LSRs.
4.4 Service Level Agreement Measurement 4.4. Service Level Agreement Measurement
Mechanisms are required to measure the diverse aspects of Service Mechanisms are required to measure the diverse aspects of Service
Level Agreements which include: Level Agreements, which include:
- defect free forwarding. The service is considered to be
available and the other aspects of performance measurement - latency - amount of time required for traffic to transit the
listed below have meaning, or the service is unavailable and network
other aspects of performance measurement do not.
- latency - amount of time required for traffic to transit
the network
- packet loss - packet loss
- jitter - measurement of latency variation - jitter - measurement of latency variation
Such measurements can be made independently of the user traffic - defect free forwarding - the service is considered to be
or via a hybrid of user traffic measurement and OAM probing. available, or the service is unavailable and other aspects of
performance measurement do not have meaning.
At least one mechanism is required to measure the number Such measurements can be made independently of the user traffic or
of OAM packets. In addition, the ability to measure the via a hybrid of user traffic measurement and OAM probing.
quantitative aspects of LSPs such as jitter, delay, latency and
loss MUST be available in order to determine whether or not the
traffic for a specific LSP are traveling within the
operator-specified tolerances.
Any method considered SHOULD be capable of measuring the latency At least one mechanism is required to measure the number of OAM
of an LSP with minimal impact on network resources. See section packets. In addition, the ability to measure the quantitative
2.1 for definitions of the various quantitative aspects of LSPs. aspects of LSPs, such as jitter, delay, latency, and loss, MUST be
available in order to determine whether the traffic for a specific
LSP is traveling within the operator-specified tolerances.
4.5 Frequency of OAM Execution Any method considered SHOULD be capable of measuring the latency of
an LSP with minimal impact on network resources. See Section 2.1 for
definitions of the various quantitative aspects of LSPs.
The operator MUST have the flexibility to configure OAM 4.5. Frequency of OAM Execution
parameters insofar-as to meet their specific operational
requirements.
This includes the frequency of the execution of any OAM The operator MUST have the flexibility to configure OAM parameters to
functions. The capability to synchronize OAM operations is required meet their specific operational requirements.
as to to permit consistent measurement of service level agreements.
To elaborate, there are defect conditions such as mis-branching or
draft-ietf-mpls-oam-requirements-07 December 7, 2005
misdirection of traffic for which probe-based detection mechanisms This includes the frequency of the execution of any OAM functions.
that incur significant mismatches in their detection frequency may The ability to synchronize OAM operations is required to permit a
result in flapping. This can be addressed either by synchronizing consistent measurement of service level agreements. To elaborate,
the rate or having the probes self-identify their probe rate. there are defect conditions, such as mis-branching or misdirection of
For example, when the probing mechanisms are bootstrapping, traffic, for which probe-based detection mechanisms that incur
they might negotiate and ultimately agree on a probing rate, significant mismatches in their detection frequency may result in
therefore providing a consistent probing frequency and avoiding flapping. This can be addressed either by synchronizing the rate or
the aforementioned problems. having the probes self-identify their probe rate. For example, when
the probing mechanisms are bootstrapping, they might negotiate and
ultimately agree on a probing rate, therefore providing a consistent
probing frequency and avoiding the aforementioned problems.
One observation would be that wide-spread deployment of MPLS, common One observation would be that wide-spread deployment of MPLS, common
implementation of monitoring tools and the need for implementation of monitoring tools, and the need for inter-carrier
inter-carrier synchronization of defect and service level synchronization of defect and service level specification handling
specification handling will drive specification of OAM parameters will drive specification of OAM parameters to commonly agreed on
to commonly agreed on values and such values will have to be values. Such values will have to be harmonized with the surrounding
harmonized with the surrounding technologies (e.g. SONET/SDH, technologies (e.g., SONET/SDH, ATM) to be useful. This will become
ATM etc.) in order to be useful. This will become particularly particularly important as networks scale and mis-configuration can
important as networks scale and mis-configuration can result in result in churn, alarm flapping, etc.
churn, alarm flapping etc.
4.6 Alarm Suppression, Aggregation and Layer Coordination 4.6. Alarm Suppression, Aggregation, and Layer Coordination
Network elements MUST provide alarm suppression functionality that Network elements MUST provide alarm suppression functionality that
prevents the generation of superfluous generation of alarms by prevents the generation of a superfluous generation of alarms by
simply discarding them (or not generating them in the first place), simply discarding them (or not generating them in the first place),
or by aggregating them together, and thereby greatly reducing the or by aggregating them together, thereby greatly reducing the number
number of notifications emitted. When viewed in conjunction with of notifications emitted. When viewed in conjunction with the
requirement 4.7 below, this typically requires fault notification requirement in Section 4.7 below, this typically requires fault
to the LSP egress that may have specific time constraints if the notification to the LSP egress that may have specific time
application using the LSP independently implements path continuity constraints if the application using the LSP independently implements
testing (for example ATM I.610 Continuity check (CC)[I610]). path continuity testing (for example, ATM I.610 Continuity check
These constraints apply to LSPs that are monitored. The nature of (CC)[I610]). These constraints apply to LSPs that are monitored.
MPLS applications allows for the possibility to have multiple MPLS The nature of MPLS applications allows for the possibility of having
applications attempt to respond to defects simultaneously. For multiple MPLS applications attempt to respond to defects
example, layer-3 MPLS VPNs that utilize Traffic Engineered tunnels, simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic
where a failure occurs on the LSP carrying the Traffic Engineered Engineered tunnels where a failure occurs on the LSP carrying the
tunnel. This failure would affect he VPN traffic that uses the Traffic Engineered tunnel. This failure would affect the VPN traffic
tunnel's LSP. Mechanisms are required to coordinate network response that uses the tunnel's LSP. Mechanisms are required to coordinate
to defects. network responses to defects.
4.7 Support for OAM Inter-working for Fault Notification 4.7. Support for OAM Inter-working for Fault Notification
An LSR supporting the inter-working of one or more networking An LSR supporting the inter-working of one or more networking
technologies over MPLS MUST be able to translate an MPLS defect technologies over MPLS MUST be able to translate an MPLS defect into
into the native technology's error condition. For example, errors the native technology's error condition. For example, errors
occurring over a MPLS transport LSP that supports an emulated occurring over an MPLS transport LSP that supports an emulated ATM VC
draft-ietf-mpls-oam-requirements-07 December 7, 2005 MUST translate errors into native ATM OAM Alarm Indication Signal
(AIS) cells at the termination points of the LSP. The mechanism
SHOULD consider possible bounded detection time parameters, e.g., a
"hold off" function before reacting to synchronize with the OAM
functions.
ATM VC MUST translate errors into native ATM OAM Alarm Indication One goal would be alarm suppression by the upper layer using the LSP.
Signal (AIS) cells at the termination points of the LSP. The As observed in Section 4.5, this requires that MPLS perform detection
mechanism SHOULD consider possible bounded detection time in a bounded timeframe in order to initiate alarm suppression prior
parameters, e.g., a "hold off" function before reacting as to to the upper layer independently detecting the defect.
synchronize with the OAM functions.
One goal would be alarm suppression by the upper layer using
the LSP. As observed in section 4.5, this requires that MPLS
perform detection in a bounded timeframe in order to initiate
alarm suppression prior to the upper layer independently
detecting the defect.
4.8 Error Detection and Recovery. 4.8. Error Detection and Recovery
Recovery from a fault by a network element can be facilitated by Recovery from a fault by a network element can be facilitated by MPLS
MPLS OAM procedures. These procedures will detect a broader range OAM procedures. These procedures will detect a broader range of
of defects than that of simple link and node failures. defects than that of simple link and node failures. Since MPLS LSPs
Since MPLS LSPs may span multiple routing areas and service provider may span multiple routing areas and service provider domains, fault
domains, fault recovery and error detection should be possible recovery and error detection should be possible in these
in these configuration as well as in the more simplified configurations as well as in the more simplified single-area/domain
single-area/domain configurations. configurations.
Recovery from faults SHOULD be automatic. It is a requirement that Recovery from faults SHOULD be automatic. It is a requirement that
faults SHOULD be detected (and possibly corrected) by the network faults SHOULD be detected (and possibly corrected) by the network
operator prior to customers of the service in question detecting operator prior to customers of the service in question detecting
them. them.
4.9 Standard Management Interfaces 4.9. Standard Management Interfaces
The wide-spread deployment of MPLS requires common information The wide-spread deployment of MPLS requires common information
modeling of management and control of OAM functionality. modeling of management and control of OAM functionality. Evidence of
Evidence of this is reflected in the standard IETF MPLS-related this is reflected in the standard IETF MPLS-related MIB modules
MIB modules (e.g. [RFC3813][RFC3812][RFC3814]) for fault, (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and
statistics and configuration management. These standard interfaces configuration management. These standard interfaces provide
provide operators with common programmatic interface access to operators with common programmatic interface access to Operations and
operations and management functions and their status. However, Management functions and their statuses. However, gaps in coverage
gaps in coverage of MIB modules to OAM and other features of MIB modules to OAM and other features exist; therefore, MIB
exists; therefore, MIB modules corresponding to new protocol modules corresponding to new protocol functions or network tools are
functions or network tools are required. required.
4.10 Detection of Denial of Service Attacks 4.10. Detection of Denial of Service Attacks
The ability to detect denial of service (DoS) attacks against the The ability to detect denial of service (DoS) attacks against the
data or control planes MUST be part of any security management data or control planes MUST be part of any security management
related to MPLS OAM tools or techniques. related to MPLS OAM tools or techniques.
4.11 Per-LSP Accounting Requirements 4.11. Per-LSP Accounting Requirements
draft-ietf-mpls-oam-requirements-07 December 7, 2005
In an MPLS network, service providers (SPs) can measure traffic In an MPLS network, service providers can measure traffic from an LSR
from an LSR to the egress of the network using some MPLS related to the egress of the network using some MPLS related MIBs, for
MIBs, for example. This means that it is a reasonable to know how example. This means that it is reasonable to know how much traffic
much traffic is traveling from where to where (i.e., a traffic is traveling from location to location (i.e., a traffic matrix) by
matrix) by analyzing the flow of traffic. Therefore, traffic analyzing the flow of traffic. Therefore, traffic accounting in an
accounting in an MPLS network can be summarized as the following MPLS network can be summarized as the following three items:
three items.
(1) Collecting information to design network (1) Collecting information to design network
Providers and their customers MAY need to verify high-level
service level specifications, either to continuously
optimize their networks, or to offer guaranteed bandwidth
services. Therefore, traffic accounting to monitor MPLS
applications is required.
(2) Providing a Service Level Specification
For the purpose of optimized network design, a service For the purpose of optimized network design, a service
provider may offer the traffic information. Optimizing provider may offer the traffic information. Optimizing
network design needs this information. network design needs this information.
(2) Providing a Service Level Specification
Providers and their customers MAY need to verify high-level
service level specifications, either to continuously optimize
their networks, or to offer guaranteed bandwidth services.
Therefore, traffic accounting to monitor MPLS applications is
required.
(3) Inter-AS environment (3) Inter-AS environment
Service providers that offer inter-AS services require Service providers that offer inter-AS services require
accounting of those services. accounting of those services.
These three motivations need to satisfy the following. These three motivations need to satisfy the following:
- In (1) and (2), collection of information on a per-LSP - In (1) and (2), collection of information on a per-LSP
basis is a minimum level of granularity of collecting basis is a minimum level of granularity for collecting
accounting information at both of ingress and egress accounting information at both of ingress and egress of an
of an LSP. LSP.
- In (3), SP's ASBR carry out interconnection functions as an - In (3), SP's ASBR carry out interconnection functions as an
intermediate LSR. Therefore, identifying a pair of ingress intermediate LSR. Therefore, identifying a pair of ingress
and egress LSRs using each LSP is needed to determine the and egress LSRs using each LSP is needed to determine the
cost of the service that a customer is using. cost of the service that a customer is using.
4.11.1 Requirements 4.11.1. Requirements
Accounting on a per-LSP basis encompasses the following set of Accounting on a per-LSP basis encompasses the following set of
functions: functions:
(1) At an ingress LSR accounting of traffic through LSPs (1) At an ingress LSR, accounting of traffic through LSPs that
beginning at each egress in question. begin at each egress in question.
draft-ietf-mpls-oam-requirements-07 December 7, 2005
(2) At an intermediate LSR, accounting of traffic through (2) At an intermediate LSR, accounting of traffic through LSPs for
LSPs for each pair of ingress to egress. each pair of ingress to egress.
(3) At egress LSR, accounting of traffic through LSPs (3) At egress LSR, accounting of traffic through LSPs for each
for each ingress. ingress.
(4) All LSRs that contain LSPs that are being measured (4) All LSRs containing LSPs that are being measured need to have
need to have a common identifier to distinguish each LSP. a common identifier to distinguish each LSP. The identifier
The identifier MUST be unique to each LSP, and its mapping to MUST be unique to each LSP, and its mapping to LSP SHOULD be
LSP SHOULD be provided from whether manual or automatic provided whether from manual or automatic configuration.
configuration.
In the case of non-merged LSPs, this can be achieved by In the case of non-merged LSPs, this can be achieved by simply
simply reading traffic counters for the label stack associated reading traffic counters for the label stack associated with the
with the LSP at any LSR along its path. However, in order to LSP at any LSR along its path. However, in order to measure
measure merged LSPs, an LSR MUST have a means to distinguish merged LSPs, an LSR MUST have a means to distinguish the source of
the source of each flow so as to disambiguate the statistics. each flow so as to disambiguate the statistics.
4.11.2 Location of Accounting 4.11.2. Location of Accounting
It is not realistic to perform the just described operations by It is not realistic for LSRs to perform the described operations on
LSRs in a network on all LSPs that exist in a network. all LSPs that exist in a network. At a minimum, per-LSP based
At a minimum, per-LSP based accounting SHOULD be performed on the accounting SHOULD be performed on the edges of the network -- at the
edges of the network -- at the edges of both LSPs and the MPLS edges of both LSPs and the MPLS domain.
domain.
5. Security Considerations 5. Security Considerations
Provisions to any of the network mechanisms designed to satisfy Provisions to any of the network mechanisms designed to satisfy the
the requirements described herein are required to prevent their requirements described herein are required to prevent their
unauthorized use. Likewise, these network mechanisms MUST unauthorized use. Likewise, these network mechanisms MUST provide a
provide a means by which an operator can prevent denial of means by which an operator can prevent denial of service attacks if
service attacks if those network mechanisms are used in such those network mechanisms are used in such an attack.
an attack.
LSP mis-merging has security implications beyond that of simply LSP mis-merging has security implications beyond that of simply being
being a network defect. LSP mis-merging can happen due to a number a network defect. LSP mis-merging can happen due to a number of
of potential sources of failure, some of which (due to MPLS label potential sources of failure, some of which (due to MPLS label
stacking) are new to MPLS. stacking) are new to MPLS.
The performance of diagnostic functions and path characterization The performance of diagnostic functions and path characterization
involve extracting a significant amount of information about involve extracting a significant amount of information about network
network construction which the network operator MAY consider construction that the network operator MAY consider private.
private.
6. IANA Considerations
draft-ietf-mpls-oam-requirements-07 December 7, 2005
This document creates no new requirements on IANA namespaces
[RFC2434].
7. References 6. References
7.1 Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2 Informative References 6.2. Informative References
[LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Failures", Internet Draft draft-ietf-mpls-lsp-ping-11.txt, Label Switched (MPLS) Data Plane Failures", RFC 4379,
November 2005. February 2006.
[RFC3812] Srinivasan, C., Viswanathan, A. and T. [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
Nadeau, "Multiprotocol Label Switching "Multiprotocol Label Switching (MPLS) Traffic Engineering
(MPLS) Traffic Engineering (TE) (TE) Management Information Base (MIB)", RFC 3812, June
Management Information Base (MIB)", 2004.
RFC3812, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A. and T. [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
Nadeau, "Multiprotocol Label Switching "Multiprotocol Label Switching (MPLS) Label Switching
(MPLS) Label Switching Router (LSR) Router (LSR) Management Information Base (MIB)", RFC 3813,
Management Information Base (MIB)", RFC3813,
June 2004. June 2004.
[RFC3814] Nadeau, T., Srinivasan, C., and A. [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
Viswanathan, "Multiprotocol Label Switching "Multiprotocol Label Switching (MPLS) Forwarding
(MPLS) Forwarding Equivalence Class To Next Equivalence Class To Next Hop Label Forwarding Entry
Hop Label Forwarding Entry (FEC-To-NHLFE) (FEC-To-NHLFE) Management Information Base (MIB)", RFC
Management Information Base (MIB)", RFC3814, 3814, June 2004.
June 2004.
[Y1710] ITU-T Recommendation Y.1710, "Requirements for [Y1710] ITU-T Recommendation Y.1710, "Requirements for OAM
OAM Functionality In MPLS Networks" Functionality In MPLS Networks"
[I610] ITU-T Recommendation I.610, "B-ISDN operations and [I610] ITU-T Recommendation I.610, "B-ISDN operations and
maintenance principles and functions", February 1999 maintenance principles and functions", February 1999
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations section in RFCs", BCP 26, RFC IANA Considerations Section in RFCs", BCP 26, RFC 2434,
2434, October 1998. October 1998.
draft-ietf-mpls-oam-requirements-07 December 7, 2005
[RFC792] Postel, J., "Internet Control Message Protocol", RFC792, [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
September 1981. 792, September 1981.
[RFC3443] Agarwal, P, Akyol, B., "Time To Live (TTL) Processing in [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks.", RFC3443, Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
January 2003. January 2003.
8. Authors' Addresses 7. Acknowledgements
The authors wish to acknowledge and thank the following individuals
for their valuable comments to this document: Adrian Smith, British
Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr.
Kumaki, KDDI. Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan
Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa,
Intec Netcore, and David Meyer.
Authors' Addresses
Comments should be made directly to the MPLS mailing list
at mpls@lists.ietf.org.
Thomas D. Nadeau Thomas D. Nadeau
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxboro, MA 01719 Boxboro, MA 01719
Phone: +1-978-936-1470 Phone: +1-978-936-1470
Email: tnadeau@cisco.com EMail: tnadeau@cisco.com
Monique Jeanne Morrow Monique Jeanne Morrow
Cisco Systems, Inc. Cisco Systems, Inc.
Glatt-Com, 2nd Floor Glatt-Com, 2nd Floor
CH-8301 CH-8301
Switzerland Switzerland
Voice: (0)1 878-9412
Email: mmorrow@cisco.com Phone: (0)1 878-9412
EMail: mmorrow@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxboro, MA 01719 Boxboro, MA 01719
Voice: +1-978-936-1398
Email: swallow@cisco.com
Phone: +1-978-936-1398
EMail: swallow@cisco.com
David Allan David Allan
Nortel Networks Nortel Networks
3500 Carling Ave. 3500 Carling Ave.
Ottawa, Ontario, CANADA Ottawa, Ontario, CANADA
Voice: 1-613-763-6362
Email: dallan@nortelnetworks.com Phone: 1-613-763-6362
EMail: dallan@nortel.com
Satoru Matsushima Satoru Matsushima
Japan Telecom Japan Telecom
1-9-1, <, Minato-ku 1-9-1, Higashi-Shinbashi, Minato-ku
Tokyo, 105-7316 Japan Tokyo, 105-7316 Japan
Phone: +81-3-6889-1092 Phone: +81-3-6889-1092
Email: satoru@ft.solteria.net EMail: satoru@ft.solteria.net
draft-ietf-mpls-oam-requirements-07 December 7, 2005
9. Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
10. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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 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.
11. Acknowledgment
draft-ietf-mpls-oam-requirements-07 December 7, 2005
Funding for the RFC Editor function is currently provided by the Acknowledgement
Internet Society.
The authors wish to acknowledge and thank the following Funding for the RFC Editor function is provided by the IETF
individuals for their valuable comments to this document: Administrative Support Activity (IASA).
Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr.
Ikejiri, NTT Communications and Mr.Kumaki of KDDI.
Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T;
Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore,
and David Meyer.
 End of changes. 109 change blocks. 
461 lines changed or deleted 391 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/