draft-ietf-mpls-oam-requirements-06.txt   draft-ietf-mpls-oam-requirements-07.txt 
Network Working Group Thomas D. Nadeau Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow Internet Draft Monique Morrow
Expires: July 2005 George Swallow Expires: June 2006 George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
David Allan David Allan
Nortel Networks Nortel Networks
Satoru Matsushima Satoru Matsushima
Japan Telecom Japan Telecom
January 2006 December 2005
OAM Requirements for MPLS Networks Operations and Management Requirements
draft-ietf-mpls-oam-requirements-06.txt for Multi-Protocol Label Switched Networks
draft-ietf-mpls-oam-requirements-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use
material or to cite them other than as "work in progress." 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html 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.
Abstract Abstract
As transport of diverse traffic types such as voice, frame This document specifies Operations and Management requirements
relay, and ATM over MPLS become more common, the ability to detect, for Multi-Protocol Label Switching, as well as for applications
handle and diagnose control and data plane defects becomes draft-ietf-mpls-oam-requirements-07 December 7, 2005
critical.
Detection and specification of how to handle those defects is not of Multi-Protocol Label Switching such as pseudo-wire voice and
only important because such defects may not only affect the virtual private network services. These requirements
fundamental operation of an Multi-Protocol Label Switching (MPLS) have been gathered from network operators who have extensive
network, but also because they MAY impact service level specification experience deploying Multi-Protocol Label Switching networks.
commitments for customers of that network.
This document describes requirements for user and data Table of Contents
plane operations and management for MPLS.
These requirements have been gathered
from network operators who have extensive experience deploying
MPLS networks, similarly some of these
requirements have appeared in other documents. This draft specifies
Operations and Management requirements for Multi-Protocol Label
Switching, as well as for applications of Multi-Protocol Label
Switching such as pseudowire voice and virtual private network
services. Those interested in specific issues relating to
instrumenting MPLS for Operations
and Management purposes are directed to the Multi-Protocol Label
Switching Architecture specification.
Abstract......................................................1 Abstract ....................................................1
1 Introduction..................................................2 1. Introduction ................................................2
2 Document Conventions..........................................2 2. Document Conventions ........................................2
2.1 Terminology..................................................2 2.1 Terminology .................................................2
2.2 Acronyms.....................................................2 2.2 Acronyms ....................................................2
3. Motivations..................................................2 3. Motivations .................................................2
4. Requirements..................................................2 4. Requirements ................................................2
5 Security Considerations......................................26 5. Security Considerations ....................................26
6 IANA considerations..........................................27 6. IANA considerations ........................................27
7 References..................................................27 7. References .................................................27
7.1 Normative references........................................27 7.1 Normative references .......................................27
7.2 Informative references......................................29 7.2 Informative references .....................................29
8 Author's Addresses..........................................29 8. Author's Addresses .........................................29
9 Intellectual Property Notice................................30 9. Intellectual Property Notice ...............................30
10 Full Copyright Statement...................................29 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 operations and management (OAM) for Multi-Protocol plane operations and management (OAM) for Multi-Protocol
Label Switching (MPLS). These requirements have been gathered Label Switching (MPLS). These requirements have been gathered
from network operators who have extensive experience deploying from network operators who have extensive experience deploying
MPLS networks. This draft specifies OAM requirements MPLS networks. This draft specifies OAM requirements
for MPLS, as well as for applications of MPLS. for MPLS, as well as for applications of MPLS.
No specific mechanisms are proposed to address these No specific mechanisms are proposed to address these
requirements at this time. The goal of this draft is to requirements at this time. The goal of this draft is to
identify a commonly applicable set of requirements for MPLS identify a commonly applicable set of requirements for MPLS
OAM at this time. Specifically, a set of requirements that apply OAM at this time. Specifically, a set of requirements that apply
to the most common set of MPLS networks deployed by service to the most common set of MPLS networks deployed by service
provider organizations today. These requirements can then be used 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 as a base for network management tool development and to guide
the evolution of currently specified tools, as well as the the evolution of currently specified tools, as well as the
specification of OAM functions that are intrinsic to protocols specification of OAM functions that are intrinsic to protocols
used in MPLS networks. used in MPLS networks.
Comments should be made directly to the MPLS mailing list Comments should be made directly to the MPLS mailing list
at mpls@lists.ietf.org. at mpls@lists.ietf.org.
draft-ietf-mpls-oam-requirements-07 December 7, 2005
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. document are to be interpreted as described in RFC 2119 [RFC2119].
Defect: Any error condition that prevents an LSP
functioning correctly. For example, loss of an
IGP path will most likely also result in an LSP
not being able to deliver traffic to its
destination. Another example is the breakage of
a TE tunnel. These MAY be due to physical
circuit failures or failure of switching nodes
to operate as expected.
Multi-vendor/multi-provider network operation typically
requires agreed upon definitions of defects (when it is
broken and when it is not) such that both recovery
procedures and service level specification impacts can
be specified.
Head-end Label Switch Router (LSR): The beginning of a label Queuing/buffering Latency: delay caused by packet queuing (value is
switched path. variable since depending on the packet
arrival rate in addition to the
dependence on the packet length and the
link throughput).
Probe-based-detection: Active measurement using a tool such as Probe-based-detection: Active measurement tool which can measure
LSP ping. the consistency of an LSP [LSPPING].
Collecting traffic: Passive measurement of network traffic. Defect: Any error condition that prevents an Label
Switched Path functioning correctly. For
example, loss of an IGP path will most
likely also result in a Label Switched
Path not being able to deliver traffic to
its destination. Another example is the
breakage of a TE tunnel. These may be due
to physical circuit failures or failure
of switching nodes to operate as expected.
Head-end Label Switching Router (LSR): The beginning of a label Multi-vendor/multi-provider network
switched path. A head-end LSR is also referred to as operation typically requires agreed upon
an Ingress Label Switching Router. definitions of defects (when it is broken
and when it is not) such that both
recovery procedures and service level
specification impacts can be specified.
Probe-based-detection: Active measurement using a tool such as Head-end Label Switching
LSP ping. Router (LSR): The beginning of a label switched path. A
head-end LSR is also referred to as an
ingress LSR.
Collecting traffic: Passive measurement of network traffic. Tail-end Label Switching
Router (LSR): The end of a label switched path. A
tail-end LSR is also referred to as an
egress LSR.
propagation latency: delay added by the propagation of the packet Propagation Latency: The delay added by the propagation of the
through the link (fixed value that depends on draft-ietf-mpls-oam-requirements-07 December 7, 2005
the distance of the link and the propagation
speed).
transmission latency: delay added by the transmission of the packey packet through the link (fixed value that
over the link i.e. the time it takes put the depends on the distance of the link and
packet over the media (value that depends of the propagation speed).
the link throughput and packet length).
processing latency: delay added by all the operations related to the Transmission Latency: The delay added by the transmission of
switching of labeled packet (value is node the packet over the link i.e. the time
implementation specific and may are considered it takes put the packet over the media
as fixed and constant for a given equipment). (value that depends on the link
throughput and packet length).
queuing/buffering latency: delay caused by packet queuing (value is Processing Latency: The delay added by all the operations
variable since depending on the packet related to the switching of labeled
arrival rate in addition to the packet (value is node implementation
dependance on the packet length and the specific and may be considered as fixed
link throughput). and constant for a given type of
equipment).
node latency: delay added by the network element resulting from of Node Latency: The delay added by the network element
the sum of the transmission, processing and queuing/ resulting from of the sum of the
transmission, processing and queuing/
buffering latency buffering latency
one-hop delay: fixed delay experienced by a packet to reach the next One-hop Delay: The fixed delay experienced by a packet
hop reesulting from the of the propagation latency, to reach the next hop resulting from the
the transmission latency and the processing latency. of the propagation latency, the
transmission latency and the processing
latency.
minimum path latency: sum of the one-hop delays experienced by the Minimum Path Latency: The sum of the one-hop delays experienced
packet when travelling from the ingress to the by the packet when traveling from the
egress LSR. ingress to the egress LSR.
variable path latency (jitter): sum of the delays caused by the Variable Path Latency: The sum of the delays caused by the
queuing latency experienced by the queuing latency experienced by the
packet at each node over the path. packet at each node over the path.
Otherwise known as jitter.
2.2 Acronyms 2.2 Acronyms
ASBR: Autonomous System Border Router
CE: Customer Edge CE: Customer Edge
PE: Provider Edge
SP: Service Provider SP: Service Provider
draft-ietf-mpls-oam-requirements-07 December 7, 2005
ECMP: Equal Cost Multipath ECMP: Equal Cost Multi-path
LSP: Label Switch Path LSP: Label Switched Path
LSR: Label Switch Router LSP Ping: Label Switched Path Ping
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
MPLS OAM has been tackled in numerous Internet drafts. This document was created in order to provide requirements
However as of this writing, existing drafts focus on single which could be used to create consistent and useful OAM
provider solutions or focus on a single aspect of the MPLS functionality that meets operational requirements of those
architecture or application of MPLS. For example, the use service providers who have or are deploying MPLS.
of RSVP or LDP signaling and defects MAY be covered in some
deployments, and a corresponding SNMP MIB module exists to
manage this application; however, the handling of defects
and specification of which types of defects are interesting
to operational networks MAY not have been created in concert
with those for other applications of MPLS such as L3 VPN.
This leads to inconsistent and inefficient applicability
across the MPLS architecture, and/or requires significant
modifications to operational procedures and systems in order
to provide consistent and useful OAM functionality which do
not create inconsistencies with existing solutions. As MPLS
has matured, relationships between providers has become more
complex. Furthermore, the deployment of multiple concurrent
applications of MPLS is common place, leading to a need to
consider broader and more uniform solutions, rather than very
specific ad hoc point solutions.
4. Requirements 4. Requirements
The following sections enumerate the OAM requirements The following sections enumerate the OAM requirements
gathered from service providers who have deployed MPLS gathered from service providers who have deployed MPLS
and services based on MPLS networks. Each requirement is and services based on MPLS networks. Each requirement is
specified in detail to clarify its applicability. specified in detail to clarify its applicability.
Although the requirements specified herein are defined by Although the requirements specified herein are defined by
the IETF, they have been harmonized 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 Switch Path Defects 4.1 Detection of Label Switched Path Defects
The ability to detect defects in a broken Label Switch Path The ability to detect defects in a broken Label Switched Path
(LSP) SHOULD not require manual hop-by-hop troubleshooting of (LSP) MUST not require manual hop-by-hop troubleshooting of
each LSR used to switch traffic for that LSP. For example, each LSR used to switch traffic for that LSP. For example,
it is not desirable to manually visit each LSR along the data it is not desirable to manually visit each LSR along the data
plane path used to transport an LSP; instead,this function plane path used to transport an LSP; instead,this function
SHOULD be automated and able to be performed at some operator MUST be automated and able to be performed at some operator
specified frequency from the origination point of that LSP. specified frequency from the origination point of that LSP.
This implies solutions that are interoperable as to allow for This implies solutions that are interoperable as to allow for
such automatic operation. Furthermore, the automation of path such automatic operation.
liveliness is desired in cases where large numbers of LSPs might
be tested. For example, automated ingress LSR to egress LSR testing Furthermore, the automation of path liveliness is desired in
functionality is desired for some LSPs. The goal is to detect LSP draft-ietf-mpls-oam-requirements-07 December 7, 2005
path defects before customers do, and this requires detection of
LSP defects in a "reasonable" amount of time. One useful cases where large numbers of LSPs might be tested. For example,
definition of reasonable is both predictable and consistent. automated ingress LSR to egress LSR testing functionality is
desired for some LSPs. The goal is to detect LSP path defects
before customers do, and this requires detection and correction
of LSP defects in a manner that is both predictable and
sufficiently within the constraints of the service level agreement
under which the service is being offered. Simply 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
this defect by possibly correcting it or notifying the customer,
must fall within the bounds of the service level agreement in
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 specifying defect detection broken LSPs is required. Failure to specify defect detection
time bounds may result in an ambiguity in test results. If the time bounds may result in an ambiguity in test results. If the
time to detect is known, then automated responses can be specified time to detect is known, then automated responses can be specified
both with respect to and with regard to resiliency and service both with respect to and with regard to resiliency and service
level specification reporting. Further, if synchronization of level specification reporting. Further, if synchronization of
detection time bounds is possible, an operational framework can be detection time bounds is possible, an operational framework can be
established that can guide the design and specification of MPLS established that can guide the design and specification of MPLS
applications. applications.
Although ICMP-based ping [RFC792] can be sent through an LSP, the Although ICMP-based ping [RFC792] can be sent through an LSP as
use of this tool to verify the defect free operation of an LSP an IP payload, the use of this tool to verify the defect free
has the potential for returning erroneous results (both positive and operation of an LSP has the potential for returning erroneous
negative). For example, failures may occur when results (both positive and negative) for a number of reasons. First,
inconsistencies exist within the IP or MPLS forwarding tables, since the ICMP traffic is based on legally addressable IP addressing,
in the MPLS control and data planes or LSP. Failures may also result it is possible for ICMP messages that are originally transmitted
from defects with the reply path (i.e., a reverse path does not inside of an LSP to "fall out of the LSP" at some point along
exist) used to return a response to a test message. As an example the path. In these cases, since ICMP packets are routable
of a false positive, consider the case where the MPLS data a falsely positive response may be returned. In other cases
plane flows through a network node using a different output line where the data plane of a specific LSP needs to be tested, it
card than the data plane uses to reach the next-hop neighbor. Also is difficult to guarantee that traffic based on an ICMP ping
assume that although the control plane is functional, the data header is parsed and hashed to the same equal-cost multi-paths
plane on the output line card where data traffic is programmed to as the data traffic.
exit the device is defective. Now, if an LSP is signaled using
this node, any test based solely on the control plane's view of the Any detection mechanisms that depend on receiving status via a
world (i.e., ICMP-based) will return with a false positive result return path SHOULD provide multiple return options with the
because although the control plane traffic at the node in the expectation that one of them will not be impacted by the original
example would be forwarded correctly, the actual data plane defect. An example of a case where a false negative might occur
switching at the node in the example would misroute or drop any would be a mechanism that requires a functional MPLS return path.
traffic transmitted onto that LSP. An example of a false Since MPLS LSPs are unidirectional, it is possible that although
negative case would be when a functioning return path does not the forward LSP which is the LSP under test, might be functioning,
exist. In this case, neither a positive nor a negative reply the response from the destination LSR might be lost, thus giving
will be received by the sender. Therefore any detection mechanisms the source LSR the false impression that the forward LSP is
that depend on receiving status via a return path SHOULD provide defective. However, if an alternate return path could be
multiple return options with the expectation that one of them will draft-ietf-mpls-oam-requirements-07 December 7, 2005
not be impacted by the original defect.
specified -- say IP for example -- then the source could
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 exactly the customer data path in order
to reflect path liveliness used by customer data. Particular cases to reflect path liveliness used by customer data. Particular cases
of interest are forwarding mechanisms such as equal cost multipath of interest are forwarding mechanisms such as equal cost multi-path
(ECMP) scenarios within the operator's network whereby flows are (ECMP) scenarios within the operator's network whereby flows are
load-shared across parallel (i.e., equal IGP cost) paths. Where load-shared across parallel (i.e., equal IGP cost) paths. Where
the customer traffic MAY be spread over multiple paths, what is the customer traffic may be spread over multiple paths, what is
required is to be able to detect failures on any of the path required is to be able to detect failures on any of the path
permutations. Where the spreading mechanism is payload specific, permutations. Where the spreading mechanism is payload specific,
payloads need to have forwarding that is common with the traffic payloads need to have forwarding that is common with the traffic
under test. Satisfying these requirements introduces complexity under test. Satisfying these requirements introduces complexity
into ensuring that ECMP connectivity permutations are exercised, into ensuring that ECMP connectivity permutations are exercised,
and that defect detection occurs in a reasonable amount of time. and that defect detection occurs in a reasonable amount of time.
4.2 Diagnosis of a Broken Label Switch 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, note that specifying recovery actions for misbranching example, note that specifying recovery actions for mis-branching
defects in an LDP network is a particularly difficult case. defects in an LDP network is a particularly difficult case.
Diagnosis of defects and isolation of the failed component is Diagnosis of defects and isolation of the failed component is
best accomplished via a path trace function which can return the best accomplished via a path trace function which can return the
the entire list of LSRs and links used by a certain LSP (or at the entire list of LSRs and links used by a certain LSP (or at
least the set of LSRs/links up to the location of the defect) is least the set of LSRs/links up to the location of the defect) is
required. The tracing capability SHOULD include the ability to required. The tracing capability SHOULD include the ability to
trace recursive paths, such as when nested LSPs are used. This trace recursive paths, such as when nested LSPs are used. This
path trace function MUST also be capable of diagnosing LSP path trace function MUST also be capable of diagnosing LSP
mis-merging by permitting comparison of expected vs. actual mis-merging by permitting comparison of expected vs. actual
forwarding behavior at any LSR in the path. The path trace forwarding behavior at any LSR in the path. The path trace
capability SHOULD be capable of being executed from both the capability SHOULD be capable of being executed from both the
head-end Label Switch Router (LSR) and MAY permit downstream head-end Label Switching Router (LSR) and may permit downstream
path components to be traced from an intermediate mid-point LSR. path components to be traced from an intermediate mid-point LSR.
Additionally, the path trace function MUST have the ability to Additionally, the path trace function MUST have the ability to
support equal cost multipath scenarios described above in support equal cost multi-path scenarios described above in
section 4.1. 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. later during subsequent testing relevant to OAM functionality.
This would include but is not limited to: This would include 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 - sufficient details that allow the test origin to
excersize all path permutations related to load spreading excursive all path permutations related to load spreading
(e.g. ECMP). (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 - defect free forwarding. The service is considered to be
available and the other aspects of performance measurement available and the other aspects of performance measurement
skipping to change at page 8, line 33 skipping to change at page 8, line 32
other aspects of performance measurement do not. other aspects of performance measurement do not.
- latency - amount of time required for traffic to transit - latency - amount of time required for traffic to transit
the network 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 Such measurements can be made independently of the user traffic
or via a hybrid of user traffic measurement and OAM probing. or via a hybrid of user traffic measurement and OAM probing.
At least one mechanism is required to measure the number At least one mechanism is required to measure the number
of OAM packets. In addition, the ability to measure the qualitative of OAM packets. In addition, the ability to measure the
aspects of LSPs such as jitter, delay, latency and loss MUST quantitative aspects of LSPs such as jitter, delay, latency and
be available in order to determine whether or not the traffic for loss MUST be available in order to determine whether or not the
a specific LSP are traveling within the operator-specified traffic for a specific LSP are traveling within the
tollerances. operator-specified tolerances.
Any method considered SHOULD be capable of measuring the latency Any method considered SHOULD be capable of measuring the latency
of an LSP with minimal impact on network resources. See section of an LSP with minimal impact on network resources. See section
2.1 for definitions of the various qualitative aspects of LSPs. 2.1 for definitions of the various quantitative aspects of LSPs.
4.5 Frequency of OAM Execution 4.5 Frequency of OAM Execution
The operator MUST have the flexibility to configure OAM The operator MUST have the flexibility to configure OAM
parameters insofaras to meet their specific operational parameters insofar-as to meet their specific operational
requirements. requirements.
This includes the frequency of the execution of any OAM This includes the frequency of the execution of any OAM
functions. The capability to synchronize OAM operations is required functions. The capability to synchronize OAM operations is required
as to to permit consistent measurement of service level agreements. as to to permit consistent measurement of service level agreements.
To elaborate, there are defect conditions such as misbranching or 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 misdirection of traffic for which probe-based detection mechanisms
that incur significant mismatches in the probe rate MAY result in that incur significant mismatches in their detection frequency may
flapping. This can be addressed either by synchronizing the rate result in flapping. This can be addressed either by synchronizing
or having the probes self-identify their probe rate. the rate or 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 synchronization of defect and service level inter-carrier synchronization of defect and service level
specification handling will drive specification of OAM parameters specification handling will drive specification of OAM parameters
to commonly agreed on values and such values will have to be to commonly agreed on values and such values will have to be
harmonized with the surrounding technologies (e.g. SONET/SDH, harmonized with the surrounding technologies (e.g. SONET/SDH,
ATM etc.) in order to be useful. This will become particularly ATM etc.) in order to be useful. This will become particularly
important as networks scale and misconfiguration can result in important as networks scale and mis-configuration can 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 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, and thereby greatly reducing the
number of notifications emitted. When viewed in conjuction with number of notifications emitted. When viewed in conjunction with
requirement 4.7 below, this typically requires fault notification requirement 4.7 below, this typically requires fault notification
to the LSP egress that to the LSP egress that may have specific time constraints if the
MAY have specific time constraints if the application using the LSP application using the LSP independently implements path continuity
independently implements path continuity testing (for example ATM testing (for example ATM I.610 Continuity check (CC)[I610]).
I.610 Continuity check (CC)[I610]). These constraints apply to These constraints apply to LSPs that are monitored. The nature of
LSPs that are monitored. The nature of MPLS applications allows MPLS applications allows for the possibility to have multiple MPLS
for the possibility to have multiple MPLS applications attempt to applications attempt to respond to defects simultaneously. For
respond to defects simultaneously. For example, layer-3 MPLS VPNs example, layer-3 MPLS VPNs that utilize Traffic Engineered tunnels,
that utilize Traffic Engineered tunnels, where a failure occurs on where a failure occurs on the LSP carrying the Traffic Engineered
the LSP carrying the Traffic Engineered tunnel. This failure would tunnel. This failure would affect he VPN traffic that uses the
affect he VPN traffic that uses the tunnel's LSP. Mechanisms are tunnel's LSP. Mechanisms are required to coordinate network response
required to coordinate network response to defects. to defects.
4.7 Support for OAM Interworking for Fault Notification 4.7 Support for OAM Inter-working for Fault Notification
An LSR supporting the interworking 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 the native technology's error condition. For example, errors into the native technology's error condition. For example, errors
occurring over a MPLS transport LSP that supports an emulated occurring over a MPLS transport LSP that supports an emulated
draft-ietf-mpls-oam-requirements-07 December 7, 2005
ATM VC MUST translate errors into native ATM OAM Alarm Indication ATM VC MUST translate errors into native ATM OAM Alarm Indication
Signal (AIS) cells at the termination points of the LSP. The Signal (AIS) cells at the termination points of the LSP. The
mechanism SHOULD consider possible bounded detection time mechanism SHOULD consider possible bounded detection time
parameters, e.g., a "hold off" function before reacting as to parameters, e.g., a "hold off" function before reacting as to
synchronize with the OAM functions. synchronize with the OAM functions.
One goal would be alarm suppression by the upper layer using One goal would be alarm suppression by the upper layer using
the LSP. As observed in section 4.5, this requires that MPLS the LSP. As observed in section 4.5, this requires that MPLS
perform detection in a bounded timeframe in order to initiate perform detection in a bounded timeframe in order to initiate
alarm suppression prior to the upper layer independently alarm suppression prior to the upper layer independently
detecting the defect. 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 OAM procedures. These procesures will detect a broader range MPLS OAM procedures. These procedures will detect a broader range
of defects than that of simple link and node failures. of defects than that of simple link and node failures.
Since MPLS LSPs may span multiple routing areas and service provider Since MPLS LSPs may span multiple routing areas and service provider
domains, fault recovery and error detection should be possible domains, fault recovery and error detection should be possible
in these configuration as well as in the more simplifed in these configuration as well as in the more simplified
single-area/domain configurations. single-area/domain 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. This is modeling of management and control of OAM functionality.
reflected in the the integration of standard MPLS-related MIBs Evidence of this is reflected in the standard IETF MPLS-related
(e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and MIB modules (e.g. [RFC3813][RFC3812][RFC3814]) for fault,
configuration management. These standard interfaces provide statistics and configuration management. These standard interfaces
operators with common programmatic interface access to provide operators with common programmatic interface access to
operations and management functions and their status. operations and management functions and their status. However,
gaps in coverage of MIB modules to OAM and other features
exists; therefore, MIB modules corresponding to new protocol
functions or network tools are 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 (SPs) can measure traffic
from an LSR to the egress of the network using some MPLS related from an LSR to the egress of the network using some MPLS related
MIBs, for example. This means that it is a reasonable to know how MIBs, for example. This means that it is a reasonable to know how
much traffic is traveling from where to where (i.e., a traffic much traffic is traveling from where to where (i.e., a traffic
matrix) by analyzing the flow of traffic. Therefore, traffic matrix) by analyzing the flow of traffic. Therefore, traffic
accounting in an MPLS network can be summarized as the following accounting in an 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 Providers and their customers MAY need to verify high-level
service level specifications, either to continuously service level specifications, either to continuously
optimize their networks, or to offer guaranteed bandwidth optimize their networks, or to offer guaranteed bandwidth
services. Therefore, traffic accounting to monitor MPLS services. Therefore, traffic accounting to monitor MPLS
applications is required. applications is required.
(2) Providing a Service Level Specification (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 informationr. Optimizing provider may offer the traffic information. Optimizing
network design needs this information. network design needs this information.
(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
skipping to change at page 11, line 46 skipping to change at page 12, line 5
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
beginning at each egress in question. beginning 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 each pair of ingress to egress. LSPs for 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 ingress. for each ingress.
(4) All LSRs that contain LSPs that are being measuremented (4) All LSRs that contain LSPs that are being measured
need to have a common key to distinguish each LSP. need to have a common identifier to distinguish each LSP.
The key MUST be unique to each LSP, and its mapping to The identifier MUST be unique to each LSP, and its mapping to
LSP SHOULD be provided from whether manual or automatic LSP SHOULD be provided from whether 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 reading traffic counters for the label stack associated simply reading traffic counters for the label stack associated
with the LSP at any LSR along its path. However, in order to with the LSP at any LSR along its path. However, in order to
measure merged LSPs, an LSR MUST have a means to distinguish measure merged LSPs, an LSR MUST have a means to distinguish
the source of each flow so as to disambiguate the statistics. the source of each flow so as to disambiguate the statistics.
4.11.2 Scalability 4.11.2 Location of Accounting
It is not realistic to perform the just described operations by It is not realistic to perform the just described operations by
LSRs in a network on all LSPs that exist in a network. LSRs in a network on all LSPs that exist in a network.
At a minimum, per-LSP based accounting SHOULD be performed on the At a minimum, per-LSP based accounting SHOULD be performed on the
edges of the network -- at the edges of both LSPs and the MPLS edges of the network -- at the edges of both LSPs and the MPLS
domain. domain.
5. Security Considerations 5. Security Considerations
Provisions to any of the tools designed to satisfy the requirements Provisions to any of the network mechanisms designed to satisfy
described herin are required to prevent their unauthorized use. the requirements described herein are required to prevent their
Likewise, these tools MUST provide a means by which an operator unauthorized use. Likewise, these network mechanisms MUST
can prevent denial of service attacks if those tools are used in provide a means by which an operator can prevent denial of
such an attack. service attacks if those network mechanisms are used in such
an attack.
LSP mis-merging has security implications beyond that of simply LSP mis-merging has security implications beyond that of simply
being a network defect. LSP mis-merging can happen due to a number being a network defect. LSP mis-merging can happen due to a number
of potential sources of failure, some of which (due to MPLS label of 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 construction which the network operator MAY consider network construction which the network operator MAY consider
private. private.
6. IANA Considerations 6. IANA Considerations
draft-ietf-mpls-oam-requirements-07 December 7, 2005
This document creates no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
7. References 7. References
7.1 Informative References 7.1 Normative References
[RFC3812] Srinivasan, C., Viswanathan, A. and T. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Nadeau, "MPLS Traffic Engineering Management 7.2 Informative References
Information Base Using SMIv2", RFC3812, June 2004.
[LSPPING] Kompella, K., G. Swallow, " Detecting MPLS Data Plane
Failures", Internet Draft draft-ietf-mpls-lsp-ping-11.txt,
November 2005.
[RFC3812] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "Multiprotocol Label Switching
(MPLS) Traffic Engineering (TE)
Management Information Base (MIB)",
RFC3812, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A. and T. [RFC3813] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management Nadeau, "Multiprotocol Label Switching
Information Base Using SMIv2", RFC3813, June 2004. (MPLS) Label Switching Router (LSR)
Management Information Base (MIB)", RFC3813,
June 2004.
[RFC3814] Nadeau, T., Srinivasan, C., and A. [RFC3814] Nadeau, T., Srinivasan, C., and A.
Viswanathan, "Multiprotocol Label Switching Viswanathan, "Multiprotocol Label Switching
(MPLS) FEC-To-NHLFE (FTN) Management (MPLS) Forwarding Equivalence Class To Next
Information Base", RFC3814, June 2004. Hop Label Forwarding Entry (FEC-To-NHLFE)
Management Information Base (MIB)", RFC3814,
June 2004.
[Y1710] ITU-T Recommendation Y.1710, "Requirements for [Y1710] ITU-T Recommendation Y.1710, "Requirements for
OAM Functionality In MPLS Networks" OAM 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 IANA Considerations section in RFCs", BCP 26, RFC an IANA Considerations section in RFCs", BCP 26, RFC
2434, October 1998. 2434, 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", RFC792,
September 1981. September 1981.
[RFC3443] Agarwal, P, Akyol, B., "Time To Live (TTL) Processing in [RFC3443] Agarwal, P, Akyol, B., "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks.", RFC3443, Multi-Protocol Label Switching (MPLS) Networks.", RFC3443,
January 2003. January 2003.
8. Authors' Addresses 8. Authors' Addresses
Thomas D. Nadeau Thomas D. Nadeau
skipping to change at page 14, line 20 skipping to change at page 14, line 47
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 Voice: 1-613-763-6362
Email: dallan@nortelnetworks.com Email: dallan@nortelnetworks.com
Satoru Matsushima Satoru Matsushima
Japan Telecom Japan Telecom
4-7-1, Hatchobori, Chuo-ku 1-9-1, <, Minato-ku
Tokyo, 104-8508 Japan Tokyo, 105-7316 Japan
Phone: +81-3-5540-8214 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 9. Intellectual Property Statement
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
skipping to change at page 15, line 4 skipping to change at page 15, line 31
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 ietf-
ipr@ietf.org. ipr@ietf.org.
10. Full Copyright Statement 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 Copyright (C) The Internet Society (2005).
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. IANA Considerations 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 has no IANA actions. 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.
12. Acknowledgment 11. Acknowledgment
draft-ietf-mpls-oam-requirements-07 December 7, 2005
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
The authors wish to acknowledge and thank the following The authors wish to acknowledge and thank the following
individuals for their valuable comments to this document: individuals for their valuable comments to this document:
Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr.
Ikejiri, NTT Communications and Mr.Kumaki of KDDI. Ikejiri, NTT Communications and Mr.Kumaki of KDDI.
Hari Rakotoranto, Miya Khono, Cisco Systems; Luyuan Fang, AT&T; Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T;
Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore, Danny McPherson, TCB; Dr.Ken Nagami, Ikuo Nakagawa, Intec Netcore,
and David Meyer. and David Meyer.
 End of changes. 85 change blocks. 
242 lines changed or deleted 281 lines changed or added

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