draft-ietf-mpls-oam-requirements-04.txt   draft-ietf-mpls-oam-requirements-05.txt 
Network Working Group Thomas D. Nadeau Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow Internet Draft Monique Morrow
Expires: April 2005 George Swallow Expires: May 2005 George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
David Allan David Allan
Nortel Networks Nortel Networks
Satoru Matsushima Satoru Matsushima
Japan Telecom Japan Telecom
September 2004 December 2004
OAM Requirements for MPLS Networks OAM Requirements for MPLS Networks
draft-ietf-mpls-oam-requirements-04.txt draft-ietf-mpls-oam-requirements-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed, patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we become aware will be or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
This document is an Internet-Draft and is subject to all This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667. By submitting this provisions of section 3 of RFC 3667. By submitting this
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Abstract Abstract
As transport of diverse traffic types such as voice, frame As transport of diverse traffic types such as voice, frame
relay, and ATM over MPLS become more common, the ability to detect, relay, and ATM over MPLS become more common, the ability to detect,
handle and diagnose control and data plane defects becomes handle and diagnose control and data plane defects becomes
critical. critical.
Detection and specification of how to handle those defects is not Detection and specification of how to handle those defects is not
only important because such defects may not only affect the only important because such defects may not only affect the
fundamental operation of an Multi-Protocol Label Switching network, fundamental operation of an Multi-Protocol Label Switching (MPLS)
but also because they MAY impact service level specification network, but also because they MAY impact service level specification
commitments for customers of that network. commitments for customers of that network.
This document describes requirements for user and data This document describes requirements for user and data
plane operations and management for Multi-Protocol plane operations and management for MPLS.
Label Switching. These requirements have been gathered These requirements have been gathered
from network operators who have extensive experience deploying from network operators who have extensive experience deploying
Multi-Protocol Label Switching networks, similarly some of these MPLS networks, similarly some of these
requirements have appeared in other documents. This draft specifies requirements have appeared in other documents. This draft specifies
Operations and Management requirements for Multi-Protocol Label Operations and Management requirements for Multi-Protocol Label
Switching, as well as for applications of Multi-Protocol Label Switching, as well as for applications of Multi-Protocol Label
Switching such as pseudowire voice and virtual private network Switching such as pseudowire voice and virtual private network
services. Those interested in specific issues relating to services. Those interested in specific issues relating to
instrumenting Multi-Protocol Label Switching for Operations instrumenting MPLS for Operations
and Management purposes are directed to the Multi-Protocol Label and Management purposes are directed to the Multi-Protocol Label
Switching Architecture specification. Switching Architecture specification.
Table of Contents
1. Introduction.....................................................2
2. Terminology......................................................2
3. Motivations......................................................3
4. Requirements.....................................................4
5. Security Considerations..........................................8
6. IANA Considerations..............................................8
7. References.......................................................9
8. Authors' Addresses..............................................10
9. Copyright Notice.................................................11
10. Intellectual Property...........................................11
11. Disclaimer of Validity..........................................12
12. Copyright Statement.............................................12
13. Acknowledgment..................................................13
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
skipping to change at page 3, line 19 skipping to change at page 2, line 51
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. 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.
2. Terminology 2. Document Conventions
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.
CE: Customer Edge
Defect: Any error condition that prevents an LSP Defect: Any error condition that prevents an LSP
functioning correctly. For example, loss of an functioning correctly. For example, loss of an
IGP path will most likely also result in an LSP IGP path will most likely also result in an LSP
not being able to deliver traffic to its not being able to deliver traffic to its
destination. Another example is the breakage of destination. Another example is the breakage of
a TE tunnel. These MAY be due to physical a TE tunnel. These MAY be due to physical
circuit failures or failure of switching nodes circuit failures or failure of switching nodes
to operate as expected. to operate as expected.
Multi-vendor/multi-provider network operation typically Multi-vendor/multi-provider network operation typically
requires agreed upon definitions of defects (when it is requires agreed upon definitions of defects (when it is
broken and when it is not) such that both recovery broken and when it is not) such that both recovery
procedures and service level specification impacts can procedures and service level specification impacts can
be specified. be specified.
Head-end Label Switch Router (LSR): The beginning of a label
switched path.
Probe-based-detection: Active measurement using a tool such as
LSP ping.
Collecting traffic: Passive measurement of network traffic.
Head-end Label Switching Router (LSR): The beginning of a label
switched path. A head-end LSR is also referred to as
an Ingress Label Switching Router.
Probe-based-detection: Active measurement using a tool such as
LSP ping.
Collecting traffic: Passive measurement of network traffic.
propagation latency: delay added by the propagation of the packet
through the link (fixed value that depends on
the distance of the link and the propagation
speed).
transmission latency: delay added by the transmission of the packey
over the link i.e. the time it takes put the
packet over the media (value that depends of
the link throughput and packet length).
processing latency: delay added by all the operations related to the
switching of labeled packet (value is node
implementation specific and may are considered
as fixed and constant for a given equipment).
queuing/buffering latency: delay caused by packet queuing (value is
variable since depending on the packet
arrival rate in addition to the
dependance on the packet length and the
link throughput).
node latency: delay added by the network element resulting from of
the sum of the transmission, processing and queuing/
buffering latency
one-hop delay: fixed delay experienced by a packet to reach the next
hop reesulting from the of the propagation latency,
the transmission latency and the processing latency.
minimum path latency: sum of the one-hop delays experienced by the
packet when travelling from the ingress to the
egress LSR.
variable path latency (jitter): sum of the delays caused by the
queuing latency experienced by the
packet at each node over the path.
2.2 Acronyms
CE: Customer Edge
SP: Service Provider
ECMP: Equal Cost Multipath ECMP: Equal Cost Multipath
LSP: Label Switch Path LSP: Label Switch Path
LSR: Label Switch Router LSR: Label Switch Router
OAM: Operations and Management OAM: Operations and Management
Head-end Label Switch Router (LSR): The beginning of a label RSVP: Resource reSerVation Protocol
switched path.
probe-based-dectection: Active measurement using a tool such as LDP: Label Distribution Protocol
LSP ping.
collecting traffic: Passive measurement of network traffic. DoS: Denial of service
3. Motivations 3. Motivations
MPLS OAM has been tackled in numerous Internet drafts. MPLS OAM has been tackled in numerous Internet drafts.
However as of this writing, existing drafts focus on single provider However as of this writing, existing drafts focus on single
solutions or focus on a single aspect of the MPLS architecture provider solutions or focus on a single aspect of the MPLS
or application of MPLS. For example, the use of RSVP or LDP architecture or application of MPLS. For example, the use
signaling and defects MAY be covered in some deployments, of RSVP or LDP signaling and defects MAY be covered in some
and a corresponding SNMP MIB module exists to manage this deployments, and a corresponding SNMP MIB module exists to
application; however, the handling of defects and specification manage this application; however, the handling of defects
of which types of defects are interesting to operational and specification of which types of defects are interesting
networks MAY not have been created in concert with those for to operational networks MAY not have been created in concert
other applications of MPLS such as L3 VPN. This leads to with those for other applications of MPLS such as L3 VPN.
inconsistent and inefficient applicability across the MPLS This leads to inconsistent and inefficient applicability
architecture, and/or requires significant modifications to across the MPLS architecture, and/or requires significant
operational procedures and systems in order to provide consistent modifications to operational procedures and systems in order
and useful OAM functionality. As MPLS has matured, relationships to provide consistent and useful OAM functionality which do
between providers has become more complex. Furthermore, the not create inconsistencies with existing solutions. As MPLS
deployment of multiple concurrent applications of MPLS is common has matured, relationships between providers has become more
place, leading to a need to consider broader and more uniform complex. Furthermore, the deployment of multiple concurrent
solutions, rather than very specific ad hoc point solutions. 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 harmonized 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 Broken Label Switch Paths 4.1 Detection of Label Switch Path Defects
The ability to detect a broken Label Switch Path (LSP) The ability to detect defects in a broken Label Switch Path
SHOULD not require manual hop-by-hop troubleshooting of (LSP) SHOULD 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 performed from the origination of that LSP. SHOULD 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 This implies solutions that are interoperable as to allow for
such automatic operation. Furthermore, the automation of path such automatic operation. Furthermore, the automation of path
liveliness is desired in cases where large numbers of LSPs might liveliness is desired in cases where large numbers of LSPs might
be tested. For example, automated ingress LSR to egress LSR testing be tested. For example, automated ingress LSR to egress LSR testing
functionality is desired for some LSPs. The goal is to detect LSP functionality is desired for some LSPs. The goal is to detect LSP
problems before customers do, and this requires detection of path defects before customers do, and this requires detection of
problems in a "reasonable" amount of time. One useful definition LSP defects in a "reasonable" amount of time. One useful
of reasonable is both predictable and consistent. definition of reasonable is both predictable and consistent.
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 specifying 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 can be sent through an LSP, the use of Although ICMP-based ping [RFC792] can be sent through an LSP, the
this tool to verify the LSP path liveliness has the potential for use of this tool to verify the defect free operation of an LSP
returning erroneous results (both positive and negative). For has the potential for returning erroneous results (both positive and
example, failures may occur when negative). For example, failures may occur when
inconsistencies exist between the IP and MPLS forwarding tables, inconsistencies exist within the IP or MPLS forwarding tables,
inconsistencies in the MPLS control and data planes or problems in the MPLS control and data planes or LSP. Failures may also result
with the reply path (i.e., a reverse path does not exist). As an from defects with the reply path (i.e., a reverse path does not
example of a false positive, consider the case where the MPLS data exist) used to return a response to a test message. As an example
of a false positive, consider the case where the MPLS data
plane flows through a network node using a different output line plane flows through a network node using a different output line
card than the data plane does to each the next neighbor. Also card than the data plane uses to reach the next-hop neighbor. Also
assume that although the control plane is functional, the data assume that although the control plane is functional, the data
plane on the output line card where data traffic is programmed to plane on the output line card where data traffic is programmed to
exit the device is defective. Now, if an LSP is signaled using 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 this node, any test based solely on the control plane's view of the
world (i.e., ICMP-based) will return with a false positive result world (i.e., ICMP-based) will return with a false positive result
because although the control plane traffic at the node in the because although the control plane traffic at the node in the
example would be forwarded correctly, the actual data plane example would be forwarded correctly, the actual data plane
switching at the node in the example would misroute or drop any switching at the node in the example would misroute or drop any
traffic transmitted onto that LSP. An example of a false traffic transmitted onto that LSP. An example of a false
negative case would be when a functioning return path does not negative case would be when a functioning return path does not
exist. In this case, neither a positive nor a negative reply exist. In this case, neither a positive nor a negative reply
will be received by the sender. will be received by the sender. Therefore any detection mechanisms
that depend on receiving status via a return path SHOULD provide
multiple return options with the expectation that one of them will
not be impacted by the original defect.
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 multipath
(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
skipping to change at page 6, line 16 skipping to change at page 7, line 16
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 misbranching
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, or when trace recursive paths, such as when nested LSPs are used. This
LSPs enter and exit traffic-engineered tunnels. This path trace path trace function MUST also be capable of diagnosing LSP
function MUST also be capable of diagnosing LSP mis-merging by mis-merging by permitting comparison of expected vs. actual
permitting comparison of expected vs. actual forwarding behavior forwarding behavior at any LSR in the path. The path trace
at any LSR in the path. The path trace capability SHOULD be capability SHOULD be capable of being executed from both the
capable of being executed from both the head-end Label Switch head-end Label Switch Router (LSR) and MAY permit downstream
Router (LSR) and any mid-point LSR. Additionally, the path trace path components to be traced from an intermediate mid-point LSR.
function MUST have the ability to support equal cost multipath Additionally, the path trace function MUST have the ability to
scenarios described above in section 4.1. support equal cost multipath 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. later during subsequent testing relevant to OAM functionality.
This would include but is not limited to: This would include but is not limited to:
- consistent use of pipe or uniform TTL models by an LSR - consistent use of pipe or uniform time to live (TTL) models by
- externally visible aspects of load spreading such as an LSR [RFC3443].
ECMP, the specific algorithm(s) used, and examples of how - sufficient details that allow the test origin to
algorithm will spread traffic. excersize all path permutations related to load spreading
- data/control plane OAM capabilities of the LSR, such as (e.g. ECMP).
the ability of the data plane to reveal how it will forward
an LSP so that this may be compared with the control
plane notion of how this LSP is to be forwarded.
- stack operations performed by the LSR, such as pushes, pops, - stack operations performed by the LSR, such as pushes, pops,
and time to live (TTL) propigation 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: Level Agreements which include:
- availability - in which 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
listed below have meaning, or unavailable and other aspects listed below have meaning, or the service is unavailable and
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 qualitative
aspects of OAM probing MUST be available to specifically compute aspects of LSPs such as jitter, delay, latency and loss MUST
the latency of OAM packets generated and received at each end of a be available in order to determine whether or not the traffic for
tested LSP so as to accurately reflect the latency of data packets a specific LSP are traveling within the operator-specified
traveling along that LSP. Note that latency is a measurable tollerances.
parameter in service level specification reporting. Any method
considered SHOULD be capable of measuring the latency of an LSP Any method considered SHOULD be capable of measuring the latency
with minimal impact on network resources. of an LSP with minimal impact on network resources. See section
2.1 for definitions of the various qualitative 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. This includes the frequency of the execution of any OAM parameters insofaras to meet their specific operational
functions. The capability to synchronize OAM operations is desired requirements.
This includes the frequency of the execution of any OAM
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 misbranching or
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 the probe rate MAY result in
flapping. flapping. This can be addressed either by synchronizing the rate
or having the probes self-identify their probe rate.
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 misconfiguration can result in
churn, alarm flapping etc. churn, alarm flapping etc.
4.5 Alarm Suppression, Aggregation and Layer Coordination 4.6 Alarm Suppression, Aggregation and Layer Coordination
Devices MUST provide alarm suppression functionality that prevents Network elements MUST provide alarm suppression functionality that
the generation of superfluous generation of alarms by simply prevents the generation of superfluous generation of alarms by
discarding them (or not generating them in the first place), or by simply discarding them (or not generating them in the first place),
aggregating them together, and thereby greatly reducing the number or by aggregating them together, and thereby greatly reducing the
of notifications emitted. When viewed in conjuction with number of notifications emitted. When viewed in conjuction with
requirement 4.6 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 application using the LSP MAY have specific time constraints if the application using the LSP
independently implements path continuity testing (for example ATM independently implements path continuity testing (for example ATM
I.610 Continuity check (CC)[I610]). These constraints apply to I.610 Continuity check (CC)[I610]). These constraints apply to
LSPs that are monitored. The nature of MPLS applications allows LSPs that are monitored. The nature of MPLS applications allows
for an arbitrary hierarchy of LSPs. This introduces the for the possibility to have multiple MPLS applications attempt to
opportunity to have multiple MPLS applications attempt to respond respond to defects simultaneously. For example, layer-3 MPLS VPNs
to defects simultaneously. For example, layer-3 MPLS VPNs that that utilize Traffic Engineered tunnels, where a failure occurs on
utilize Traffic Engineered tunnels, where a failure occurs on the the LSP carrying the Traffic Engineered tunnel. This failure would
LSP carrying the Traffic Engineered tunnel. This failure would
affect he VPN traffic that uses the tunnel's LSP. Mechanisms are affect he VPN traffic that uses the tunnel's LSP. Mechanisms are
required to coordinate network response to defects. required to coordinate network response to defects.
4.6 Support for OAM Interworking for Fault Notification 4.7 Support for OAM Interworking for Fault Notification
An LSR supporting the interworking of one or more networking An LSR supporting the interworking 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
ATM VC MUST translate errors into native ATM OAM AIS cells at the ATM VC MUST translate errors into native ATM OAM Alarm Indication
termination points of the LSP. The mechanism SHOULD consider Signal (AIS) cells at the termination points of the LSP. The
possible bounded detection time parameters, e.g., a "hold off" mechanism SHOULD consider possible bounded detection time
function before reacting as to synchronize with the OAM functions. parameters, e.g., a "hold off" function before reacting as to
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.7 Error Detection and Recovery. 4.8 Error Detection and Recovery.
Recovery from a fault can be facilitated by OAM procedures. It is Recovery from a fault by a network element can be facilitated by
often desirable for such recovery to be automatic. It is a MPLS OAM procedures. These procesures will detect a broader range
requirement that faults be detected prior to customers detecting of defects than that of simple link and node failures.
Since MPLS LSPs may span multiple routing areas and service provider
domains, fault recovery and error detection should be possible
in these configuration as well as in the more simplifed
single-area/domain configurations.
Recovery from faults SHOULD be automatic. It is a requirement that
faults SHOULD be detected (and possibly corrected) by the network
operator prior to customers of the service in question detecting
them. them.
4.8 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. This is
reflected in the the integration of standard MPLS-related MIBs reflected in the the integration of standard MPLS-related MIBs
(e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and (e.g. [RFC3813][RFC3812][RFC3814]) for fault, statistics and
configuration management. These standard interfaces provide configuration management. These standard interfaces provide
operators with common programmatic interface access to operators with common programmatic interface access to
operations and management functions and their status. operations and management functions and their status.
4.9 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 plaes 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.10 Per-LSP Accounting Requirements 4.11 Per-LSP Accounting Requirements
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
skipping to change at page 9, line 31 skipping to change at page 10, line 42
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 informationr. 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
basis is a minimum level of granularity of collecting basis is a minimum level of granularity of collecting
accounting information at both of ingress and egress accounting information at both of ingress and egress
of an LSP. of an 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.10.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.
(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.
skipping to change at page 10, line 20 skipping to change at page 11, line 32
need to have a common key to distinguish each LSP. need to have a common key to distinguish each LSP.
The key MUST be unique to each LSP, and its mapping to The key 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.
For example, the LSR might use an additional label as a key,
further inspect the packet to uncover its source address,
etc...
4.10.2 Scalability 4.11.2 Scalability
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 tools designed to satisfy the requirements
skipping to change at page 11, line 22 skipping to change at page 12, line 32
[RFC3813] Srinivasan, C., Viswanathan, A. and T. [RFC3813] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management Nadeau, "MPLS Label Switch Router Management
Information Base Using SMIv2", RFC3813, June 2004. Information Base Using SMIv2", 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) FEC-To-NHLFE (FTN) Management
Information Base", RFC3814, June 2004. Information Base", RFC3814, June 2004.
[MPLS-TE] Awduche et. al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001
[FRR] Pan et.al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", Internet draft,
<draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt>,
February 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.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC792,
September 1981.
[RFC3443] Agarwal, P, Akyol, B., "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks.", RFC3443,
January 2003.
8. Authors' Addresses 8. Authors' Addresses
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
 End of changes. 

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