The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] WG last call for draft-ietf-mpls-oam-requirements-02.txt
Hi, I have read the draft and have some comments.
* The way the draft is structured if find it a little bit difficult to find
out what are the real requirements and what is supportive text for an
requirement. I think that stating each requirement and then provide
supportive text for it would make the document easier to read an understand.
* Is all requirements at the same level of importance? You write somewhere
that "is sometimes a requirement that the customer be notified...". Would
this be an not as important requirement than for example the possibility to
track paths?
Some comments below as well. Search for @@@.
Regards
Thomas
Abstract
As transport of diverse traffic types such as voice, frame
relay, and ATM over MPLS become more common, the ability to detect,
handle and diagnose control and data plane defects becomes
critical.
Detection and specification of how to handle those defects is not
only important because such defects may not only affect the
fundamental operation of an MPLS network, but also because they
may impact SLA commitments for customers of that network.
MPLS Working Group Expires April 2004 [Page 1]
Internet Draft MPLS OAM Requirements October 2003
This Internet draft describes requirements for user and data
plane operations and management (OAM) for Multi-Protocol
Label Switching (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 [Y1710].
@@@ No refs in abstract ;)
This draft specifies OAM
requirements for MPLS, as well as for applications of MPLS such
as pseudowire voice and VPN services. Those interested in specific
issues relating to instrumenting MPLS for OAM purposes are directed
to [FRAMEWORK]
Table of Contents
Introduction.....................................................2
Terminology......................................................2
Motivations......................................................3
Requirements.....................................................4
Security Considerations..........................................8
Acknowledgments..................................................9
References.......................................................9
Authors' Addresses..............................................10
Intellectual Property Rights Notices............................11
Full Copyright Statement........................................11
1. Introduction
This Internet draft describes requirements for user and data
plane operations and management (OAM) for Multi-Protocol
Label Switching (MPLS). These requirements have been gathered
from network operators who have extensive experience deploying
MPLS networks. This draft specifies OAM requirements
for MPLS, as well as for applications of MPLS such as
pseudowire [PWE3FRAME] voice, and VPN services.
@@@ My feeling is that the last parts has not been covered very much in
this document? Should it be covered in this document at all? Of course the
demands from these services on MPLS OAM can be discussed.
No specific mechanisms are proposed to address these
requirements at this time. The goal of this draft is to
identify a commonly applicable set of requirements for MPLS
OAM. Specifically, a set of requirements that apply to
the most common set of MPLS networks deployed by service
provider organizations today. These requirements can then be used
as a base for network management tool development and to guide
the evolution of currently specified tools, as well as the
specification of OAM functions that are intrinsic to protocols
used in MPLS networks.
Comments should be made directly to the MPLS mailing list
at mpls@uu.net.
This memo does not, in its draft form, specify a standard
MPLS Working Group Expires April 2004 [Page 2]
Internet Draft MPLS OAM Requirements October 2003
for the Internet community.
2. Terminology
CE: Customer Edge
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 SLA impacts can be specified.
ECMP: Equal Cost Multipath
LSP: Label Switch Path
LSR: Label Switch Router
OAM: Operations and Management
PE: Provider Edge
PW: Pseudowire
SLA: Service Level Agreement
VCC: Virtual Channel Connection
VPC: Virtual Path Connection
3 Motivations
MPLS OAM has been tackled in numerous Internet drafts.
However all existing drafts focus on single provider
solutions or focus on a single aspect of the MPLS architecture
or application of MPLS. For example, the use 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
MPLS Working Group Expires April 2004 [Page 3]
Internet Draft MPLS OAM Requirements October 2003
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 procedure and systems in order to provide consistent
and useful OAM functionality. As MPLS matures relationships
between providers has become more complex. Furthermore, the
deployment of multiple concurrent applications of MPLS is common
place. This has led to a need to consider deployments that span
arbitrary networking arrangements and boundaries;
so that broader and more uniform applicability to the MPLS
architecture for OAM is possible.
3. Requirements
The following sections enumerate the OAM requirements
gathered from service providers. Each requirement is
further specified in detail to further clarify its
applicability.
@@@ In section 3.1, 3.2 and 3.3 should it be a requirement that is should
be possible to perform these function with regard to VPN-labels, e.g.
between two VRFs/VFIs? Maybe it is already included but it is not clear to
me anyway.
3.1 Detection of Broken Label Switch Paths
The ability to detect a broken Label Switch Path (LSP)
should not require manual hop-by-hop troubleshooting of
each LSR used to switch traffic for that LSP. For example,
it is not desirable to manually visit each LSR along the data
plane path used to transport an LSP; instead,this function
should be automated and performed from the origination of that LSP.
Furthermore, the automation of path liveliness is desired in
cases where large amounts of LSPs might be tested. For example,
automated PE-to-PE LSP testing functionality is desired.
The goal is to detect LSP problems before customers do, and
this requires detection of problems in a "reasonable" amount of
time.
One useful definition of reasonable is both predictable and
consistent.
If the time to detect defects is specified and tools designed
accordingly then a harmonized operational framework can be
established both within MPLS levels, and with MPLS applications.
If the time to detect is known, then automated responses can be
specified both w.r.t.with regard to resiliency and SLA
reporting. One consequence is that ambiguity in maintenance
procedures MUST be minimized as ambiguity in test results impacts
detection time.
Although ICMP-based ping can be sent through an LSP,
the use of this tool to verify the LSP path liveliness has the
MPLS Working Group Expires April 2004 [Page 4]
Internet Draft MPLS OAM Requirements October 2003
potential for returning erroneous results (both positive and
negative) given the nature of MPLS LSPs. For example, failures can
be may occur where inconsistencies exist between the IP and MPLS
forwarding tables, inconsistencies in the MPLS control and data
plane or problems with the reply path (i.e.: a reverse MPLS
path does not exist). Detection tools should have minimal
dependencies on network components that do not implement the LSP.
The OAM packet MUST follow exactly the customer data path in order
to reflect path liveliness used by customer data. Particular
cases of interest are forwarding mechanisms such as equal cost
multipath (ECMP) scenarios within the operator's network whereby
flows are load-shared across parallel (i.e.: equal IGP cost) paths.
Where the customer traffic may be spread over multiple paths, it
is required to be able to detect failures on any of the path
permutations. Where the spreading mechanism is payload specific,
payloads need to have forwarding that is common with the traffic
under test. Satisfying these requirements introduces complexity
into ensuring that ECMP connectivity permutations are exercised,
and that defect detection occurs in a reasonable amount of time.
[GUIDELINES] discusses some of the issues and offers suggestions
for ensuring mutual compatibility of ECMP and maintenance
functions (both detection and diagnostic).
3.2 Diagnosis of a Broken Label Switch Path
The ability to diagnose a broken LSP and to isolate the failed
resource in the path is required. This is particularly true for
misbranching defects which are particularly difficult to specify
recovery actions in an LDP network.
Experience suggests that this is best accomplished via a path
trace function that can return 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 required. The tracing capability should
include the ability to trace recursive paths, such as when nested
LSPs are used, or when LSPs enter and exit traffic-engineered
tunnels [TUNTRACE]. This path trace function must also be
capable of diagnosing LSP mis-merging by permitting comparison
of expected vs. actual forwarding behavior at any LSR in the path.
The path trace capability should be capable of being
executed from both the head end Label Switch Router (LSR) and any
mid-point LSR.
Additionally, the path trace function MUST have the ability to
support equal cost multipath scenarios as described above in
section 3.1.
@@@ Should tracing paths Inter-AS be included in the above text?
3.3 Path characterization
The ability of a path trace function to reveal details of LSR
forwarding operations relevant to OAM functionality. This would
MPLS Working Group Expires April 2004 [Page 5]
Internet Draft MPLS OAM Requirements October 2003
include but not be limited to:
- use of pipe or uniform TTL models by an LSR
- externally visible aspects of load spreading (such as
ECMP), including type of algorithm used
examples of how algorithm will spread traffic
- data/control plane OAM capabilities of the LSR
- stack operations performed by the LSR (pushes and pops)
3.4 Service Level Agreement Measurement
Mechanisms are required to measure diverse aspects of Service
Level Agreements:
- availability - in which the service is considered to be
available and the other aspects of performance measurement
listed below have meaning, or unavailable and other aspects
of performance measurement do not.
- latency - amount of time required for traffic to transit
the network
- packet loss
- jitter - measurement of latency variation
Such measurements can be made independently of the user traffic
or via a hybrid of user traffic measurement and OAM probing.
At least one mechanism is required to measure the quantity
(i.e.: number of packets) of OAM packets. In addition, the
ability to measure the qualitative aspects of OAM probing must
be available to specifically compute the latency of OAM packets
generated and received at each end of a tested LSP. Latency is
considered in this context as a measurable parameter for SLA
reporting. There is no assumption that bursts of OAM packets are
required to characterize the performance of an LSP, but it is
suggested that any method considered be capable of measuring the
latency of an LSP with minimal impact on network resources.
3.5 Frequency of OAM Execution
The operator MUST be have the flexibility to configure OAM
parameters and the frequency of the execution of any OAM
functions provided that there is some synchronization possible
of tool usage for availability metrics. The motivation for this
is to permit the network to function as a system of harmonious
OAM functions consistent across the entire network.
To elaborate, there are defect conditions (specifically
misbranching or misdirection of traffic) for probe based detection
mechanisms combined with automated network response requires
harmonization of probe insertion rates and probe handling across
the network in order to avoid flapping.
MPLS Working Group Expires April 2004 [Page 6]
Internet Draft MPLS OAM Requirements October 2003
One observation would be that commoditization of MPLS, common
optimized implementation of monitoring tools and the need for inter-
carrier harmonization of defect and SLA handling will drive
specification of OAM parameters to commonly agreed on values and
such values will have to be harmonized with the surrounding
technologies (e.g. SONET/SDH, ATM etc.) in order to be useful.
This will become particularly important as networks scale
and misconfiguration can result in churn, alarm flapping etc.
3.5 Alarm Suppression and layer coordination
Devices must provide alarm suppression functionality that
prevents the generation of superfluous generation of alarms.
When viewed in conjuction with requirement 3.6 below, this
typically requires fault notification to the LSP egress, that
may have specific time constraints if the client PW independently
implements path continuity testing (for example ATM I.610
Continuity check (CC)[I610]).
This would also be true for LSPs that have client LSPs that are
monitored. MPLS arbitrary hierarchy introduces the opportunity to
have multiple MPLS levels attempt to respond to defects
simultaneously. Mechanisms are required to coordinate network
response to defects.
3.6 Support for OAM Interworking for Fault Notification
An LSR supporting OAM functions for pseudo-wire functions that
join one or more networking technologies over MPLS must be
able to translate an MPLS defect into the native technology's
error condition. For example, errors occurring over the MPLS
transport LSP that supports an emulated ATM VC must translate
errors into native ATM OAM AIS cells at the edges of the pseudo-
wire. The mechanism SHOULD consider possible bounded detection
time parameters, e.g., a "hold off" function before reacting as
to harmonize with the client OAM. One goal would be alarm
suppression in the psuedo-wire's client layer. As observed in
section 3.5, this requires that the MPLS layer perform detection
in a bounded timeframe in order to initiate alarm suppression
prior to the psuedo-wire client layer independently detecting the
defect.
3.7 Error Detection and Recovery.
Mechanisms are needed to detect an error, react to it (ideally
in some form of automated response by the network), recover from
it and alert the network operator prior to the customer informing
MPLS Working Group Expires April 2004 [Page 7]
Internet Draft MPLS OAM Requirements October 2003
the network operator of the error condition. The ideal situation
would be where the network is resilient and can restore service
prior any significant impact on the customer perception of the
service. There are also defects that by virtue of available network
resources or topology that cannot be recovered automatically.
It is however, sometimes a requirement that the customer be
notified of the defect condition at the same time that the network
operator is made aware of the defect (as in the example of alarm
suppression for PW clients discussed above). In these situations,
the customer network may be capable of processing automated
responses based on notification of a defect condition. It is
preferred that the format of these notifications be made
consistent (i.e.: standardized) as to increase the applicability
of such messages. Depending on the device's capabilities, the
device may be programmed to take automatic corrective actions as
a result of detection of defect conditions. These actions may be
user or operator-specified, or may simply be inherent to the
underlying transport technology (i.e.: MPLS Fast-Reroute,
graceful restart or high-availability functionality).
3.8
@@@ insert a section topic here.
The commoditization of MPLS will require common information
modeling of management and control of OAM functionality. This
will be reflected in the the integration of standard MPLS-related
MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics
and configuration management. These standard interfaces
provide operators with common programmatic interface access to
operations and management functions and their status.
3.9 Detection of Denial of Service attacks as part of security
management.
@@@ I think Adrian already commented this....
3.10 Per-LSP Accounting Requirements
@@@ This chapter has a totaly different structure than the other chapters.
In an MPLS network, SPs can measure traffic from an LSR to the
egress
of the MPLS network using some MPLS related MIBs, for example.
This means that it is reasonable wish to know how much traffic is
traveling from where to where (i.e.: a traffic matrix) by analyzing
the flow of traffic.
Therefore, traffic accounting in an MPLS network can be summarized
as
the following three items.
(1) Collecting information to design network
For the purpose of optimized network design, SP offers that the
traffic information regarding among POP and/or router.
Optimizing network design needs this information.
(2) Providing high-level SLA
@@@ Monotoring/verifying SLAs
MPLS Working Group Expires April 2004 [Page 8]
Internet Draft MPLS OAM Requirements October 2003
Due to the progress of the recent [MPLS-TE] technology,
SPs and their customers may need to verify high-level SLAs. The
resource optimization and high-speed restoration by [FRR] is
being offered; therefore, continuous improvement of the service
is expected. Moreover, bandwidth guaranteed service can be
achieved by resource management based on [DS-TE].
To provide services based on these applications, the SP
needs to perform traffic accounting to monitor their
services.
(3) Inter-AS environment
SPs which offer inter-as services [Inter-AS TE][Inter-AS VPN]
require accounting of the service.
These three motivations need to satisfy the following.
- In (1) and (2), collection of information on a per-LSP basis
is a minimum level of granularity of collecting accounting
information at both of ingress and egress of an LSP.
- In (3), SP's ASBR carry out interconnection functions as an
intermediate LSR. Therefore, identifying a pair of ingress
and egress LSRs using each LSP is needed to determine the
cost of the service that a customer is using.
3.10.1 Requirements
Accounting on a per-LSP basis encompasses the following set of
functions:
(1) At an ingress LSR accounting of traffic through LSPs
beginning at each egress in question.
@@@ I really do not understand this sentence. Does this mean accounting of
traffic sent into the LSP from the ingress LSR? see also (3)
(2) At an intermediate LSR, accounting of traffic through
LSPs for each pair of ingress to egress.
(3) At egress LSR, accounting of traffic through LSPs
for each ingress.
Does this mean accounting of traffic received over the LSP at the egress LSR?
(4) All LSRs that contain LSPs that are being measuremented
need to have a common key to distinguish each LSP.
The key must be unique to each LSP, and its mapping to
LSP should be provided from whether manual or automatic
configuration.
3.10.2 Scalability
@@@ Do you say here that the requirements just described above is not
valid? I think that you could write these two together to say what you want
to say more clear.
It is not realistic to perform the just described operations by
MPLS Working Group Expires April 2004 [Page 9]
Internet Draft MPLS OAM Requirements October 2003
LSRs in a network and on all LSPs which exist in a network.
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
domain.
4. Security Considerations
LSP mis-merging has security implications beyond that of simply
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
stacking) are new to MPLS.
The performance of diagnostic functions and path characterization
involve extracting a significant amount of information about
network construction which the network operator may consider
private.
Mechanisms are required to prevent unauthorized use of either those
tools or protocol features.
|
|