Movatterモバイル変換

Internet Engineering Task Force (IETF)                   T. SenevirathneRequest for Comments: 6905                                         CiscoCategory: Informational                                          D. BondISSN: 2070-1721                                                      IBM                                                               S. Aldrin                                                                   Y. Li                                                                  Huawei                                                                R. Watve                                                                   Cisco                                                              March 2013Requirements 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; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6905.Senevirathne, et al.          Informational                     [Page 1]

RFC 6905                 TRILL OAM Requirements               March 2013Copyright Notice   Copyright (c) 2013 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1. Introduction ....................................................31.1. Scope ......................................................32. Conventions Used in This Document ...............................33. Terminology .....................................................34. OAM Requirements ................................................44.1. Data Plane .................................................44.2. Connectivity Verification ..................................54.2.1. Unicast .............................................54.2.2. Distribution Trees ..................................54.3. Continuity Check ...........................................54.4. Path Tracing ...............................................64.5. General Requirements .......................................64.6. Performance Monitoring .....................................74.6.1. Packet Loss .........................................74.6.2. Packet Delay ........................................74.7. ECMP Utilization ...........................................84.8. Security and Operational Considerations ....................84.9. Fault Indications ..........................................84.10. Defect Indications ........................................94.11. Live Traffic Monitoring ...................................95. Security Considerations .........................................96. References ......................................................96.1. Normative References .......................................96.2. Informative References ....................................107. Acknowledgments ................................................118. Contributors ...................................................11Senevirathne, et al.          Informational                     [Page 2]

RFC 6905                 TRILL OAM Requirements               March 20131.  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 inRFC 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 Requirements4.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 OAMSenevirathne, 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 Verification4.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 Monitoring4.6.1.  Packet Loss   In this document, the term "packet loss" is used as defined inSection 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 inSection 4.8. For general TRILL   security considerations, please refer to [RFC6325].6.  References6.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 20136.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",RFC4377, 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 20137.  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.comSenevirathne, 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.comAuthors' Addresses   Tissa Senevirathne   Cisco Systems   375 East Tasman Drive   San Jose, CA 95134   USA   Phone: +1-408-853-2291   EMail: tsenevir@cisco.comSenevirathne, 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.comSenevirathne, et al.          Informational                    [Page 13]