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).
AbstractThis 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. 1. Introduction ....................................................2 2. Document Conventions ............................................2 3. Motivations .....................................................4 4. Requirements ....................................................4 5. Security Considerations ........................................11 6. References .....................................................12 7. Acknowledgements ...............................................13
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.
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.
Variable Path Latency: The variation in the sum of the delays experienced by packets transiting the path, otherwise know as jitter. Y1710].
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
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. Section 4.1.
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. Section 2.1 for definitions of the various quantitative aspects of LSPs.
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.
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. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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.
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Phone: 1-613-763-6362 EMail: email@example.com Satoru Matsushima Japan Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo, 105-7316 Japan Phone: +81-3-6889-1092 EMail: firstname.lastname@example.org
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 email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).