doc: Add RFC documents

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]
+