doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc4377.txt b/doc/rfc/rfc4377.txt
new file mode 100644
index 0000000..b1e9156
--- /dev/null
+++ b/doc/rfc/rfc4377.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                          T. Nadeau
+Request for Comments: 4377                                     M. Morrow
+Category: Informational                                       G. Swallow
+                                                     Cisco Systems, Inc.
+                                                                D. Allan
+                                                         Nortel Networks
+                                                           S. Matsushima
+                                                           Japan Telecom
+                                                           February 2006
+
+
+             Operations and Management (OAM) Requirements
+           for Multi-Protocol Label Switched (MPLS) Networks
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies Operations and Management (OAM) requirements
+   for Multi-Protocol Label Switching (MPLS), as well as for
+   applications of MPLS, such as pseudo-wire voice and virtual private
+   network services.  These requirements have been gathered from network
+   operators who have extensive experience deploying MPLS networks.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Document Conventions ............................................2
+   3. Motivations .....................................................4
+   4. Requirements ....................................................4
+   5. Security Considerations ........................................11
+   6. References .....................................................12
+   7. Acknowledgements ...............................................13
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 1]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+1.  Introduction
+
+   This document describes requirements for user and data plane
+   Operations and Management (OAM) for Multi-Protocol Label Switching
+   (MPLS).  These requirements have been gathered from network operators
+   who have extensive experience deploying MPLS networks.  This document
+   specifies OAM requirements for MPLS, as well as for applications of
+   MPLS.
+
+   Currently, there are no specific mechanisms proposed to address these
+   requirements.  The goal of this document is to identify a commonly
+   applicable set of requirements for MPLS OAM at this time.
+   Specifically, a set of requirements that apply to the most common set
+   of MPLS networks deployed by service provider organizations at the
+   time this document was written.  These requirements can then be used
+   as a base for network management tool development and to guide the
+   evolution of currently specified tools, as well as the specification
+   of OAM functions that are intrinsic to protocols used in MPLS
+   networks.
+
+2.  Document Conventions
+
+2.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   Queuing/buffering Latency: The delay caused by packet queuing (value
+                              is variable since it is dependent on the
+                              packet arrival rate, the packet length,
+                              and the link throughput).
+
+   Probe-based-detection:     Active measurement tool that can measure
+                              the consistency of an LSP [RFC4379].
+
+   Defect:                    Any error condition that prevents a Label
+                              Switched Path (LSP) from functioning
+                              correctly.  For example, loss of an
+                              Interior Gateway Protocol (IGP) path will
+                              most likely result in an LSP not being
+                              able to deliver traffic to its
+                              destination.  Another example is the
+                              interruption of the path for a TE tunnel.
+                              These may be due to physical circuit
+                              failures or failure of switching nodes to
+                              operate as expected.
+
+
+
+
+Nadeau, et al.               Informational                      [Page 2]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+                              Multi-vendor/multi-provider network
+                              operation typically requires agreed upon
+                              definitions of defects (when it is broken
+                              and when it is not) such that both
+                              recovery procedures and service level
+                              specification impact can be specified.
+
+   Head-end Label Switching
+   Router (LSR):              The beginning of an LSP.  A head-end LSR
+                              is also referred to as an ingress LSR.
+
+   Tail-end Label Switching
+   Router (LSR):              The end of an LSP.  A tail-end LSR is also
+                              referred to as an egress LSR.
+
+   Propagation Latency:       The delay added by the propagation of the
+                              packet through the link (fixed value that
+                              depends on the distance of the link and
+                              the propagation speed).
+
+   Transmission Latency:      The delay added by the transmission of the
+                              packet over the link, i.e., the time it
+                              takes to put the packet over the media
+                              (value that depends on the link throughput
+                              and packet length).
+
+   Processing Latency:        The delay added by all the operations
+                              related to the switching of labeled
+                              packets (value is node implementation
+                              specific and may be considered fixed and
+                              constant for a given type of equipment).
+
+   Node Latency:              The delay added by the network element
+                              resulting from of the sum of the
+                              transmission, processing, and
+                              queuing/buffering latency.
+
+   One-hop Delay:             The fixed delay experienced by a packet to
+                              reach the next hop resulting from the of
+                              the propagation latency, the transmission
+                              latency, and the processing latency.
+
+   Minimum Path Latency:      The sum of the one-hop delays experienced
+                              by the packet when traveling from the
+                              ingress to the egress LSR.
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 3]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+   Variable Path Latency:     The variation in the sum of the delays
+                              experienced by packets transiting the
+                              path, otherwise know as jitter.
+
+2.2.  Acronyms
+
+   ASBR: Autonomous System Border Router
+
+   CE: Customer Edge
+
+   PE: Provider Edge
+
+   SP: Service Provider
+
+   ECMP: Equal-Cost Multi-path
+
+   LSP: Label Switched Path
+
+   LSP Ping: Label Switched Path Ping
+
+   LSR: Label Switching Router
+
+   OAM: Operations and Management
+
+   RSVP: Resource reSerVation Protocol
+
+   LDP: Label Distribution Protocol
+
+   DoS: Denial of Service
+
+3.  Motivations
+
+   This document was created to provide requirements that could be used
+   to create consistent and useful OAM functionality that meets
+   operational requirements of those service providers (SPs) who have
+   deployed or are deploying MPLS.
+
+4.  Requirements
+
+   The following sections enumerate the OAM requirements gathered from
+   service providers who have deployed MPLS and services based on MPLS
+   networks.  Each requirement is specified in detail to clarify its
+   applicability.  Although the requirements specified herein are
+   defined by the IETF, they have been made consistent with requirements
+   gathered by other standards bodies such as the ITU [Y1710].
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 4]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.1.  Detection of Label Switched Path Defects
+
+   The ability to detect defects in a broken LSP MUST not require manual
+   hop-by-hop troubleshooting of each LSR used to switch traffic for
+   that LSP.  For example, it is not desirable to manually visit each
+   LSR along the data plane path transited by an LSP; instead, this
+   function MUST be automated and able to be performed at some operator
+   specified frequency from the origination point of that LSP.  This
+   implies solutions that are interoperable to allow for such automatic
+   operation.
+
+   Furthermore, the automation of path liveliness is desired in cases
+   where large numbers of LSPs might be tested.  For example, automated
+   ingress LSR to egress LSR testing functionality is desired for some
+   LSPs.  The goal is to detect LSP path defects before customers do,
+   which requires detection and correction of LSP defects in a manner
+   that is both predictable and within the constraints of the service
+   level agreement under which the service is being offered.  Simply
+   put, the sum of the time it takes an OAM tool to detect a defect and
+   the time needed for an operational support system to react to this
+   defect, by possibly correcting it or notifying the customer, must
+   fall within the bounds of the service level agreement in question.
+
+   Synchronization of detection time bounds by tools used to detect
+   broken LSPs is required.  Failure to specify defect detection time
+   bounds may result in an ambiguity in test results.  If the time to
+   detect broken LSPs is known, then automated responses can be
+   specified with respect and regard to resiliency and service level
+   specification reporting.  Further, if synchronization of detection
+   time bounds is possible, an operational framework can be established
+   to guide the design and specification of MPLS applications.
+
+   Although an ICMP-based ping [RFC792] can be sent through an LSP as an
+   IP payload, the use of this tool to verify the defect-free operation
+   of an LSP has the potential of returning erroneous results (both
+   positive and negative) for a number of reasons.  For example, in some
+   cases, because the ICMP traffic is based on legally addressable IP
+   addressing, it is possible for ICMP messages that are originally
+   transmitted inside of an LSP to "fall out of the LSP" at some point
+   along the path.  In these cases, since ICMP packets are routable, a
+   falsely positive response may be returned.  In other cases, where the
+   data plane of a specific LSP needs to be tested, it is difficult to
+   guarantee that traffic based on an ICMP ping header is parsed and
+   hashed to the same equal-cost multi-paths (ECMP) as the data traffic.
+
+   Any detection mechanisms that depend on receiving the status via a
+   return path SHOULD provide multiple return options with the
+   expectation that one of them will not be impacted by the original
+
+
+
+Nadeau, et al.               Informational                      [Page 5]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+   defect.  An example of a case where a false negative might occur
+   would be a mechanism that requires a functional MPLS return path.
+   Since MPLS LSPs are unidirectional, it is possible that although the
+   forward LSP, which is the LSP under test, might be functioning, the
+   response from the destination LSR might be lost, thus giving the
+   source LSR the false impression that the forward LSP is defective.
+   However, if an alternate return path could be specified -- say IP for
+   example -- then the source could specify this as the return path to
+   the destination, and in this case, would receive a response
+   indicating that the return LSP is defective.
+
+   The OAM packet MUST follow the customer data path exactly in order to
+   reflect path liveliness used by customer data.  Particular cases of
+   interest are forwarding mechanisms, such as ECMP scenarios within the
+   operator's network, whereby flows are load-shared across parallel
+   paths (i.e., equal IGP cost).  Where the customer traffic may be
+   spread over multiple paths, the ability to detect failures on any of
+   the path permutations is required.  Where the spreading mechanism is
+   payload specific, payloads need to have forwarding that is common
+   with the traffic under test.  Satisfying these requirements
+   introduces complexity into ensuring that ECMP connectivity
+   permutations are exercised and that defect detection occurs in a
+   reasonable amount of time.
+
+4.2.  Diagnosis of a Broken Label Switched Path
+
+   The ability to diagnose a broken LSP and to isolate the failed
+   component (i.e., link or node) in the path is required.  For example,
+   note that specifying recovery actions for mis-branching defects in an
+   LDP network is a particularly difficult case.  Diagnosis of defects
+   and isolation of the failed component is best accomplished via a path
+   trace function that can return the entire list of LSRs and links used
+   by a certain LSP (or at least the set of LSRs/links up to the
+   location of the defect).  The tracing capability SHOULD include the
+   ability to trace recursive paths, such as when nested LSPs are used.
+   This path trace function MUST also be capable of diagnosing LSP mis-
+   merging by permitting comparison of expected vs. actual forwarding
+   behavior at any LSR in the path.  The path trace capability SHOULD be
+   capable of being executed from the head-end Label Switching Router
+   (LSR) and may permit downstream path components to be traced from an
+   intermediate mid-point LSR.  Additionally, the path trace function
+   MUST have the ability to support ECMP scenarios described in Section
+   4.1.
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 6]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.3.  Path Characterization
+
+   The path characterization function is the ability to reveal details
+   of LSR forwarding operations.  These details can then be compared
+   during subsequent testing relevant to OAM functionality.  This
+   includes but is not limited to:
+
+      -  consistent use of pipe or uniform time to live (TTL) models by
+         an LSR [RFC3443].
+
+      -  sufficient details that allow the test origin to exercise all
+         path permutations related to load spreading (e.g., ECMP).
+
+      -  stack operations performed by the LSR, such as pushes, pops,
+         and TTL propagation at penultimate hop LSRs.
+
+4.4.  Service Level Agreement Measurement
+
+   Mechanisms are required to measure the diverse aspects of Service
+   Level Agreements, which include:
+
+      -  latency - amount of time required for traffic to transit the
+         network
+
+      -  packet loss
+
+      -  jitter - measurement of latency variation
+
+      -  defect free forwarding - the service is considered to be
+         available, or the service is unavailable and other aspects of
+         performance measurement do not have meaning.
+
+   Such measurements can be made independently of the user traffic or
+   via a hybrid of user traffic measurement and OAM probing.
+
+   At least one mechanism is required to measure the number of OAM
+   packets.  In addition, the ability to measure the quantitative
+   aspects of LSPs, such as jitter, delay, latency, and loss, MUST be
+   available in order to determine whether the traffic for a specific
+   LSP is traveling within the operator-specified tolerances.
+
+   Any method considered SHOULD be capable of measuring the latency of
+   an LSP with minimal impact on network resources.  See Section 2.1 for
+   definitions of the various quantitative aspects of LSPs.
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 7]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.5.  Frequency of OAM Execution
+
+   The operator MUST have the flexibility to configure OAM parameters to
+   meet their specific operational requirements.
+
+   This includes the frequency of the execution of any OAM functions.
+   The ability to synchronize OAM operations is required to permit a
+   consistent measurement of service level agreements.  To elaborate,
+   there are defect conditions, such as mis-branching or misdirection of
+   traffic, for which probe-based detection mechanisms that incur
+   significant mismatches in their detection frequency may result in
+   flapping.  This can be addressed either by synchronizing the rate or
+   having the probes self-identify their probe rate.  For example, when
+   the probing mechanisms are bootstrapping, they might negotiate and
+   ultimately agree on a probing rate, therefore providing a consistent
+   probing frequency and avoiding the aforementioned problems.
+
+   One observation would be that wide-spread deployment of MPLS, common
+   implementation of monitoring tools, and the need for inter-carrier
+   synchronization of defect and service level specification handling
+   will drive specification of OAM parameters to commonly agreed on
+   values.  Such values will have to be harmonized with the surrounding
+   technologies (e.g., SONET/SDH, ATM) to be useful.  This will become
+   particularly important as networks scale and mis-configuration can
+   result in churn, alarm flapping, etc.
+
+4.6.  Alarm Suppression, Aggregation, and Layer Coordination
+
+   Network elements MUST provide alarm suppression functionality that
+   prevents the generation of a superfluous generation of alarms by
+   simply discarding them (or not generating them in the first place),
+   or by aggregating them together, thereby greatly reducing the number
+   of notifications emitted.  When viewed in conjunction with the
+   requirement in Section 4.7 below, this typically requires fault
+   notification to the LSP egress that may have specific time
+   constraints if the application using the LSP independently implements
+   path continuity testing (for example, ATM I.610 Continuity check
+   (CC)[I610]).  These constraints apply to LSPs that are monitored.
+   The nature of MPLS applications allows for the possibility of having
+   multiple MPLS applications attempt to respond to defects
+   simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic
+   Engineered tunnels where a failure occurs on the LSP carrying the
+   Traffic Engineered tunnel.  This failure would affect the VPN traffic
+   that uses the tunnel's LSP.  Mechanisms are required to coordinate
+   network responses to defects.
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 8]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.7.  Support for OAM Inter-working for Fault Notification
+
+   An LSR supporting the inter-working of one or more networking
+   technologies over MPLS MUST be able to translate an MPLS defect into
+   the native technology's error condition.  For example, errors
+   occurring over an MPLS transport LSP that supports an emulated ATM VC
+   MUST translate errors into native ATM OAM Alarm Indication Signal
+   (AIS) cells at the termination points of the LSP.  The mechanism
+   SHOULD consider possible bounded detection time parameters, e.g., a
+   "hold off" function before reacting to synchronize with the OAM
+   functions.
+
+   One goal would be alarm suppression by the upper layer using the LSP.
+   As observed in Section 4.5, this requires that MPLS perform detection
+   in a bounded timeframe in order to initiate alarm suppression prior
+   to the upper layer independently detecting the defect.
+
+4.8.  Error Detection and Recovery
+
+   Recovery from a fault by a network element can be facilitated by MPLS
+   OAM procedures.  These procedures will detect a broader range of
+   defects than that of simple link and node failures.  Since MPLS LSPs
+   may span multiple routing areas and service provider domains, fault
+   recovery and error detection should be possible in these
+   configurations as well as in the more simplified single-area/domain
+   configurations.
+
+   Recovery from faults SHOULD be automatic.  It is a requirement that
+   faults SHOULD be detected (and possibly corrected) by the network
+   operator prior to customers of the service in question detecting
+   them.
+
+4.9.  Standard Management Interfaces
+
+   The wide-spread deployment of MPLS requires common information
+   modeling of management and control of OAM functionality.  Evidence of
+   this is reflected in the standard IETF MPLS-related MIB modules
+   (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and
+   configuration management.  These standard interfaces provide
+   operators with common programmatic interface access to Operations and
+   Management functions and their statuses.  However, gaps in coverage
+   of MIB modules to OAM and other features exist; therefore, MIB
+   modules corresponding to new protocol functions or network tools are
+   required.
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                      [Page 9]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.10.  Detection of Denial of Service Attacks
+
+   The ability to detect denial of service (DoS) attacks against the
+   data or control planes MUST be part of any security management
+   related to MPLS OAM tools or techniques.
+
+4.11.  Per-LSP Accounting Requirements
+
+   In an MPLS network, service providers can measure traffic from an LSR
+   to the egress of the network using some MPLS related MIBs, for
+   example.  This means that it is reasonable to know how much traffic
+   is traveling from location to location (i.e., a traffic matrix) by
+   analyzing the flow of traffic.  Therefore, traffic accounting in an
+   MPLS network can be summarized as the following three items:
+
+      (1) Collecting information to design network
+
+          For the purpose of optimized network design, a service
+          provider may offer the traffic information.  Optimizing
+          network design needs this information.
+
+      (2) Providing a Service Level Specification
+
+          Providers and their customers MAY need to verify high-level
+          service level specifications, either to continuously optimize
+          their networks, or to offer guaranteed bandwidth services.
+          Therefore, traffic accounting to monitor MPLS applications is
+          required.
+
+      (3) Inter-AS environment
+
+          Service providers that offer inter-AS services require
+          accounting of those services.
+
+      These three motivations need to satisfy the following:
+
+          -  In (1) and (2), collection of information on a per-LSP
+             basis is a minimum level of granularity for collecting
+             accounting information at both of ingress and egress of an
+             LSP.
+
+          -  In (3), SP's ASBR carry out interconnection functions as an
+             intermediate LSR.  Therefore, identifying a pair of ingress
+             and egress LSRs using each LSP is needed to determine the
+             cost of the service that a customer is using.
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 10]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+4.11.1.  Requirements
+
+   Accounting on a per-LSP basis encompasses the following set of
+   functions:
+
+      (1) At an ingress LSR, accounting of traffic through LSPs that
+          begin at each egress in question.
+
+      (2) At an intermediate LSR, accounting of traffic through LSPs for
+          each pair of ingress to egress.
+
+      (3) At egress LSR, accounting of traffic through LSPs for each
+          ingress.
+
+      (4) All LSRs containing LSPs that are being measured need to have
+          a common identifier to distinguish each LSP.  The identifier
+          MUST be unique to each LSP, and its mapping to LSP SHOULD be
+          provided whether from manual or automatic configuration.
+
+      In the case of non-merged LSPs, this can be achieved by simply
+      reading traffic counters for the label stack associated with the
+      LSP at any LSR along its path.  However, in order to measure
+      merged LSPs, an LSR MUST have a means to distinguish the source of
+      each flow so as to disambiguate the statistics.
+
+4.11.2.  Location of Accounting
+
+   It is not realistic for LSRs to perform the described operations on
+   all LSPs that exist in a network.  At a minimum, per-LSP based
+   accounting SHOULD be performed on the edges of the network -- at the
+   edges of both LSPs and the MPLS domain.
+
+5.  Security Considerations
+
+   Provisions to any of the network mechanisms designed to satisfy the
+   requirements described herein are required to prevent their
+   unauthorized use.  Likewise, these network mechanisms MUST provide a
+   means by which an operator can prevent denial of service attacks if
+   those network mechanisms are used in such an attack.
+
+   LSP mis-merging has security implications beyond that of simply being
+   a network defect.  LSP mis-merging can happen due to a number of
+   potential sources of failure, some of which (due to MPLS label
+   stacking) are new to MPLS.
+
+   The performance of diagnostic functions and path characterization
+   involve extracting a significant amount of information about network
+   construction that the network operator MAY consider private.
+
+
+
+Nadeau, et al.               Informational                     [Page 11]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+6.2.  Informative References
+
+   [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
+             Label Switched (MPLS) Data Plane Failures", RFC 4379,
+             February 2006.
+
+   [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+             "Multiprotocol Label Switching (MPLS) Traffic Engineering
+             (TE) Management Information Base (MIB)", RFC 3812, June
+             2004.
+
+   [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
+             "Multiprotocol Label Switching (MPLS) Label Switching
+             Router (LSR) Management Information Base (MIB)", RFC 3813,
+             June 2004.
+
+   [RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
+             "Multiprotocol Label Switching (MPLS) Forwarding
+             Equivalence Class To Next Hop Label Forwarding Entry
+             (FEC-To-NHLFE) Management Information Base (MIB)", RFC
+             3814, June 2004.
+
+   [Y1710]   ITU-T Recommendation Y.1710, "Requirements for OAM
+             Functionality In MPLS Networks"
+
+   [I610]    ITU-T Recommendation I.610, "B-ISDN operations and
+             maintenance principles and functions", February 1999
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [RFC792]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
+             792, September 1981.
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 12]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+   [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
+             Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
+             January 2003.
+
+7.  Acknowledgements
+
+   The authors wish to acknowledge and thank the following individuals
+   for their valuable comments to this document:  Adrian Smith, British
+   Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr.
+   Kumaki, KDDI.  Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan
+   Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa,
+   Intec Netcore, and David Meyer.
+
+Authors' Addresses
+
+   Comments should be made directly to the MPLS mailing list
+   at mpls@lists.ietf.org.
+
+   Thomas D. Nadeau
+   Cisco Systems, Inc.
+   300 Beaver Brook Road
+   Boxboro, MA 01719
+
+   Phone: +1-978-936-1470
+   EMail: tnadeau@cisco.com
+
+
+   Monique Jeanne Morrow
+   Cisco Systems, Inc.
+   Glatt-Com, 2nd Floor
+   CH-8301
+   Switzerland
+
+   Phone:  (0)1 878-9412
+   EMail: mmorrow@cisco.com
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   300 Beaver Brook Road
+   Boxboro, MA 01719
+
+   Phone: +1-978-936-1398
+   EMail: swallow@cisco.com
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 13]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+   David Allan
+   Nortel Networks
+   3500 Carling Ave.
+   Ottawa, Ontario, CANADA
+
+   Phone: 1-613-763-6362
+   EMail: dallan@nortel.com
+
+
+   Satoru Matsushima
+   Japan Telecom
+   1-9-1, Higashi-Shinbashi, Minato-ku
+   Tokyo, 105-7316 Japan
+
+   Phone: +81-3-6889-1092
+   EMail: satoru@ft.solteria.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 14]
+
+RFC 4377           OAM Requirements for MPLS Networks      February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   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
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   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
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Nadeau, et al.               Informational                     [Page 15]
+