GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6905

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6905.txt · Last modified: 2013/03/29 21:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki