From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6905.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc6905.txt (limited to 'doc/rfc/rfc6905.txt') diff --git a/doc/rfc/rfc6905.txt b/doc/rfc/rfc6905.txt new file mode 100644 index 0000000..c3ed579 --- /dev/null +++ b/doc/rfc/rfc6905.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Senevirathne +Request for Comments: 6905 Cisco +Category: Informational D. Bond +ISSN: 2070-1721 IBM + S. Aldrin + Y. Li + Huawei + R. Watve + Cisco + March 2013 + + + Requirements for Operations, Administration, and Maintenance (OAM) + in Transparent Interconnection of Lots of Links (TRILL) + +Abstract + + Operations, Administration, and Maintenance (OAM) is a general term + used to identify functions and toolsets to troubleshoot and monitor + networks. This document presents OAM requirements applicable to the + Transparent Interconnection of Lots of Links (TRILL). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6905. + + + + + + + + + + + + + + +Senevirathne, et al. Informational [Page 1] + +RFC 6905 TRILL OAM Requirements March 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Scope ......................................................3 + 2. Conventions Used in This Document ...............................3 + 3. Terminology .....................................................3 + 4. OAM Requirements ................................................4 + 4.1. Data Plane .................................................4 + 4.2. Connectivity Verification ..................................5 + 4.2.1. Unicast .............................................5 + 4.2.2. Distribution Trees ..................................5 + 4.3. Continuity Check ...........................................5 + 4.4. Path Tracing ...............................................6 + 4.5. General Requirements .......................................6 + 4.6. Performance Monitoring .....................................7 + 4.6.1. Packet Loss .........................................7 + 4.6.2. Packet Delay ........................................7 + 4.7. ECMP Utilization ...........................................8 + 4.8. Security and Operational Considerations ....................8 + 4.9. Fault Indications ..........................................8 + 4.10. Defect Indications ........................................9 + 4.11. Live Traffic Monitoring ...................................9 + 5. Security Considerations .........................................9 + 6. References ......................................................9 + 6.1. Normative References .......................................9 + 6.2. Informative References ....................................10 + 7. Acknowledgments ................................................11 + 8. Contributors ...................................................11 + + + + + + + + +Senevirathne, et al. Informational [Page 2] + +RFC 6905 TRILL OAM Requirements March 2013 + + +1. Introduction + + The Operations, Administration, and Maintenance (OAM) generally + covers various production aspects of a network. In this document, we + use the term OAM as defined in [RFC6291]. + + The success of network operations depends on the ability to + proactively monitor it for faults, performance, etc., as well as the + ability to efficiently and quickly troubleshoot defects and failures. + A well-defined OAM toolset is a vital requirement for wider adoption + of Transparent Interconnection of Lots of Links (TRILL) as the next + generation data-forwarding technology in larger networks such as data + centers. + + In this document, we define the requirements for TRILL OAM. It is + assumed that the readers are familiar with the OAM concepts and + terminologies defined in other OAM standards such as [8021ag], + [RFC5860], and [RFC4377]. This document does not attempt to redefine + the terms and concepts specified elsewhere. + +1.1. Scope + + The scope of this document is OAM between Routing Bridges (RBridges) + of a TRILL campus over links selected by TRILL routing. + +2. Conventions Used in This Document + + 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]. + Although this document is not a protocol specification, the use of + this language clarifies the instructions to protocol designers + producing solutions that satisfy the requirements set out in this + document. + +3. Terminology + + Section: This term refers to a segment of a path between any two + given RBridges. As an example, consider the case where RB1 is + connected to RBx via RB2, RB3, and RB4. The segment between RB2 to + RB4 is referred to as a section of the path RB1 to RBx. More details + of this definition can be found in [RFC5960]. + + Flow: This term indicates a set of packets that share the same path + and per-hop behavior (such as priority). A flow is typically + identified by a portion of the inner payload that affects the hop-by- + hop forwarding decisions. This may contain Layer 2 through Layer 4 + information. + + + +Senevirathne, et al. Informational [Page 3] + +RFC 6905 TRILL OAM Requirements March 2013 + + + All Selectable Least-Cost Paths: This term refers to a subset of all + potentially available least-cost paths to a specified destination + RBridge that are available (and usable) for forwarding of frames. It + is important to note that in practice, due to limitations in + implementations, not all available least-cost paths may be selectable + for forwarding. + + Connectivity: This term indicates reachability between an arbitrary + RBridge RB1 and any other RBridge RB2. The specific path can be + either explicit (i.e., associated with a specific flow) or + unspecified. Unspecified means that messages used for connectivity + verification take whatever path the RBs happen to select. Please + refer to [OAMOVER] for details. + + Continuity Verification: This term refers to proactive verification + of liveliness between two RBridges at periodic intervals and the + generation of explicit notification when connectivity failures occur. + Please refer to [OAMOVER] for details. + + Fault: This term refers to an inability to perform a required action, + e.g., an unsuccessful attempt to deliver a packet. Please refer to + [TERMTP] for definition. + + Defect: This term refers to an interruption in the normal operation, + such that over a period of time no packets are delivered + successfully. Please refer to [TERMTP] for definition. + + Failure: This term refers to the termination of the required function + over a longer period of time. Persistence of a defect for a period + of time is interpreted as a failure. Please refer to [TERMTP] for + definition. + + Simulated Flow: This term refers to a sequence of OAM-generated + packets designed to follow a specific path. The fields of the + packets in the simulated flow may or may not be identical to the + fields of data packets of an actual flow being simulated. However, + the purpose of the simulated flow is to have OAM packets of the + simulated flow follow a specific path. + +4. OAM Requirements + +4.1. Data Plane + + OAM frames, utilized for connectivity verification, continuity + checks, performance measurements, etc., will by default take whatever + path TRILL chooses based on the current topology and per-hop equal- + cost path choices. In some cases, it may be required that the OAM + + + + +Senevirathne, et al. Informational [Page 4] + +RFC 6905 TRILL OAM Requirements March 2013 + + + frames utilize specific paths. Thus, it MUST be possible to arrange + that OAM frames follow the path taken by a specific flow. + + RBridges MUST have the ability to identify frames that require OAM + processing. + + TRILL OAM frames MUST remain within a TRILL campus and MUST NOT be + egressed from a TRILL network as native frames. + + OAM MUST have the ability to include all Ethernet traffic types + carried by TRILL. + +4.2. Connectivity Verification + +4.2.1. Unicast + + From an arbitrary RBridge RB1, OAM MUST have the ability to verify + connectivity to any other RBridge RB2. + + From an arbitrary RBridge RB1, OAM MUST have the ability to verify + connectivity to any other RBridge RB2 for a specific flow via the + path associated with the specified flow. + +4.2.2. Distribution Trees + + OAM MUST have the ability to verify connectivity from an arbitrary + RBridge RB1 to either a specific set of RBridges or all member + RBridges, for a specified distribution tree. This functionality is + referred to as verification of the unpruned distribution tree. + + OAM MUST have the ability to verify connectivity from an arbitrary + RBridge RB1 to either a specific set of RBridges or all member + RBridges, for a specified distribution tree and for a specified flow. + This functionality is referred to as verification of the pruned tree. + +4.3. Continuity Check + + OAM MUST provide functions that allow any arbitrary RBridge RB1 to + perform a Continuity Check to any other RBridge. + + OAM MUST provide functions that allow any arbitrary RBridge RB1 to + perform a Continuity Check to any other RBridge using a path + associated with a specified flow. + + OAM SHOULD provide functions that allow any arbitrary RBridge to + perform a Continuity Check to any other RBridge over any section of + any selectable least-cost path. + + + + +Senevirathne, et al. Informational [Page 5] + +RFC 6905 TRILL OAM Requirements March 2013 + + + OAM SHOULD provide the ability to perform a Continuity Check on + sections of any selectable path within the network. + + OAM SHOULD provide the ability to perform a multicast Continuity + Check for specified distribution tree(s), as well as specified + combinations of distribution trees and flows. The former is referred + to as an unpruned multi-destination tree Continuity Check and the + latter is referred to as a pruned tree Continuity Check. + +4.4. Path Tracing + + OAM MUST provide the ability to trace a path between any two RBridges + corresponding to a specified unicast flow. + + OAM SHOULD provide the ability to trace all selectable least-cost + paths between any two RBridges. + + OAM SHOULD provide functionality to trace all branches of a specified + distribution tree (unpruned tree). + + OAM SHOULD provide functionality to trace all branches of a specified + distribution tree for a specified flow (pruned tree). + +4.5. General Requirements + + OAM MUST provide the ability to initiate and maintain multiple + concurrent sessions for multiple OAM functions between any arbitrary + RBridge RB1 to any other RBridge. In general, multiple OAM + operations will run concurrently. For example, proactive continuity + checks may take place between RB1 and RB2 at the same time that an + operator decides to test connectivity between the same two RBs. + Multiple OAM functions and instances of those functions MUST be able + to run concurrently without interfering with each other. + + OAM MUST provide a single OAM framework for all TRILL OAM functions + within the scope of this document. + + OAM, as practical and as possible, SHOULD reuse functional, + operational, and semantic elements of existing OAM standards. + + OAM MUST maintain related error and operational counters. Such + counters MUST be accessible via network management applications + (e.g., SNMP). + + OAM functions related to continuity and connectivity checks MUST be + able to be invoked either proactively or on demand. + + + + + +Senevirathne, et al. Informational [Page 6] + +RFC 6905 TRILL OAM Requirements March 2013 + + + OAM MAY be required to provide the ability to specify a desired + response mode for a specific OAM message. The desired response mode + can be in-band, out-of-band, or none. + + The OAM Framework MUST be extensible to include new functionality. + For example, the solution needs to include a version number to + differentiate older and newer implementations and TLV structures for + flexibility to include new information elements. + + OAM MAY provide methods to verify control-plane and forwarding-plane + alignments. + + OAM SHOULD leverage existing OAM technologies, where practical. + +4.6. Performance Monitoring + +4.6.1. Packet Loss + + In this document, the term "packet loss" is used as defined in + Section 2.4 of [RFC2680]. + + OAM SHOULD provide the ability to measure packet loss statistics for + a flow from any arbitrary RBridge RB1 to any other RBridge. + + OAM SHOULD provide the ability to measure packet loss statistics over + a section for a flow between any arbitrary RBridge RB1 to any other + RBridge. + + OAM SHOULD provide the ability to measure packet loss statistics + between any two RBridges over all least-cost paths. + + An RBridge SHOULD be able to perform the above packet loss + measurement functions either proactively or on demand. + +4.6.2. Packet Delay + + There are two types of packet delays -- one-way delay and two-way + delay (Round-Trip Delay). + + One-way delay is defined in [RFC2679] as the time elapsed from the + start of transmission of the first bit of a packet by an RBridge + until the reception of the last bit of the packet by the destination + RBridge. + + + + + + + + +Senevirathne, et al. Informational [Page 7] + +RFC 6905 TRILL OAM Requirements March 2013 + + + Two-way delay is also referred to as Round-Trip Delay and is defined + similar to [RFC2681]; i.e., the time elapsed from the start of + transmission of the first bit of a packet from RB1, receipt of the + packet at RB2, RB2 sending a response packet back to RB1, and RB1 + receiving the last bit of that response packet. + + OAM SHOULD provide functions to measure two-way delay between two + RBridges. + + OAM MAY provide functions to measure one-way delay between two + RBridges for a specified flow. + + OAM MAY provide functions to measure one-way delay between two + RBridges for a specified flow over a specific section. + +4.7. ECMP Utilization + + OAM MAY provide functionality to monitor the effectiveness of per-hop + Equal-Cost Multipath (ECMP) hashing. For example, individual + RBridges could maintain counters that show how packets are being + distributed across equal-cost next hops for a specified destination + RBridge or RBridges as a result of ECMP hashing. + +4.8. Security and Operational Considerations + + Methods MUST be provided to protect against exploitation of OAM + framework for security and denial-of-service attacks. + + Methods MUST be provided to prevent OAM messages from causing + congestion in the networks. Periodically generated messages with + high frequencies may lead to congestion, hence methods such as + shaping or rate limiting SHOULD be utilized. + + Certain OAM functions may be utilized to gather operational + information such as topology of the network. Methods MUST be + provided to prevent unauthorized users accessing OAM functions to + gather critical and sensitive information of the network. + + OAM packets MUST be limited to within the TRILL campus, and the + implementation MUST provide methods to prevent leaking of OAM packets + out of the TRILL campus. Additionally, methods MUST be provided to + prevent accepting OAM packets from outside the TRILL campus. + +4.9. Fault Indications + + OAM MUST provide a Fault Indication framework to notify the packet's + ingress RBridge or other interested parties (such as syslog servers) + about faults. + + + +Senevirathne, et al. Informational [Page 8] + +RFC 6905 TRILL OAM Requirements March 2013 + + + OAM MUST provide functions to selectively enable or disable different + types of Fault Indications. + +4.10. Defect Indications + + OAM SHOULD provide a framework for Defect Detection and Indication. + + OAM Defect Detection and Indication Framework SHOULD provide methods + to selectively enable or disable Defect Detection per defect type. + + OAM Defect Detection and Indication Framework SHOULD provide methods + to configure Defect Detection thresholds per different types of + defects. + + OAM Defect Detection and Indication Framework SHOULD provide methods + to log defect indications to a locally defined archive (such as log + buffer) or Simple Network Management Protocol (SNMP) traps. + + OAM Defect Detection and Indication Framework SHOULD provide a Remote + Defect Indication framework that facilitates notifying the + originator/owner of the flow experiencing the defect, which is the + ingress RBridge. + + Remote Defect Indication MAY be either in-band or out-of-band. + +4.11. Live Traffic Monitoring + + OAM implementations MAY provide methods to utilize live traffic for + troubleshooting and performance monitoring. + +5. Security Considerations + + Security requirements are specified in Section 4.8. For general TRILL + security considerations, please refer to [RFC6325]. + +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. + + [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, + D., and S. Mansfield, "Guidelines for the Use of the "OAM" + Acronym in the IETF", BCP 161, RFC 6291, June 2011. + + + + + + +Senevirathne, et al. Informational [Page 9] + +RFC 6905 TRILL OAM Requirements March 2013 + + +6.2. Informative References + + [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: + Connectivity Fault Management", IEEE Std 802.1ag-2007, + 2007. + + [OAMOVER] Mizrahi, T., Sprecher, N., Bellagamba, E., Y. Weingarten, + "An Overview of Operations, Administration, and + Maintenance (OAM) Mechanisms", Work in Progress, January + 2013. + + [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Delay Metric for IPPM", RFC 2679, September 1999. + + [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way + Packet Loss Metric for IPPM", RFC 2680, September 1999. + + [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip + Delay Metric for IPPM", RFC 2681, September 1999. + + [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. + Matsushima, "Operations and Management (OAM) Requirements + for Multi-Protocol Label Switched (MPLS) Networks", RFC + 4377, February 2006. + + [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., + "Requirements for Operations, Administration, and + Maintenance (OAM) in MPLS Transport Networks", RFC 5860, + May 2010. + + [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS + Transport Profile Data Plane Architecture", RFC 5960, + August 2010. + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, July 2011. + + [TERMTP] van Helvoort, H., Ed., Andersson, L., Ed., and N. + Sprecher, Ed., "A Thesaurus for the Terminology used in + Multiprotocol Label Switching Transport Profile (MPLS-TP) + drafts/RFCs and ITU-T' Transport Network Recommendations", + Work in Progress, February 2013. + + + + + + + + +Senevirathne, et al. Informational [Page 10] + +RFC 6905 TRILL OAM Requirements March 2013 + + +7. Acknowledgments + + Special acknowledgments to IEEE 802.1 chair, Tony Jeffree, for + allowing us to solicit comments from IEEE 802.1 group. Also + recognized are the comments received from the IEEE group, IESG, + Stewart Bryant, Ralph Droms, Adrian Farrel, Benoit Claise, Ayal Lior, + and others. + +8. Contributors + + Thomas Narten + IBM Corporation + 3039 Cornwallis Avenue, + PO Box 12195 + Research Triangle Park, NC 27709 + USA + + EMail:narten@us.ibm.com + + + Donald Eastlake + Huawei Technologies + 155 Beaver Street, + Milford, MA 01757 + USA + + EMail: d3e3e3@gmail.com + + + Anoop Ghanwani + Dell + 350 Holger Way + San Jose, CA 95134 + USA + + Phone: +1-408-571-3500 + EMail: Anoop@alumni.duke.edu + + + Jon Hudson + Brocade + 120 Holger Way + San Jose, CA 95134 + USA + + EMail: jon.hudson@gmail.com + + + + + +Senevirathne, et al. Informational [Page 11] + +RFC 6905 TRILL OAM Requirements March 2013 + + + Naveen Nimmu + Broadcom + 9th Floor, Building no 9, Raheja Mind space + Hi-Tec City, Madhapur, + Hyderabad - 500 081 + India + + Phone: +1-408-218-8893 + EMail: naveen@broadcom.com + + + Radia Perlman + Intel Labs + 2700 156th Ave NE, Suite 300, + Bellevue, WA 98007 + USA + + Phone: +1-425-881-4824 + EMail: radia.perlman@intel.com + + + Tal Mizrahi + Marvell + 6 Hamada St. + Yokneam, 20692 + Israel + + EMail: talmi@marvell.com + +Authors' Addresses + + Tissa Senevirathne + Cisco Systems + 375 East Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1-408-853-2291 + EMail: tsenevir@cisco.com + + + + + + + + + + + + +Senevirathne, et al. Informational [Page 12] + +RFC 6905 TRILL OAM Requirements March 2013 + + + David Bond + IBM + 4400 North 1st Street + San Jose, CA 95134 + USA + + Phone: +1-603-339-7575 + EMail: mokon@mokon.net + + + Sam Aldrin + Huawei Technologies + 2330 Central Express Way + Santa Clara, CA 95951 + USA + + EMail: aldrin.ietf@gmail.com + + + Yizhou Li + Huawei Technologies + 101 Software Avenue, + Nanjing 210012 + China + + Phone: +86-25-56625375 + EMail: liyizhou@huawei.com + + + Rohit Watve + Cisco Systems + 375 East Tasman Drive + San Jose, CA 95134 + USA + + Phone: +1-408-424-2091 + EMail: rwatve@cisco.com + + + + + + + + + + + + + + +Senevirathne, et al. Informational [Page 13] + -- cgit v1.2.3