draft-ietf-mpls-oam-frmwk-03.txt   draft-ietf-mpls-oam-frmwk-04.txt 
Internet Draft David Allan, Editor Internet Draft David Allan, Editor
Document: draft-ietf-mpls-oam-frmwk-03.txt Nortel Networks Document: draft-ietf-mpls-oam-frmwk-04.txt Nortel Networks
Thomas D. Nadeau, Editor Thomas D. Nadeau, Editor
Cisco Systems, Inc. Cisco Systems, Inc.
Category: Informational Category: Informational
Expires: August 2005 February 2005 Expires: May 2006 November 2005
A Framework for MPLS Operations A Framework for MPLS Operations
and Management (OAM) and Management (OAM)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, each author represents that
patent or other IPR claims of which we are aware have been disclosed, any applicable patent or other IPR claims of which he or she is
or will be disclosed, and any of which we become aware will be aware have been or will be disclosed, and any of which he or she
disclosed, in accordance with RFC 3668. becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
This document is an Internet-Draft and is subject to all
provisions of section 3 of RFC 3667. By submitting this
Internet-Draft, each author represents that any applicable patent
or other IPR claims of which he or she is aware have been or will
be disclosed, and any of which he or she become aware will be
disclosed, in accordance with RFC 3668.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other than Internet-Drafts as reference material or to cite them other than
skipping to change at page 3, line 4 skipping to change at page 2, line 54
2. Terminology 2. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
OAM Operations and Management OAM Operations and Management
FCAPS Fault management, Configuration management, FCAPS Fault management, Configuration management,
Administration management, Provisioning Administration management, Provisioning
management, and Security management management, and Security management
FEC Forwarding Equivalence Class
ILM Incoming Label Map ILM Incoming Label Map
NHLFE Next Hop Label Forwarding Entry NHLFE Next Hop Label Forwarding Entry
MIB Management Information Base MIB Management Information Base
LSR Label Switching Router LSR Label Switching Router
RTT Round Trip Time RTT Round Trip Time
3. Fault Management 3. Fault Management
3.1 Fault detection 3.1 Fault detection
skipping to change at page 4, line 7 skipping to change at page 4, line 7
configuration problems. configuration problems.
It will manifest itself in one of two forms: It will manifest itself in one of two forms:
- packets belonging to a particular LSP are cross-connected - packets belonging to a particular LSP are cross-connected
into an NHLFE for which there is no corresponding ILM at into an NHLFE for which there is no corresponding ILM at
the next downstream LSR. This can occur in cases where the the next downstream LSR. This can occur in cases where the
NHLFE entry is corrupted. Therefore the packet arrives at NHLFE entry is corrupted. Therefore the packet arrives at
the next LSR with a top label value for which the LSR has no the next LSR with a top label value for which the LSR has no
corresponding forwarding information, and is typically corresponding forwarding information, and is typically
dropped. This is a No Incoming Label Map (No ILM) condition and dropped. This is a No Incoming Label Map (No ILM) condition
can be detected directly by the downstream LSR which and can be detected directly by the downstream LSR which
receives the incorrectly labeled packet. receives the incorrectly labeled packet.
- packets belonging to a particular LSP are cross-connected - packets belonging to a particular LSP are cross-connected
into an incorrect NHLFE entry for which there is a into an incorrect NHLFE entry for which there is a
corresponding ILM at the next downstream LSR, but is corresponding ILM at the next downstream LSR, but is
associated with a different LSP. This may be detected by associated with a different LSP. This may be detected by
a number of means: a number of means:
o some or all of the misdirected traffic is not routable o some or all of the misdirected traffic is not routable
at the egress node. at the egress node.
o Or OAM probing is able to detect the fault by detecting o Or OAM probing is able to detect the fault by detecting
skipping to change at page 5, line 22 skipping to change at page 5, line 22
network. Load sharing typically takes place when equal cost network. Load sharing typically takes place when equal cost
paths exist between the ingress and egress of an LSP. In these paths exist between the ingress and egress of an LSP. In these
cases, traffic is split among these equal cost paths using a cases, traffic is split among these equal cost paths using a
variety of algorithms. One such algorithm relies on splitting variety of algorithms. One such algorithm relies on splitting
traffic between each path on a per-packet basis. When this is traffic between each path on a per-packet basis. When this is
done, it is possible for some packets along the path to be done, it is possible for some packets along the path to be
delayed due to congestion or slower links, which may result in delayed due to congestion or slower links, which may result in
packets being received out of order at the egress. Detection packets being received out of order at the egress. Detection
and remedy of this situation may be left up to client and remedy of this situation may be left up to client
applications that use the LSPs. For instance, TCP is capable of applications that use the LSPs. For instance, TCP is capable of
re-ordering packets belonging to a specific flow. re-ordering packets belonging to a specific flow (although this
may result in re-transmission of some of the misordered
packets).
Detection of mis-ordering can also be determined by sending Detection of mis-ordering can also be determined by sending
probe traffic along the path and verifying that all probe probe traffic along the path and verifying that all probe
traffic is indeed received in the order it was transmitted. traffic is indeed received in the order it was transmitted.
This will only detect truly pathological problems as This will only detect truly pathological problems as
misordering typically is an insufficiently predictable and misordering typically is an insufficiently predictable and
repeatable problem. repeatable problem.
LSRs do not normally implement mechanisms to detect misordering LSRs do not normally implement mechanisms to detect misordering
of flows. of flows.
skipping to change at page 8, line 12 skipping to change at page 8, line 12
To measure information loss, a common practice is to periodically To measure information loss, a common practice is to periodically
read ingress and egress counters (i.e.: MIB module counters). This read ingress and egress counters (i.e.: MIB module counters). This
information may also be used for offline correlation. Another common information may also be used for offline correlation. Another common
practice is to send explicit probe traffic which traverses the data practice is to send explicit probe traffic which traverses the data
plane path in question. This probe traffic can also be used to plane path in question. This probe traffic can also be used to
measure jitter and delay. measure jitter and delay.
7. Security Management 7. Security Management
Providing a secure OAM environment does require that if MPLS Providing a secure OAM environment is required if MPLS specific
specific IP based tools are used, they can be filtered at the network mechanisms are to be used successfully. To this end,
edge of the MPLS network. Malicious users cannot use non-MPLS operators have a number of options when deploying network mechanisms
interfaces to insert MPLS specific OAM transactions, and provider including simply filtering OAM messages at the edge of the MPLS
initiated OAM transactions do not leak outside the MPLS cloud. network. Malicious users should not be able to use non-MPLS
interfaces to insert MPLS specific OAM transactions. Provider
initiated OAM transactions should be able to be blocked from leaking
outside the MPLS cloud.
OAM messaging does address existing security concerns with the Finally, if a provider does wish to allow OAM messages to flow into
(or through) their networks, for example, in a multi-provider
deployment, authentication and authorization is required to prevent
malicious and/or unauthorized access. Also, given that MPLS networks
often run IP simultaneously, similar requirements apply to any
native IP OAM network mechanisms in use. Therefore, authentication
and authorization for OAM technologies is something that MUST be
considered when designing network mechanism which satisfy the
requirements presented in this document.
OAM messaging can address some existing security concerns with the
MPLS architecture. i.e. through rigorous defect handling operator's MPLS architecture. i.e. through rigorous defect handling operator's
can offer their customers a greater degree of integrity protection can offer their customers a greater degree of integrity protection
that their traffic will not be misdelivered (for example by being that their traffic will not be misdelivered (for example by being
able to detect leaking LSP traffic from a VPN). able to detect leaking LSP traffic from a VPN).
Support for inter-provider data plane OAM messaging introduces a Support for inter-provider data plane OAM messaging introduces a
number of security concerns as by definition, portions of LSPs will number of security concerns as by definition, portions of LSPs will
not be in trusted space, the provider has no control over who may not be within a single provider's network, the provider has no
inject traffic into the LSP which can be exploited for denial of control over who may inject traffic into the LSP which can be
service attacks. OAM PDUs are not explicitly identified in the MPLS exploited for denial of service attacks. OAM PDUs are not
header and therefore are not typically inspected by transit LSRs. explicitly identified in the MPLS header and therefore are not
This creates opportunity for malicious or poorly behaved users to typically inspected by transit LSRs. This creates opportunity for
disrupt network operations. Attempts to introduce filtering on malicious or poorly behaved users to disrupt network operations.
target LSP OAM flows may be problematic if flows are not visible Attempts to introduce filtering on target LSP OAM flows may be
to intermediate LSRs. However it may be possible to interdict flows problematic if flows are not visible to intermediate LSRs. However
on the return path between providers (as faithfulness to the it may be possible to interdict flows on the return path between
forwarding path is ot a return path requirement) to mitigate providers (as faithfulness to the forwarding path is ot a return
aspects of this vulnerability. path requirement) to mitigate aspects of this vulnerability.
OAM tools may permit unauthorized or malicious users to extract OAM tools may permit unauthorized or malicious users to extract
significant amounts of information about network configuration. This significant amounts of information about network configuration. This
would be especially true of IP based tools as in many network would be especially true of IP based tools as in many network
configurations, MPLS does not typically extend to untrusted hosts, configurations, MPLS does not typically extend to untrusted hosts,
but IP does. For example, TTL hiding at ingress and egress LSRs will but IP does. For example, TTL hiding at ingress and egress LSRs will
prevent external users from using TTL-based mechanisms to probe an prevent external users from using TTL-based mechanisms to probe an
operator's network. This suggests that tools used for problem operator's network. This suggests that tools used for problem
diagnosis or which by design are capable of extracting significant diagnosis or which by design are capable of extracting significant
amounts of information will require authentication and authorization amounts of information will require authentication and authorization
skipping to change at page 9, line 48 skipping to change at page 10, line 9
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Copyright Statement 12. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
13. Acknowledgment 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.13. Acknowledgment
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 editors would like to thank Monique Morrow from Cisco Systems, The editors would like to thank Monique Morrow from Cisco Systems,
and Harmen van Der Linde from AT&T for their valuable review comments and Harmen van Der Linde from AT&T for their valuable review comments
on this document. on this document.
14. References 14. References
 End of changes. 12 change blocks. 
38 lines changed or deleted 47 lines changed or added

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