summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6905.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6905.txt')
-rw-r--r--doc/rfc/rfc6905.txt731
1 files changed, 731 insertions, 0 deletions
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]
+