draft-ietf-mpls-oam-frmwk-04.txt   draft-ietf-mpls-oam-frmwk-05.txt 
Internet Draft David Allan, Editor Internet Draft David Allan, Editor
Document: draft-ietf-mpls-oam-frmwk-04.txt Nortel Networks Document: draft-ietf-mpls-oam-frmwk-05.txt Nortel Networks
Thomas D. Nadeau, Editor Thomas D. Nadeau, Editor
Cisco Systems, Inc. Cisco Systems, Inc.
Category: Informational Category: Informational
Expires: May 2006 November 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
skipping to change at page 2, line 11 skipping to change at page 2, line 4
outline how Operations and Management functionality can be used to outline how Operations and Management functionality can be used to
assist in fault management, configuration, accounting, performance assist in fault management, configuration, accounting, performance
management and security, commonly known by the acronym FCAPS. management and security, commonly known by the acronym FCAPS.
Table of Contents Table of Contents
1. Introduction ...................................................2 1. Introduction ...................................................2
2. Terminology.....................................................2 2. Terminology.....................................................2
3. Fault Management................................................3 3. Fault Management................................................3
3.1 Fault detection...............................................3 3.1 Fault detection...............................................3
3.1.1 Enumeration and detection of types of data plane faults.....3 3.1.1 Enumeration and detection of types of data plane faults.....3
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
3.1.2 Timeliness..................................................5 3.1.2 Timeliness..................................................5
3.2 Diagnosis.....................................................6 3.2 Diagnosis.....................................................6
3.2.1 Characterization............................................6 3.2.1 Characterization............................................6
3.2.2 Isolation...................................................6 3.2.2 Isolation...................................................6
3.3 Availability..................................................7 3.3 Availability..................................................7
4. Configuration Management.......................................7 4. Configuration Management.......................................7
5. Accounting Management..........................................7 5. Accounting Management..........................................7
6. Performance Management.........................................7 6. Performance Management.........................................7
7. Security Management............................................8 7. Security Management............................................8
8. IANA Considerations ...........................................8 8. IANA Considerations ...........................................8
9. Security Considerations .......................................8 9. Security Considerations .......................................8
10. Intellectual Property Statement................................8 10. Intellectual Property Statement................................8
11. Disclaimer of Validity.........................................9 11. Copyright statement............................................9
12. Copyright statement............................................9 12. Acknowledgments ...............................................9
13. Acknowledgements...............................................9 13. References.....................................................9
14. References.....................................................9 13.1 Normative References ..........................................9
14.1 Normative References ..........................................9 13.2 Informative References ........................................9
14.2 Informative References ........................................9 14. Authors' Address..............................................10
15. Authors' Address..............................................10
1. Introduction 1. Introduction
This memo outlines in broader terms how data plane protocols This memo outlines in broader terms how data plane protocols
can assist in meeting the operations and management (OAM) can assist in meeting the operations and management (OAM)
requirements outlined in [MPLSREQS] and [Y1710] and can apply to requirements outlined in [MPLSREQS] and [Y1710] and can apply to
the management functions of fault, configuration, accounting, the management functions of fault, configuration, accounting,
performance and security (commonly known as FCAPS) for MPLS networks performance and security (commonly known as FCAPS) for MPLS networks
as defined in [RFC3031]. The approach of the document is to outline as defined in [RFC3031]. The approach of the document is to outline
functionality, the potential mechanisms to provide the function and functionality, the potential mechanisms to provide the function and
the required the applicability of data plane OAM functions. Included the required applicability of data plane OAM functions. Included
in the discussion are security issues specific to use of tools in the discussion are security issues specific to use of tools
within a provider domain and use for inter provider LSPs. within a provider domain and use for inter provider LSPs.
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, Performance
management, and Security management management, and Security management
FEC Forwarding Equivalence Class 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
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
RTT Round Trip Time RTT Round Trip Time
3. Fault Management 3. Fault Management
3.1 Fault detection 3.1 Fault detection
Fault detection encompasses the identification of all data Fault detection encompasses the identification of all data
plane failures between the ingress and egress of an LSP. plane failures between the ingress and egress of an LSP.
This section will enumerate common failure scenarios and This section will enumerate common failure scenarios and
explain how one might (or might not) detect the situation. explain how one might (or might not) detect the situation.
skipping to change at page 3, line 42 skipping to change at page 3, line 40
case. case.
Node failures: Node failures:
Node failures are those that impact the forwarding capability Node failures are those that impact the forwarding capability
of a node component, including its entire set of links. This of a node component, including its entire set of links. This
can be due to component failure, power outage, or reset of can be due to component failure, power outage, or reset of
control processor in an LSR employing a distributed control processor in an LSR employing a distributed
architecture, etc. architecture, etc.
MPLS LSP misforwarding: MPLS LSP mis-forwarding:
Misforwarding occurs when there is a loss of synchronization Mis-forwarding occurs when there is a loss of synchronization
between the data and the control planes in one or more nodes. between the data and the control planes in one or more nodes.
This can occur due to hardware failure, software failure or This can occur due to hardware failure, software failure or
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
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
corresponding forwarding information, and is typically corresponding forwarding information, and is typically
dropped. This is a No Incoming Label Map (No ILM) condition dropped. This is a No Incoming Label Map (No ILM) condition
and 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:
skipping to change at page 4, line 30 skipping to change at page 4, line 30
plane state. plane state.
Discontinuities in the MPLS Encapsulation Discontinuities in the MPLS Encapsulation
The forwarding path of the FEC carried by an LSP may transit The forwarding path of the FEC carried by an LSP may transit
nodes or links for which MPLS is not configured. This may nodes or links for which MPLS is not configured. This may
result in a number of behaviors which are undesirable and not result in a number of behaviors which are undesirable and not
easily detected easily detected
- if exposed payload is not routable at the LSR resulting in - if exposed payload is not routable at the LSR resulting in
silent discard OR silent discard OR
- the exposed MPLS label was not offered by the LSR which may - the exposed MPLS label was not offered by the LSR which may
result in either silent discard or misforwarding result in either silent discard or mis-forwarding
Alternately the payload may be routable and packets Alternately the payload may be routable and packets
successfully delivered but bypasses associated MPLS successfully delivered but bypasses associated MPLS
instrumentation and tools. instrumentation and tools.
MTU problems MTU problems
MTU problems occur when client traffic cannot be fragmented by MTU problems occur when client traffic cannot be fragmented by
intermediate LSRs, and is dropped somewhere along the path of intermediate LSRs, and is dropped somewhere along the path of
the LSP. MTU problems should appear as a discrepancy in the the LSP. MTU problems should appear as a discrepancy in the
traffic count between the set of ingresses and the egresses for traffic count between the set of ingress LSRs and the egress
a FEC and will appear in the corresponding MPLS MIB performance LSRs for a FEC and will appear in the corresponding MPLS MIB
tables in the transit LSRs as discarded packets. performance tables in the transit LSRs as discarded packets.
TTL Mishandling TTL Mishandling
The implementation of TTL handling is inconsistent at The implementation of TTL handling is inconsistent at
penultimate hop LSRs. Tools that rely on consistent TTL penultimate hop LSRs. Tools that rely on consistent TTL
processing may produce inconsistent results in any given processing may produce inconsistent results in any given
network. network.
Congestion Congestion
Congestion occurs when the offered load on any interface Congestion occurs when the offered load on any interface
exceeds the link capacity for sufficient time that the exceeds the link capacity for sufficient time that the
interface buffering is exhausted. Congestion problems will interface buffering is exhausted. Congestion problems will
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
appear as a discrepancy in the traffic count between the set of appear as a discrepancy in the traffic count between the set of
ingresses and the egresses for a FEC and will appear in the ingress LSRs and the egress LSRs for a FEC and will appear in
MPLS MIB performance tables in the transit LSRs as discarded the MPLS MIB performance tables in the transit LSRs as
packets. discarded packets.
Misordering Mis-ordering
Misordering of LSP traffic occurs when incorrect or Mis-ordering of LSP traffic occurs when incorrect or
inappropriate load sharing is implemented within an MPLS inappropriate load sharing is implemented within an MPLS
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 (although this re-ordering packets belonging to a specific flow (although this
may result in re-transmission of some of the misordered may result in re-transmission of some of the mis-ordered
packets). 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 mis-ordering 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
of flows. mis-ordering of flows.
Payload Corruption Payload Corruption
Payload corruption may occur and be undetectable by LSRs. Such Payload corruption may occur and be undetectable by LSRs. Such
errors are typically detected by client payload integrity errors are typically detected by client payload integrity
mechanisms. mechanisms.
3.1.2 Timeliness 3.1.2 Timeliness
The design of SLAs and management support systems requires that The design of SLAs and management support systems requires that
ample headroom be alloted in terms of their processing capabilites ample headroom be alloted in terms of their processing capabilities
in order to process and handle all necessary fault conditions in order to process and handle all necessary fault conditions
within the bounds stipulated in the SLA. This includes planning for within the bounds stipulated in the SLA. This includes planning for
event handling using a time budget which takes into account the event handling using a time budget which takes into account the
over-all SLA and time to address any defects which arise. However, over-all SLA and time to address any defects which arise. However,
it is possible that some fault conditions may surpass this budget it is possible that some fault conditions may surpass this budget
due their catastrophic nature (e.g.: fibre cut) or due to due their catastrophic nature (e.g.: fibre cut) or due to
misplanning of the time processing budget. incorrect planning of the time processing budget.
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
^ -------------- ^ --------------
| | ^ | | ^
| | |---- Time to notify NOC + process/correct | | |---- Time to notify NOC + process/correct
SLA | | v defect SLA | | v defect
Max - | ------------- Max - | -------------
Time | | ^ Time | | ^
| | |----- Time to dignose/isolate/correct | | |----- Time to diagnose/isolate/correct
| | v | | v
v ------------- v -------------
Figure 1: Fault Correction Budget Figure 1: Fault Correction Budget
In figure 1, we represent the overall fault correction time budget In figure 1, we represent the overall fault correction time budget
by the maximum time as specified in an SLA for the service in by the maximum time as specified in an SLA for the service in
question. This time is then divided into two subsections, the first question. This time is then divided into two subsections, the first
encompassing the total time required to detect a fault and notify an encompassing the total time required to detect a fault and notify an
operator (or optionally automatically correct the defect). This operator (or optionally automatically correct the defect). This
section may have an explicit maximum time to detect defects arising section may have an explicit maximum time to detect defects arising
from either the application or a need to do alarm management (i.e.: from either the application or a need to do alarm management (i.e.:
supression) and this will be reflected in the frequency of OAM suppression) and this will be reflected in the frequency of OAM
execution. The second section indicates the time required to notify execution. The second section indicates the time required to notify
the operational systems used to diagnose, isolate and correct the the operational systems used to diagnose, isolate and correct the
defect (if they cannot be corrected automatically). defect (if they cannot be corrected automatically).
3.2 Diagnosis 3.2 Diagnosis
3.2.1 Characterization 3.2.1 Characterization
Characterization is defined as determining the forwarding path of a Characterization is defined as determining the forwarding path of a
packet (which may not be necessarily known). Characterization may be packet (which may not be necessarily known). Characterization may be
skipping to change at page 6, line 52 skipping to change at page 7, line 4
Isolation of a fault can occur in two forms. In the first case, the Isolation of a fault can occur in two forms. In the first case, the
local failure is detected, and the node where the failure occurred local failure is detected, and the node where the failure occurred
is capable of issuing an alarm for such an event. The node should is capable of issuing an alarm for such an event. The node should
attempt to withdraw the defective resources and/or rectify the attempt to withdraw the defective resources and/or rectify the
situation prior to raising an alarm. Active data plane OAM situation prior to raising an alarm. Active data plane OAM
mechanisms may also detect the failure conditions remotely and issue mechanisms may also detect the failure conditions remotely and issue
their own alarms if the situation is not rectified quickly enough. their own alarms if the situation is not rectified quickly enough.
In the second case, the fault has not been detected locally. In this In the second case, the fault has not been detected locally. In this
case, the local node cannot raise an alarm, nor can it be expected case, the local node cannot raise an alarm, nor can it be expected
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
to rectify the situation. In this case, the failure may be detected to rectify the situation. In this case, the failure may be detected
remotely via data plane OAM. This mechanism should also be able to remotely via data plane OAM. This mechanism should also be able to
determine the location of the fault, perhaps on the basis of limited determine the location of the fault, perhaps on the basis of limited
information such as a customer complaint. This mechanism may also be information such as a customer complaint. This mechanism may also be
able to automatically remove the defective resources from and the able to automatically remove the defective resources from the
network and restore service, but should at least provide a network network and restore service, but should at least provide a network
operator with enough information by which they can perform this operator with enough information by which they can perform this
operation. Given that detection of faults is desired to happen as operation. Given that detection of faults is desired to happen as
quickly as possible, tools which posses the ability to incrementally quickly as possible, tools which posses the ability to incrementally
test LSP health should be used to uncover faults. test LSP health should be used to uncover faults.
3.3 Availability 3.3 Availability
Availability is the measure of the percentage of time that a service Availability is the measure of the percentage of time that a service
is operating within specification, often specified by an SLA. is operating within specification, often specified by an SLA.
skipping to change at page 7, line 45 skipping to change at page 7, line 51
6. Performance Management 6. Performance Management
Performance management permits the information transfer Performance management permits the information transfer
characteristics of LSPs to be measured, perhaps in order to characteristics of LSPs to be measured, perhaps in order to
compare against an SLA. This falls into two categories, latency compare against an SLA. This falls into two categories, latency
(where jitter is considered a variation in latency) and information (where jitter is considered a variation in latency) and information
loss. loss.
Latency can be measured in two ways: one is to have precisely Latency can be measured in two ways: one is to have precisely
synchronized clocks at the ingress and egress such that timestamps synchronized clocks at the ingress and egress such that time-stamps
in PDUs flowing from the ingress to the egress can be compared. The in PDUs flowing from the ingress to the egress can be compared. The
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
other is to use an exchange of PING type PDUs that gives a round other is to use an exchange of PING type PDUs that gives a round
trip time (RTT) measurement, and an estimate of the one way latency trip time (RTT) measurement, and an estimate of the one way latency
can be inferred with some loss of precision. Use of load spreading can be inferred with some loss of precision. Use of load spreading
techniques such as ECMP mean that any individual RTT measurement is techniques such as ECMP mean that any individual RTT measurement is
only representative of the typical RTT for a FEC. only representative of the typical RTT for a FEC.
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
skipping to change at page 8, line 28 skipping to change at page 8, line 37
initiated OAM transactions should be able to be blocked from leaking initiated OAM transactions should be able to be blocked from leaking
outside the MPLS cloud. outside the MPLS cloud.
Finally, if a provider does wish to allow OAM messages to flow into Finally, if a provider does wish to allow OAM messages to flow into
(or through) their networks, for example, in a multi-provider (or through) their networks, for example, in a multi-provider
deployment, authentication and authorization is required to prevent deployment, authentication and authorization is required to prevent
malicious and/or unauthorized access. Also, given that MPLS networks malicious and/or unauthorized access. Also, given that MPLS networks
often run IP simultaneously, similar requirements apply to any often run IP simultaneously, similar requirements apply to any
native IP OAM network mechanisms in use. Therefore, authentication native IP OAM network mechanisms in use. Therefore, authentication
and authorization for OAM technologies is something that MUST be and authorization for OAM technologies is something that MUST be
considered when designing network mechanism which satisfy the considered when designing network mechanisms which satisfy the
requirements presented in this document. framework presented in this document.
OAM messaging can address some existing security concerns with the 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 incorrectly delivered (for example by
able to detect leaking LSP traffic from a VPN). being 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 within a single provider's network, the provider has no not be within a single provider's network, the provider has no
control over who may inject traffic into the LSP which can be control over who may inject traffic into the LSP which can be
exploited for denial of service attacks. OAM PDUs are not exploited for denial of service attacks. OAM PDUs are not
explicitly identified in the MPLS header and therefore are not explicitly identified in the MPLS header and therefore are not
typically inspected by transit LSRs. This creates opportunity for typically inspected by transit LSRs. This creates opportunity for
malicious or poorly behaved users to disrupt network operations. malicious or poorly behaved users to disrupt network operations.
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
Attempts to introduce filtering on target LSP OAM flows may be Attempts to introduce filtering on target LSP OAM flows may be
problematic if flows are not visible to intermediate LSRs. However problematic if flows are not visible to intermediate LSRs. However
it may be possible to interdict flows on the return path between it may be possible to interdict flows on the return path between
providers (as faithfulness to the forwarding path is ot a return providers (as faithfulness to the forwarding path is to a return
path requirement) to mitigate 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
of the originator. This may impact the scalability of such tools of the originator. This may impact the scalability of such tools
when employed for monitoring instead of diagnosis. when employed for monitoring instead of diagnosis.
8. IANA Considerations 8. IANA Considerations
This document does not contain any IANA considerations. This document does not contain any IANA considerations.
9. Security Considerations 9. Security Considerations
This draft describes a framework for MPLS Operations and Management. This document describes a framework for MPLS Operations and
Although this document discusses and addresses some security Management. Although this document discusses and addresses some
concerns in section 7 above, it does not introduce any new security concerns in section 7 above, it does not introduce any
security concerns. new security concerns.
10. Intellectual Property Statement 10. 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
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
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 this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
11. Disclaimer of Validity 11. Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an 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. Acknowledgments
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.13. Acknowledgment
Funding for the RFC Editor function is currently provided by the
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 13. References
14.1 Normative References 13.1 Normative References
[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC "Multiprotocol Label Switching Architecture", RFC
3031, January 2001. 3031, January 2001.
[MPLSREQS] Nadeau et.al., "OAM Requirements for MPLS Networks", [MPLSREQS] Nadeau et.al., "OAM Requirements for MPLS Networks",
draft-ietf-mpls-oam-requirements-05.txt, November 2004 draft-ietf-mpls-oam-requirements-05.txt, November 2004
[Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM [Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM
Functionality for MPLS Networks" Functionality for MPLS Networks"
14.1 Informative References 13.2 Informative References
draft-ietf-mpls-oam-frmwk-05 December 6, 2005
15. Authors' Addresses 14. Authors' Addresses
David Allan David Allan
Nortel Networks Phone: +1-613-763-6362 Nortel Networks Phone: +1-613-763-6362
3500 Carling Ave. Email: dallan@nortelnetworks.com 3500 Carling Ave. Email: dallan@nortelnetworks.com
Ottawa, Ontario, CANADA Ottawa, Ontario, CANADA
Thomas D. Nadeau Thomas D. Nadeau
Cisco Systems Phone: +1-978-936-1470 Cisco Systems Phone: +1-978-936-1470
300 Beaver Brook Drive Email: tnadeau@cisco.com 300 Beaver Brook Drive Email: tnadeau@cisco.com
Boxborough, MA 01824 Boxborough, MA 01824
 End of changes. 37 change blocks. 
55 lines changed or deleted 71 lines changed or added

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