draft-ietf-mpls-oam-requirements-00.txt   draft-ietf-mpls-oam-requirements-01.txt 
Network Working Group Thomas D. Nadeau Network Working Group Thomas D. Nadeau
Internet Draft Monique Morrow Internet Draft Monique Morrow
Expires: August 2003 George Swallow Expires: November 2003 George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
David Allan David Allan
Nortel Networks Nortel Networks
February 2003 June 2003
OAM Requirements for MPLS Networks OAM Requirements for MPLS Networks
draft-ietf-mpls-oam-requirements-00.txt draft-ietf-mpls-oam-requirements-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of RFC 2026 conformance with all provisions of Section 10 of RFC 2026
[RFC2026]. [RFC2026].
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working groups. Note that other groups may also distribute working
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html. accessed at http://www.ietf.org/shadow.html.
Abstract Abstract
As transport of diverse traffic types such as voice, frame As transport of diverse traffic types such as voice, frame
relay, and ATM over MPLS become more common, the ability to detect, relay, and ATM over MPLS become more common, the ability to detect,
handle and diagnose control and data plane defects becomes critical. handle and diagnose control and data plane defects becomes
critical.
Detection and specification of how to handle those defects is not Detection and specification of how to handle those defects is not
only important because such defects may not only affect the only important because such defects may not only affect the
fundamental operation of an MPLS network, but also because they fundamental operation of an MPLS network, but also because they
may impact SLA commitments for customers of that network. may impact SLA commitments for customers of that network.
This Internet draft describes requirements for user and data This Internet draft describes requirements for user and data
plane operations and management (OAM) for Multi-Protocol plane operations and management (OAM) for Multi-Protocol
Label Switching (MPLS). These requirements have been gathered Label Switching (MPLS). These requirements have been gathered
from network operators who have extensive experience deploying from network operators who have extensive experience deploying
MPLS networks, similarly some of these requirements have MPLS networks, similarly some of these requirements have
appeared in other documents [Y1710]. This draft specifies OAM appeared in other documents [Y1710]. This draft specifies OAM
requirements for MPLS, as well as for applications of MPLS such requirements for MPLS, as well as for applications of MPLS such
as pseudowire voice and VPN services. Those interested in specific as pseudowire voice and VPN services. Those interested in specific
issues relating to instrumenting MPLS for OAM purposes are directed issues relating to instrumenting MPLS for OAM purposes are directed
to [FRAMEWORK] to [FRAMEWORK]
Table of Contents Table of Contents
Introduction 2 Introduction.....................................................2
Terminology 2 Terminology......................................................2
Motivations 3 Motivations......................................................3
Requirements 4 Requirements.....................................................4
Security Considerations 8 Security Considerations..........................................8
Acknowledgments 9 Acknowledgments..................................................9
References 9 References.......................................................9
Authors' Addresses 10 Authors' Addresses..............................................10
Intellectual Property Rights Notices 11 Intellectual Property Rights Notices............................11
Full Copyright Statement 11 Full Copyright Statement........................................11
1. Introduction 1. Introduction
This Internet draft describes requirements for user and data This Internet draft describes requirements for user and data
plane operations and management (OAM) for Multi-Protocol plane operations and management (OAM) for Multi-Protocol
Label Switching (MPLS). These requirements have been gathered Label Switching (MPLS). These requirements have been gathered
from network operators who have extensive experience deploying from network operators who have extensive experience deploying
MPLS networks. This draft specifies OAM requirements MPLS networks. This draft specifies OAM requirements
for MPLS, as well as for applications of MPLS such as for MPLS, as well as for applications of MPLS such as
pseudowire [PWE3FRAME] voice, and VPN services. pseudowire [PWE3FRAME] voice, and VPN services.
skipping to change at page 3, line 34 skipping to change at page 3, line 37
LSR: Label Switch Router LSR: Label Switch Router
OAM: Operations and Management OAM: Operations and Management
PE: Provider Edge PE: Provider Edge
PW: Pseudowire PW: Pseudowire
SLA: Service Level Agreement SLA: Service Level Agreement
VCC: Virtual Circuit Channel VCC: Virtual Channel Connection
VPC: Virtual Path Connection VPC: Virtual Path Connection
3 Motivations 3 Motivations
MPLS OAM has been tackled in numerous Internet drafts. MPLS OAM has been tackled in numerous Internet drafts.
However all existing drafts focus on single provider However all existing drafts focus on single provider
solutions or focus on a single aspect of the MPLS architecture solutions or focus on a single aspect of the MPLS architecture
or application of MPLS. For example, the use of RSVP or LDP or application of MPLS. For example, the use of RSVP or LDP
signaling and defects may be covered in some deployments, signaling and defects may be covered in some deployments,
and a corresponding SNMP MIB module exists to manage this and a corresponding SNMP MIB module exists to manage this
application; however, the handling of defects and specification application; however, the handling of defects and specification
of which types of defects are interesting to operational of which types of defects are interesting to operational
networks may not have been created in concert with those for networks may not have been created in concert with those for
other applications of MPLS such as L3 VPN. This leads to other applications of MPLS such as L3 VPN. This leads to
inconsistent and inefficient applicability across the MPLS inconsistent and inefficient applicability across the MPLS
architecture, and/or requires significant modifications to architecture, and/or requires significant modifications to
operational procedure and systems in order to provide consistent operational procedure and systems in order to provide consistent
and useful OAM functionality. As MPLS matures relationships and useful OAM functionality. As MPLS matures relationships
between providers has become more complex. Furthermore, the between providers has become more complex. Furthermore, the
deployment of multiple concurrent applications deployment of multiple concurrent applications of MPLS is common
of MPLS is commonplace. This has led to a need to consider place. This has led to a need to consider deployments that span
deployments that span arbitrary networking arrangements and arbitrary networking arrangements and boundaries;
boundaries so that broader and more uniform applicability so that broader and more uniform applicability to the MPLS
to the MPLS architecture for OAM is possible. architecture for OAM is possible.
3. Requirements 3. Requirements
The following sections enumerate the OAM requirements The following sections enumerate the OAM requirements
gathered from service providers. Each requirement is gathered from service providers. Each requirement is
further specified in detail to further clarify its further specified in detail to further clarify its
applicability. applicability.
3.1 Detection of Broken Label Switch Paths 3.1 Detection of Broken Label Switch Paths
The ability to detect a broken Label Switch Path (LSP) The ability to detect a broken Label Switch Path (LSP)
should not require manual hop-by-hop troubleshooting of should not require manual hop-by-hop troubleshooting of
each LSR used to switch traffic for that LSP. For example, each LSR used to switch traffic for that LSP. For example,
it is not desirable to manually visit each LSR it is not desirable to manually visit each LSR along the data
along the data plane path used to transport an LSP; instead, plane path used to transport an LSP; instead,this function
this function should be automated and performed from the should be automated and performed from the origination of that LSP.
origination of that LSP. Furthermore, the automation of Furthermore, the automation of path liveliness is desired in
path liveliness is desired in cases where large amounts of cases where large amounts of LSPs might be tested. For example,
LSPs might be tested. For example, automated PE-to-PE automated PE-to-PE LSP testing functionality is desired.
LSP testing functionality is desired. The goal is to detect LSP The goal is to detect LSP problems before customers do, and
problems before customers do, and this requires detection of this requires detection of problems in a "reasonable" amount of
problems in a "reasonable" amount of time. One useful definition time.
of reasonable is both predictable and consistent. If the time to
detect defects is specified and tools designed accordingly then One useful definition of reasonable is both predictable and
a harmonized operational framework can be established both consistent.
within MPLS levels, and with MPLS applications. If the time to
detect is known, then automated responses can be 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 specified both w.r.t.with regard to resiliency and SLA
reporting. One consequence is that ambiguity in maintenance reporting. One consequence is that ambiguity in maintenance
procedures MUST be minimized as ambiguity in test results impacts procedures MUST be minimized as ambiguity in test results impacts
detection time. detection time.
Although ICMP-based ping can be sent through an LSP, the use of Although ICMP-based ping can be sent through an LSP,
this tool to verify the LSP path liveliness has the potential the use of this tool to verify the LSP path liveliness has the
for returning erroneous results (both positive and negative) potential for returning erroneous results (both positive and
given the nature of MPLS LSPs. For example, failures can be negative) given the nature of MPLS LSPs. For example, failures can
may occur where inconsistencies exist between the IP and MPLS be may occur where inconsistencies exist between the IP and MPLS
forwarding tables, inconsistencies in the MPLS control and data forwarding tables, inconsistencies in the MPLS control and data
plane or problems with the reply path (i.e.: a reverse MPLS plane or problems with the reply path (i.e.: a reverse MPLS
path does not exist). Detection tools should have minimal path does not exist). Detection tools should have minimal
dependencies on network components that do not implement the LSP. dependencies on network components that do not implement the LSP.
Furthermore, the path liveliness function The OAM packet MUST follow exactly the customer data path in order
MUST have the ability to support equal cost multipath to reflect path liveliness used by customer data. Particular
(ECMP) scenarios within the operator's network. Specifically, cases of interest are forwarding mechanisms such as equal cost
the ability to detect failures on any parallel (i.e.: equal multipath (ECMP) scenarios within the operator's network whereby
IGP cost) paths used to load share traffic in order to more flows are load-shared across parallel (i.e.: equal IGP cost) paths.
efficiently use the network. It is common to base the algorithm Where the customer traffic may be spread over multiple paths, it
of how to load share traffic by examining certain fields within is required to be able to detect failures on any of the path
the packet header. Unfortunately, there is no standard for this permutations. Where the spreading mechanism is payload specific,
algorithm, but it is important that any function be capable payloads need to have forwarding that is common with the traffic
of detecting failures on all operational paths as failure of under test. Satisfying these requirements introduces complexity
any branch may lead to loss of traffic, regardless of load sharing into ensuring that ECMP connectivity permutations are exercised,
algorithm. This introduces complexity into ensuring that ECMP and that defect detection occurs in a reasonable amount of time.
connectivity permutations are exercised, and that defect [GUIDELINES] discusses some of the issues and offers suggestions
detection occurs in a reasonable amount of time. [GUIDELINES] for ensuring mutual compatibility of ECMP and maintenance
discusses some of the issues and offers suggestions for ensuring functions (both detection and diagnostic).
mutual compatibility of ECMP and maintenance functions (both
detection and diagnostic).
3.2 Diagnosis of a Broken Label Switch Path 3.2 Diagnosis of a Broken Label Switch Path
The ability to diagnose a broken LSP and to isolate the failed The ability to diagnose a broken LSP and to isolate the failed
resource in the path is required. This is particularly true for resource in the path is required. This is particularly true for
misbranching defects which are particularly difficult to specify misbranching defects which are particularly difficult to specify
recovery actions in an LDP network. recovery actions in an LDP network.
Experience suggests that this is best accomplished via a path Experience suggests that this is best accomplished via a path
trace function that can return the entire list of LSRs and links 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 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 location of the defect) is required. The tracing capability should
include the ability to trace recursive paths, such as when nested include the ability to trace recursive paths, such as when nested
LSPs are used, or when LSPs enter and exit traffic-engineered LSPs are used, or when LSPs enter and exit traffic-engineered
tunnels [TUNTRACE]. This path trace function must also be tunnels [TUNTRACE]. This path trace function must also be
capable of diagnosing LSP mis-merging by permitting comparison capable of diagnosing LSP mis-merging by permitting comparison
of expected vs. actual forwarding behavior at any LSR in the path. of expected vs. actual forwarding behavior at any LSR in the path.
The path trace capability should be capable of being The path trace capability should be capable of being
executed from both the head end Label Switch Router (LSR) and any executed from both the head end Label Switch Router (LSR) and any
mid-point LSR. Additionally, the path trace function MUST have mid-point LSR.
the ability to support equal cost multipath scenarios as described Additionally, the path trace function MUST have the ability to
above in section 3.1. support equal cost multipath scenarios as described above in
section 3.1.
3.3 Path characterization 3.3 Path characterization
The ability of a path trace function to reveal details of LSR The ability of a path trace function to reveal details of LSR
forwarding operations relevant to OAM functionality. This would forwarding operations relevant to OAM functionality. This would
include but not be limited to: include but not be limited to:
- use of pipe or uniform TTL models by an LSR - use of pipe or uniform TTL models by an LSR
- externally visible aspects of load spreading (such as - externally visible aspects of load spreading (such as
ECMP), including ECMP), including type of algorithm used
type of algorithm used
examples of how algorithm will spread traffic examples of how algorithm will spread traffic
- data/control plane OAM capabilities of the LSR - data/control plane OAM capabilities of the LSR
- stack operations performed by the LSR (pushes and pops) - stack operations performed by the LSR (pushes and pops)
3.4 Service Level Agreement Measurement 3.4 Service Level Agreement Measurement
Mechanisms are required to measure diverse aspects of Service Mechanisms are required to measure diverse aspects of Service
Level Agreements: Level Agreements:
- availability - in which the service is considered to be - availability - in which the service is considered to be
available and the other aspects of performance measurement available and the other aspects of performance measurement
listed below have meaning, or unavailable and other aspects listed below have meaning, or unavailable and other aspects
of performance measurement do not. of performance measurement do not.
- latency - amount of time required for traffic to transit - latency - amount of time required for traffic to transit
the network the network
- packet loss - packet loss
- jitter - measurement of latency variation - jitter - measurement of latency variation
Such measurements can be made independently of the user traffic Such measurements can be made independently of the user traffic
or via a hybrid of user traffic measurement and OAM probing. or via a hybrid of user traffic measurement and OAM probing.
At least one mechanism At least one mechanism is required to measure the quantity
is required to measure the quantity
(i.e.: number of packets) of OAM packets. In addition, the (i.e.: number of packets) of OAM packets. In addition, the
ability to measure the qualitative aspects of OAM probing must ability to measure the qualitative aspects of OAM probing must
be available to specifically compute the latency of OAM packets be available to specifically compute the latency of OAM packets
generated and received at each end of a tested LSP. Latency is generated and received at each end of a tested LSP. Latency is
considered in this context as a measurable parameter for SLA reporting. considered in this context as a measurable parameter for SLA
There is no assumption that bursts of OAM packets are required to reporting. There is no assumption that bursts of OAM packets are
characterize the performance of an LSP, but it is suggested that any required to characterize the performance of an LSP, but it is
method considered be capable of measuring the latency of an LSP with suggested that any method considered be capable of measuring the
minimal impact on network resources. latency of an LSP with minimal impact on network resources.
3.5 Frequency of OAM Execution 3.5 Frequency of OAM Execution
The operator MUST be have the flexibility to configure OAM The operator MUST be have the flexibility to configure OAM
parameters and the frequency of the execution of any OAM parameters and the frequency of the execution of any OAM
functions provided that there is some synchronization possible functions provided that there is some synchronization possible
of tool usage for availability metrics. The motivation for this of tool usage for availability metrics. The motivation for this
is to permit the network to function as a system of harmonious is to permit the network to function as a system of harmonious
OAM functions consistent across the entire network. OAM functions consistent across the entire network.
skipping to change at page 7, line 22 skipping to change at page 7, line 22
Devices must provide alarm suppression functionality that Devices must provide alarm suppression functionality that
prevents the generation of superfluous generation of alarms. prevents the generation of superfluous generation of alarms.
When viewed in conjuction with requirement 3.6 below, this When viewed in conjuction with requirement 3.6 below, this
typically requires fault notification to the LSP egress, that typically requires fault notification to the LSP egress, that
may have specific time constraints if the client PW independently may have specific time constraints if the client PW independently
implements path continuity testing (for example ATM I.610 implements path continuity testing (for example ATM I.610
Continuity check (CC)[I610]). Continuity check (CC)[I610]).
This would also be true for LSPs that have client LSPs that are This would also be true for LSPs that have client LSPs that are
monitored. MPLS arbitrary hierarchy introduces the opportunity to have monitored. MPLS arbitrary hierarchy introduces the opportunity to
multiple MPLS levels attempt to respond to defects simultaneously. have multiple MPLS levels attempt to respond to defects
Mechanisms are required to coordinate network response to defects. simultaneously. Mechanisms are required to coordinate network
response to defects.
3.6 Support for OAM Interworking for Fault Notification 3.6 Support for OAM Interworking for Fault Notification
An LSR supporting OAM functions for pseudo-wire functions that An LSR supporting OAM functions for pseudo-wire functions that
join one or more networking technologies over MPLS must be join one or more networking technologies over MPLS must be
able to translate an MPLS defect into the native technology's able to translate an MPLS defect into the native technology's
error condition. For example, errors occurring over the MPLS error condition. For example, errors occurring over the MPLS
transport LSP that supports an emulated ATM VC must translate transport LSP that supports an emulated ATM VC must translate
errors into native ATM OAM AIS cells at the edges of the pseudo- errors into native ATM OAM AIS cells at the edges of the pseudo-
wire. The mechanism SHOULD consider possible bounded detection wire. The mechanism SHOULD consider possible bounded detection
time parameters, e.g., a "hold off" function before reacting as time parameters, e.g., a "hold off" function before reacting as
to harmonize with the client OAM. One goal would be alarm suppression to harmonize with the client OAM. One goal would be alarm
in the psuedo-wire's client layer. As observed in 3.5, this requires suppression in the psuedo-wire's client layer. As observed in
that the MPLS layer perform detection in a bounded timeframe in section 3.5, this requires that the MPLS layer perform detection
order to initiate alarm suppression prior to the psuedo-wire in a bounded timeframe in order to initiate alarm suppression
client layer independently detecting the defect. prior to the psuedo-wire client layer independently detecting the
defect.
3.7 Error Detection and Recovery. 3.7 Error Detection and Recovery.
Mechanisms are needed to detect an error, react to it (ideally Mechanisms are needed to detect an error, react to it (ideally
in some form of automated response by the network), recover from in some form of automated response by the network), recover from
it and alert the network operator prior to the customer informing it and alert the network operator prior to the customer informing
the network operator of the error condition. The ideal situation the network operator of the error condition. The ideal situation
would be where the network is resilient and can restore service would be where the network is resilient and can restore service
prior any significant impact on the customer perception of the prior any significant impact on the customer perception of the
service. There are also defects that by virtue of available network service. There are also defects that by virtue of available network
resources or topology that cannot be recovered automatically. resources or topology that cannot be recovered automatically.
It is however, sometimes a requirement that the customer be It is however, sometimes a requirement that the customer be
notified of the defect condition at the same time that the network 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 operator is made aware of the defect (as in the example of alarm
suppression for PW clients discussed above). In these situations, suppression for PW clients discussed above). In these situations,
the customer network may be capable of processing automated responses the customer network may be capable of processing automated
based on notification of a defect condition. It is preferred responses based on notification of a defect condition. It is
that the format of these notifications be made consistent (i.e.: preferred that the format of these notifications be made
standardized) as to increase the applicability of such messages. consistent (i.e.: standardized) as to increase the applicability
Depending on the device's capabilities, the device may be programmed of such messages. Depending on the device's capabilities, the
to take automatic corrective actions as a result of detection of device may be programmed to take automatic corrective actions as
defect conditions. These actions may be user or operator-specified, a result of detection of defect conditions. These actions may be
or may simply be inherent to the underlying transport technology user or operator-specified, or may simply be inherent to the
(i.e.: MPLS Fast-Reroute, graceful restart or high-availability underlying transport technology (i.e.: MPLS Fast-Reroute,
functionality). graceful restart or high-availability functionality).
3.8 The commoditization of MPLS will require common information 3.8 The commoditization of MPLS will require common information
modeling of management and control of OAM functionality. This modeling of management and control of OAM functionality. This
will be reflected in the the integration of standard MPLS-related will be reflected in the the integration of standard MPLS-related
MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics MIBs (e.g. [LSRMIB][TEMIB][LBMIB][FTNMIB]) for fault, statistics
and configuration management. These standard interfaces and configuration management. These standard interfaces
provide operators with common programmatic interface access to provide operators with common programmatic interface access to
operations and management functions and their status. operations and management functions and their status.
3.9 Detection of Denial of Service attacks as part of security 3.9 Detection of Denial of Service attacks as part of security
skipping to change at page 8, line 40 skipping to change at page 8, line 42
4. Security Considerations 4. Security Considerations
LSP mis-merging has security implications beyond that of simply LSP mis-merging has security implications beyond that of simply
being a network defect. LSP mis-merging can happen due to a number 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 of potential sources of failure, some of which (due to MPLS label
stacking) are new to MPLS. stacking) are new to MPLS.
The performance of diagnostic functions and path characterization The performance of diagnostic functions and path characterization
involve extracting a significant amount of information about involve extracting a significant amount of information about
network construction which the network operator may consider private. network construction which the network operator may consider
private.
Mechanisms are required to prevent unauthorized use of either those Mechanisms are required to prevent unauthorized use of either those
tools or protocol features. tools or protocol features.
5. Acknowledgments 5. Acknowledgments
The authors wish to acknowledge and thank the following The authors wish to acknowledge and thank the following
individuals for their valuable comments to this document: individuals for their valuable comments to this document:
Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr.
Ikejiri, NTT Communications and Mr.Kumaki of KDDI. Ikejiri, NTT Communications and Mr.Kumaki of KDDI.
Hari Rakotoranto, Cisco Systems; Danny McPherson from TCB.
Hari Rakotoranto, Cisco Systems; Luyuan Fang, AT&T;
Danny McPherson, TCB.
6. References 6. References
[TUNTRACE] Bonica, R., Kompella, K., Meyer, D., [TUNTRACE] Bonica, R., Kompella, K., Meyer, D.,
"Tracing Requirements for Generic Tunnels", "Tracing Requirements for Generic Tunnels",
Internet Draft <draft-bonica-tunneltrace- Internet Draft <draft-bonica-tunneltrace-
02.txt>, November 2001. 02.txt>, November 2001.
[LSRMIB] Srinivasan, C., Viswanathan, A. and T. [LSRMIB] Srinivasan, C., Viswanathan, A. and T.
Nadeau, "MPLS Label Switch Router Management Nadeau, "MPLS Label Switch Router Management
skipping to change at page 10, line 14 skipping to change at page 10, line 17
[I610] ITU-T Recommendation I.610, "B-ISDN operations and [I610] ITU-T Recommendation I.610, "B-ISDN operations and
maintenance principles and functions", February 1999 maintenance principles and functions", February 1999
[FRAMEWORK] Allan et.al. "A Framework for MPLS OAM", Internet [FRAMEWORK] Allan et.al. "A Framework for MPLS OAM", Internet
draft <draft-allan-mpls-oam-frmwk-04.txt>, February 2003 draft <draft-allan-mpls-oam-frmwk-04.txt>, February 2003
7. Authors' Addresses 7. Authors' Addresses
Thomas D. Nadeau Thomas D. Nadeau
Cisco Systems, Inc. Cisco Systems, Inc.
300 Apollo Drive 300 Beaver Brook Road
Chelmsford, MA 01824 Boxboro, MA 01719
Phone: 978-244-3051 Phone: +1-978-936-1470
Email: tnadeau@cisco.com Email: tnadeau@cisco.com
Monique Jeanne Morrow Monique Jeanne Morrow
Cisco Systems, Inc. Cisco Systems, Inc.
Glatt-Com, 2nd Floor Glatt-Com, 2nd Floor
CH-8301 CH-8301
Switzerland Switzerland
Voice: (0)1 878-9412 Voice: (0)1 878-9412
EMail: mmorrow@cisco.com Email: mmorrow@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
250 Apollo Drive 300 Beaver Brook Road
Chelmsford, MA 01824 Boxboro, MA 01719
Voice: 978 244 8143 Voice: +1-978-936-1398
Email: swallow@cisco.com Email: swallow@cisco.com
David Allan David Allan
Nortel Networks Nortel Networks
3500 Carling Ave. 3500 Carling Ave.
Voice: 1-613-763-6362
Ottawa, Ontario, CANADA Ottawa, Ontario, CANADA
Voice: 1-613-763-6362
Email: dallan@nortelnetworks.com Email: dallan@nortelnetworks.com
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Copyright (C) The Internet Society (2001). All Rights
Reserved. Reserved.
This document and translations of it may be copied and This document and translations of it may be copied and
furnished to others, and derivative works that comment on furnished to others, and derivative works that comment on
or otherwise explain it or assist in its implementation may or otherwise explain it or assist in its implementation may
skipping to change at page 11, line 34 skipping to change at page 11, line 37
9. Intellectual Property Rights Notices 9. Intellectual Property Rights Notices
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 or other rights that might be claimed to intellectual property 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; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made to of licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can proprietary rights by implementers or users of this specification
be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
 End of changes. 

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