draft-ietf-mpls-oam-frmwk-01.txt   draft-ietf-mpls-oam-frmwk-02.txt 
Internet Draft David Allan, Editor Internet Draft David Allan, Editor
Document: draft-ietf-mpls-oam-frmwk-01.txt Nortel Networks Document: draft-ietf-mpls-oam-frmwk-02.txt Nortel Networks
Thomas D. Nadeau, Editor Thomas D. Nadeau, Editor
Cisco Systems, Inc. Cisco Systems, Inc.
Category: Informational Category: Informational
Expires: May 2005 November 2004 Expires: July 2005 January 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, 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.
skipping to change at page 1, line 44 skipping to change at page 1, line 45
Internet-Drafts as reference material or to cite them other than Internet-Drafts as reference material or to cite them other than
as "work in progress." as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a framework for how data plane OAM functions can be This document is a framework for how data plane protocols can
applied to operations and maintenance procedures. The document is be applied to operations and maintenance procedures for MPLS. The
structured to outline how OAM functionality can be used to assist in document is structured to outline how OAM functionality can be used
fault management, configuration, accounting, performance management to assist in fault management, configuration, accounting,
and security, commonly known by the acronym FCAPS. performance management and security, commonly known by the acronym
FCAPS.
Table of Contents Table of Contents
1. Introduction and Scope ........................................2 1. Introduction and Scope ........................................2
2. Terminology....................................................2 2. Terminology....................................................2
3. Fault Management...............................................2 3. Fault Management...............................................3
3.1 Fault detection...............................................2 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
3.1.2 Timeliness..................................................5 3.1.2 Timeliness..................................................5
3.2 Diagnosis.....................................................5 3.2 Diagnosis.....................................................6
3.2.1 Characterization............................................5 3.2.1 Characterization............................................6
3.2.2 Isolation...................................................5 3.2.2 Isolation...................................................6
3.3 Availability..................................................5 3.3 Availability..................................................7
4. Configuration Management.......................................5 4. Configuration Management.......................................7
5. Accounting.....................................................6 5. Accounting.....................................................7
6. Performance measurement........................................6 6. Performance measurement........................................7
7. Security.......................................................6 7. Security.......................................................8
8. Full Copyright Statement.......................................7 8. Intellectual Property Statement................................8
9. Intellectual Property Rights Notices...........................7 9. Disclaimer of Validity.........................................9
10. References.....................................................7 10. Copyright statement............................................9
11. Editors Address................................................8 11. Acknowledgements...............................................9
12. References.....................................................9
11. Editors Address...............................................10
1. Introduction and Scope 1. Introduction and Scope
This memo outlines in broader terms how data plane OAM functionality 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 can apply to the operational requirements outlined in [MPLSREQS] and can apply to the operational
functions of fault, configuration, accounting, performance and functions of fault, configuration, accounting, performance and
security (commonly known as FCAPS) for MPLS networks as defined in security (commonly known as FCAPS) for MPLS networks as defined in
[RFC3031]. The approach of the document is [RFC3031]. The approach of the document is to outline the required
to outline the required functionality, the potential mechanisms to functionality, the potential mechanisms to provide the function and
provide the function and the applicability of data plane OAM the applicability of data plane OAM functions. Included in the
functions. discussion are security issues specific to use of tools 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 RFC 2119. document are to be interpreted as described in RFC 2119.
OAM Operations and Management OAM Operations and Management
FCAPS Fault, Configuration, Administration, FCAPS Fault, Configuration, Administration,
Provisioning, and Security Provisioning, and Security
skipping to change at page 2, line 49 skipping to change at page 3, line 4
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
OAM Operations and Management OAM Operations and Management
FCAPS Fault, Configuration, Administration, FCAPS Fault, Configuration, Administration,
Provisioning, and Security Provisioning, and Security
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
Fault detection encompasses identifying all causes of failure to Fault detection encompasses identifying all causes of failure to
transfer information between the ingress and egress of an LSP. transfer information 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.
3.1.1 Enumeration and detection of types of data plane faults 3.1.1 Enumeration and detection of types of data plane faults
Physical layer faults: Lower layer faults:
Lower layer faults are those that impact the physical layer or Lower layer faults are those in the physical or virtual link
link layer that transports MPLS labeled packets between that impact the transport of MPLS labeled packets between
adjacent LSRs. Some physical links (such as SONET/SDH) may adjacent LSRs at the specific level of interest. Some physical
have link layer OAM functionality and detect and notify the links (such as SONET/SDH) may have link layer OAM functionality
LSR of link layer faults directly. Some physical links (such and detect and notify the LSR of link layer faults directly.
as Ethernet) may not have this capability and require MPLS or Some physical links (such as Ethernet) may not have this
IP layer heartbeats to detect failures. However, once detected, capability and require MPLS or IP layer heartbeats to detect
reaction to these fault notifications is often the same as failures. However, once detected, reaction to these fault
those described in the first case. notifications is often the same as those described in the first
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 misbranching: MPLS LSP misforwarding:
Misbranching occurs when there is a loss of synchronization Misforwarding 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 a 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 (ILM) condition and dropped. This is a No Incoming Label Map (ILM) condition and
can be detected directly by the downstream LSR which 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 which was corresponding ILM at the next downstream LSR, but is
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
the inconsistency between the path and the control the inconsistency between the data path and the control
plane. 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 for which MPLS is not configured. This may result in a nodes or links for which MPLS is not configured. This may
number of behaviors which are undesirable and not easily result in a number of behaviors which are undesirable and not
detected. For example, if there is only one label in the stack easily detected
of a packet's MPLS encapsulation, and the payload is IP, the - if exposed payload is not routable at the LSR resulting in
MPLS header may be removed prematurely at a node not silent discard OR
configured for MPLS forwarding on an outgoing interface. In - the exposed MPLS label was not offered by the LSR which may
this case, the MPLS header would be popped (instead of result in either silent discard or misforwarding
swapped) because there would be no outgoing label mapping due
to the outgoing line card not having MPLS enabled. At this Alternately the payload may be routable and packets
point, if the egress interface is configured for IP forwarding successfully delivered but bypasses associated MPLS
and has a routing entry that matches the packet's destination, instrumentation and tools.
the packet may still be able be successfully delivered
to the correct destination router. This scenario is not easily
detectable by the ends of the LSP since traffic is indeed
delivered.
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 ingresses and the egresses for
a FEC and will appear in the corresponding MPLS MIB performance a FEC and will appear in the corresponding MPLS MIB performance
tables in the transit LSRs as discarded packets. tables in the transit LSRs as discarded packets.
TTL Mishandling TTL Mishandling
Some Penultimate hop LSRs may consistently process TTL expiry The implementation of TTL handling is inconsistent at
and propagation at penultimate hop LSRs. In these cases, it is penultimate hop LSRs. Tools that rely on consistent TTL
possible for tools that rely on consistent processing to fail. processing may produce inconsistent results in any given
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
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 ingresses and the egresses for a FEC and will appear in the
MPLS MIB performance tables in the transit LSRs as discarded MPLS MIB performance tables in the transit LSRs as discarded
packets. packets.
skipping to change at page 5, line 18 skipping to change at page 5, line 14
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. Detection of re-ordering packets belonging to a specific flow.
mis-ordering can also be determined by sending probe traffic
along the path and verifying that all probe traffic is indeed Detection of mis-ordering can also be determined by sending
received in the order it was transmitted. probe traffic along the path and verifying that all probe
traffic is indeed received in the order it was transmitted.
This will only detect truly pathological problems as
misordering typically is an insufficiently predictable and
repeatable problem.
LSRs do not normally implement mechanisms to detect misordering LSRs do not normally implement mechanisms to detect misordering
of flows. 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 capabilites
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 hand ling using a time budget which takes into account the event hand ling 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 (i.e.: fibre cut) or due to due their catastrophic nature (e.g.: fibre cut) or due to
misplanning of the time processing budget. misplanning of the time processing budget.
^ -------------- ^ --------------
| | ^ | | ^
| | |---- 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 dignose/isolate/correct
| | v | | v
skipping to change at page 7, line 11 skipping to change at page 7, line 11
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.
MPLS has several forwarding modes (depending on the control plane MPLS has several forwarding modes (depending on the control plane
used). As such more than one model may be defined. used). As such more than one model may be defined and require more
than one measurement technique.
4. Configuration Management 4. Configuration Management
Data plane OAM can assist in configuration management by providing Data plane OAM can assist in configuration management by providing
the ability to verify the configuration of an LSP or of applications the ability to verify the configuration of an LSP or of applications
utilizing that LSP. This would be an ad-hoc data plane probe utilizing that LSP. This would be an ad-hoc data plane probe
that should both verify path integrity (a complete path exists) as that should both verify path integrity (a complete path exists) as
well as verifying that the path function is synchronized with the well as verifying that the path function is synchronized with the
control plane. The probe would carry as part of the payload relevant control plane. The probe would carry as part of the payload relevant
control plane information that the receiver would be able to compare control plane information that the receiver would be able to compare
with the local control plane configuration. with the local control plane configuration.
5. Accounting 5. Accounting
The requirements for accounting in MPLS network as specified in The requirements for accounting in MPLS networks as specified in
[MPLSREQS] do not place any requirements on data plane OAM. [MPLSREQS] do not place any requirements on data plane OAM.
6. Performance measurement 6. Performance measurement
Performance measurement permits the information transfer Performance measurement 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 7. Security
Support for intra-provider data plane OAM messaging does not Providing a secure OAM environment does require that if MPLS
introduce any new security concerns to the MPLS architecture. specific IP based tools are used, they can be filtered at the
Though it does actually address some that already exist, i.e. edge of the MPLS network. Malicious users cannot use non-MPLS
through rigorous defect handling operator's can offer their interfaces to insert MPLS specific OAM transactions, and provider
customers a greater degree of integrity protection that their initiated OAM transactions do not leak outside the MPLS cloud.
traffic will not be misdelivered (for example by being able to
detect leaking LSP traffic from a VPN). OAM messaging does address existing security concerns with the
MPLS architecture. i.e. through rigorous defect handling operator's
can offer their customers a greater degree of integrity protection
that their traffic will not be misdelivered (for example by 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 in trusted space, the provider has no control over who may not be in trusted space, the provider has no control over who may
inject traffic into the LSP which can be exploited for denial of inject traffic into the LSP which can be exploited for denial of
service attacks. This creates opportunity for malicious service attacks. OAM PDUs are not explicitly identified in the MPLS
or poorly behaved users to disrupt network operations. Attempts to header and therefore are not typically inspected by transit LSRs.
introduce filtering on target LSP OAM flows may be problematic if This creates opportunity for malicious or poorly behaved users to
flows are not visible to intermediate LSRs. However it may be disrupt network operations. Attempts to introduce filtering on
possible to interdict flows on the return path between providers (as target LSP OAM flows may be problematic if flows are not visible
faithfulness to the forwarding path is not a return path to intermediate LSRs. However it may be possible to interdict flows
requirement) to mitigate aspects of this vulnerability. on the return path between providers (as faithfulness to the
forwarding path is ot a return 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. Copyright Notice 8. Intellectual Property Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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.
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.
10. Disclaimer of Validity 9. Disclaimer of Validity
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.
11. Copyright Statement 10. Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
12. Acknowledgment 11. 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.
13. References 12. References
13.1 Normative References
13.2 Informative References
[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.
[ALLAN] Allan, D., "Guidelines for MPLS Load Balancing", [ALLAN] Allan, D., "Guidelines for MPLS Load Balancing",
draft-allan-mpls-loadbal-05.txt, IETF work in progress, draft-allan-mpls-loadbal-05.txt, IETF work in progress,
October 2003 October 2003
[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. Editors' Address 13. Editors' Address
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. 

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