[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

       Internet Engineering Task Force                 P. Ashwood-Smith
       Internet Draft                                         R.Iyenger
       Intended status: Informational                           T. Tsou
       Expires: December 12, 2012                                Huawei
                                                             A. Sajassi
                                                                  Cisco
                                                          June 12, 2012
       
       
                            NVO3 Operational Requirements
       
                draft-ashwood-nvo3-operational-requirement-00.txt
       
        Abstract
       
           This document provides framework and requirements for Network
           Virtualization over Layer 3 (NVO3) Operations, Administration,
           and Maintenance (OAM). This document for the most part gathers
           requirements from existing IETF drafts and RFCs which have
           already extensively studied this subject for different data
           planes and layering. As a result this draft is high level and
           broad. We begin to ask which are truely required for NVO3 and
           expect the list to be narrowed by the working group as
           subsequent versions of this draft are created.
       
       
        Status of this Memo
       
           This Internet-Draft is submitted in full conformance with the
           provisions of BCP 78 and BCP 79.
       
           Internet-Drafts are working documents of the Internet
           Engineering Task Force (IETF), its areas, and its working
           groups.  Note that other groups may also distribute working
           documents as Internet-Drafts.
       
           Internet-Drafts are draft documents valid for a maximum of six
           months and may be updated, replaced, or obsoleted by other
           documents at any time.  It is inappropriate to use Internet-
           Drafts as reference material or to cite them other than as
           "work in progress."
       
           The list of current Internet-Drafts can be accessed at
           http://www.ietf.org/ietf/1id-abstracts.txt
       
           The list of Internet-Draft Shadow Directories can be accessed
           at http://www.ietf.org/shadow.html
       
       
       
       
        Ashwood-Smith, et al. Expires November 18 2012            Page 1]
       
        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           This Internet-Draft will expire on December 14, 2012.
       
        Copyright Notice
       
           Copyright (c) 2012 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.
       
        Table of Contents
       
           1. Introduction                                            3
                  1.1. OSI Definitions of OAM                         3
                  1.2. Specification of Requirements                  5
                  1.3. Relationship with Other OAM Work               5
           2. Terminology                                             6
           3. NVO3 Reference Model                                    6
           4. OAM Framework for NVO3                                  7
                  4.1. OAM Layering                                   8
                  4.2. OAM Domains                                    9
           5. NVO3 OAM Requirements                                   9
                  5.1. Discovery                                      9
                  5.2. Connectivity Fault Management                  9
                       5.2.1. Connectivity Fault Detection            9
                       5.2.2. Connectivity Fault Verification         10
                       5.2.3. Connectivity Fault localization         10
                       5.2.4. Connectivity Fault Notification and Alarm
                              Suppression                             10
                  5.3. Frame Loss                                     10
                  5.4. Frame Delay                                    10
                  5.5. Frame Delay Variation                          10
                  5.6. Availability                                   10
                  5.7. Data Path Forwarding                           11
                  5.8. Scalability                                    11
                  5.9. Extensibility                                  11
                  5.10. Security                                      11
                  5.11. Transport Independence                        12
                  5.12. Application Independence                      12
           6. Security Considerations                                 12
           7. IANA Considerations                                     12
           8. References                                              12
                  8.1. Normative References                           12
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 2]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
                  8.2. Informative References                         12
           9. Authors' Addresses                                      13
           10. Contributors                                           14
           11. Acknowlegement                                         14
       
        1. Introduction
       
           This document provides framework and requirements for Network
           virtualization over Layer 3(NVO3) Operation, Administration,
           and Maintenance (OAM). Given that this OAM subject is far from
           new and has been under extensive investigation by various IETF
           working groups (and several other standards bodies) for many
           years, this document draws from existing work, starting with
           RFC 6136 [L2VPN-OAM] "Layer 2 Virtual Private Network (L2VPN)
           Operations, Administration and Maintenance (OAM) Requirements
           and Framework" as a result sections of text have been reused
           with minor changes with the permission of these authors.
       
           NVO3 OAM requirements are expected to a be a subset of
           IETF/IEEE etc. work done so far however we begin with a full
           set and expect to prune through several iterations of this
           document.
       
        1.1. OSI Definitions of OAM
       
           The scope of OAM for any service and/or transport/network
           infrastructure technologies can be very broad in nature. OSI
           has defined the following five generic functional areas
           commonly abbreviated as "FCAPS" [NM-Standards]:
       
           o  Fault Management,
       
           o  Configuration Management,
       
           o  Accounting Management,
       
           o  Performance Management, and
       
           o  Security Management.
       
           This document focuses on the Fault and Performance Management
           aspects. Other functional aspects of FCAPS and their relevance
           (or not) to NVO3 are for further study.
       
           Fault Management can typically be viewed in terms of the
           following categories:
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 3]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           o  Fault Detection
       
           o  Fault Verification
       
           o  Fault Isolation
       
           o  Fault Notification and Alarm Suppression
       
           o  Fault Recovery
       
           Fault detection deals with mechanism(s) that can detect both
           hard failures such as link and device failures, and soft
           failures, such as software failure, memory corruption,
           misconfiguration, etc. Typically, a lightweight protocol is
           desirable to detect the fault and thus it would be prudent to
           verify the fault via a fault verification mechanism before
           taking additional steps in isolating the fault. After verifying
           that a fault has occurred along the data path, it is important
           to be able to isolate the fault to the level of a given device
           or link. Therefore, a fault isolation mechanism is needed in
           Fault Management. A fault notification mechanism can be used in
           conjunction with a fault detection mechanism to notify the
           devices upstream and downstream to the fault detection point.
           For example, when there is a client/server relationship between
           two layered networks (for example the NVO3 layer would be a
           client of the outer IP server layer) while the inner IP layer
           would be a client of the NVO3 server layer 2); fault detection
           at the server layer may result in the following fault
           notifications:
       
           o  Sending a forward fault notification from the server layer
              to the client layer network(s) using the fault notification
              format appropriate to the client layer.
       
           o  Sending a backward fault notification at the server layer,
              if applicable, in the reverse direction.
       
           o  Sending a backward fault notification at the client layer,
              if applicable, in the reverse direction.
       
           Finally, fault recovery deals with recovering from the detected
           failure by switching to an alternate available data path using
           alternate devices or links (e.g., device redundancy or link
           redundancy). Note, given that the IP network on which NVO3
           resides is usually self healing, it is expected that recovery
           would not normally be required by the NVO3 layer. The special
           case of a static IP overlay network, or possibly a centrally
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 4]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           controlled IP overlay network may however require NVO3
           involvement in fault recovery.
       
       
           Performance Management deals with mechanism(s) that allow
           determining and measuring the performance of the
           network/services under consideration. Performance Management
           can be used to verify the compliance to both the service-level
           and network-level metric objectives/specifications. Performance
           Management typically consists of measurement of performance
           metrics, e.g., Frame Loss, Frame Delay, Frame Delay Variation
           (aka Jitter), etc., across managed entities when the managed
           entities are in available state. Performance Management is
           suspended across unavailable managed entities.
       
           This document uses the above broad OAM definitions as a guide
           for the requirements. We recognize this is likely 'overkill'
           and that pruning will be required since the layers above and
           below NVO3 are already quite full featured.
       
         1.2. Specification of Requirements
       
           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 [RFC2119].
       
         1.3. Relationship with Other OAM Work
       
           This document leverages requirements that originate with other
           OAM work, specifically the following:
       
           o  [L2VPN-OAM] Layer 2 Virtual Private Network(L2VPN)
              Operations, Administration and Maintenance (OAM)
              Requirements and Framework. This document provides a
              template and some of the high level requirements and
              introduction wording.
       
           o  [IEEE802.1ag] IEEE Std. 802.1ag-2007. This document is
              expected to provide a subset of the requirements for NVO3
              both at the Tenant level and also within the L3 Overlay
              network.
       
           o  [Y.1731] ITU-T Std. Y.1731. This document is expected to
              provide a subset of the requirements for NVO3 at the Tenant
              level.
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 5]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           o  NVO3 Data Plane Requirements [NVO3-DP-REQ] (section 3.8 -
              OAM) lists several requirements specifically concerning
              ECMP/LAG.
       
        2. Terminology
       
           The terminology defined in [NVO3-framework] and [NVO3-DP-REQS]
           is used throughtout this document. We introduce no new
           terminology.
       
        3. NVO3 Reference Model
       
           Figure 1 below reproduces the generic NVO3 reference model as
           per [NVO3-Framework].
       
                   +--------+                                  +--------+
                   | Tenant |                                  | Tenant |
                   |  End   +--+                           +---|  End   |
                   | System |  |                           |   | System |
                   +--------+  |    ...................    |   +--------+
                               |  +-+--+           +--+-+  |
                               |  | NV |           | NV |  |
                               +--|Edge|           |Edge|--+
                                  +-+--+           +--+-+
                                 /  .    L3 Overlay   .  \
                   +--------+   /   .     Network     .   \     +--------+
                   | Tenant +--+    .                 .    +----| Tenant |
                   |  End   |       .                 .         |  End   |
                   | System |       .    +----+       .         | System |
                   +--------+       .....| NV |........         +--------+
                                         |Edge|
                                         +----+
                                           |
                                           |
                                        +--------+
                                        | Tenant |
                                        |  End   |
                                        | System |
                                        +--------+
       
                Figure 1 : Generic reference model for DC network
                           virtualization over a Layer3 infrastructure
       
       
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 6]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           Figure 2 below, reproduces the Generic reference model for the
           NV Edge (NVE) as per [NVO3-DP-Reqs].
       
       
                              +------- L3 Network ------+
                              |                         |
                              |       Tunnel Overlay    |
                 +------------+--------+       +--------+------------+
                 | +----------+------+ |       | +------+----------+ |
                 | | Overlay Module  | |       | | Overlay Module  | |
                 | +--------+--------+ |       | +--------+--------+ |
                 |          | VNID     |       |          | VNID     |
                 |          |          |       |          |          |
                 |  +-------+-------+  |       |  +-------+-------+  |
                 |  |      VNI      |  |       |  |      VNI      |  |
            NVE1 |  +-+-----------+-+  |  NVE2 |  +-+-----------+-+  |
                 |    |   VAPs    |    |       |    |   VAPs    |    |
                 +----+-----------+----+       +----+-----------+----+
                      |           |                 |           |
               -------+-----------+-----------------+-----------+-------
                      |           |     Tenant      |           |
                      |           |   Service IF    |           |
                    Tenant End Systems            Tenant End Systems
       
       
                    Figure 2 - Generic reference model for NV Edge
       
       
        4. OAM Framework for NVO3
       
           Figure 1 shows the generic reference model for a DC network
           virtualization over an L3 (or L3VPN) infrastructure while
           Figure 2 shows the generic reference model for the NV Edge.
       
           L3 network(s) or L3 VPN networks (either IPV6 or IPV4), provide
           transport for an emulated layer 2 created by NV Edge devices.
           Unicast and multicast tunneling methods (demultiplexed by VNID)
           are used to provide connectivity between the NV Edge devices.
           The NV Edge devices then present an emulated layer 2 network to
           the Tenant End Systems at a VNI through VAPs. The NV Edge
           devices map layer 2 unicast to layer 3 unicast point-to-point
           tunnels and may either map layer 2 multicast to layer 3
           multicast tunnels or may replicate packets onto multiple l3
           unicast tunnels.
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 7]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
        4.1. OAM Layering
       
           The emulated layer 2 network is provided by the NV Edge devices
           to which the Tenant End Systems are connected. This network of
           NV Edges can belong to a single network operator or can span
           across multiple network operators and / or administrative
           domains. Likewise the L3 Overlay Network can belong to a single
           network operator or can span across multiple network operators
           / administrative domains.
       
           While each of the layers is responsible for its own OAM, each
           layer may consist of several different administrative domains.
       
       
                                                                 OAM
                                                                 ---
       
             TENANT    |----------------------------| TENANT {all IP/ETH}
       
       
                NV-Edge   |----------------------|  NV-Edge  {t.b.d}
       
       
                  IP(VPN)   |---| IP (VPN) |---| IP(VPN)     {IP(VPN)/ETH}
       
       
       
                  Figure 3 : OAM layers in an NVO3 network
       
           For example, at the bottom, at the L3 IP overlay network layer
           IP(VPN) and/or Ethernet OAM mechanisms are used to probe link
           by link, node to node etc. OAM addressing here means physical
           node loopback or interface addresses.
       
           Further up, at the NV-Edge layer, NVO3 OAM messages are used to
           probe the NV-Edge to NV-Edge tunnels and NV-Edge entity status.
           OAM addressing here likely means the physical node loopback
           together with the VNI (to demultiplex the tunnels).
       
           Finally, at the Tenant layer, the IP and/or Ethernet OAM
           mechanisms are again used but here they are operating over the
           logical L2/L3 provided by the NV-Edge through the VAP. OAM
           addressing at this layer deals with the logical interfaces on
           Vswitches and Virtual Machines.
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 8]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
        4.2. OAM Domains
       
           Complex OAM relationships exist as a result of the hierarchical
           layering of responsibility and of breaking up of end to end
           responsibility.
       
           The OAM domain above NVO3, is expected to be supported by
           existing IP and L2 OAM methods and tools.
       
           The OAM domain below NVO3, is expected to be supported by
           existing IP/L2 and MPLS OAM methods and tools. Where this layer
           is actually multiple domains spliced together, the existing
           methods to deal with these boundaries are unchanged. Note
           however that exposing LAG/ECMP detailed behavior may result in
           additional requirements to this domain.
       
           When we refer to an OAM domain in this document, or just
           'domain', we therefore refer to a closed set of NVEs and the
           tunnels which interconnect them.
       
        5. NVO3 OAM Requirements
       
           The following numbered requirements originate from [L2VPN-OAM].
           All are included however where they seem obviously not relevant
           (to these authors) an explaination as to why is included.
       
        5.1. Discovery
       
           R1) NVO3 OAM MUST allow an NV Edge device to discover other NV
           Edge devices that share the same VNI within a given NVO3
           domain.
       
        5.2. Connectivity Fault Management
       
        5.2.1. Connectivity Fault Detection
       
           R2) NVO3 OAM MUST allow proactive connectivity monitoring
           between two NV Edge devices that support the same VNIs within a
           given NVO3 domain.
       
           R3) NVO3 OAM MUST allow monitoring/tracing of all possible
           paths between NV Edge devices such that equal cost paths that
           traverse LAG and/or ECMP may be differenciated.
       
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 9]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
        5.2.2. Connectivity Fault Verification
       
           R4) NVO3 OAM MUST allow connectivity fault verification between
           two NV Edge devices that support the same VNI within a given
           NVO3 domain.
       
        5.2.3. Connectivity Fault localization
       
           R5) NVO3 OAM MUST allow connectivity fault localization between
           two NV Edge devices that support the same instance within a
           given NVO3 domain.
       
        5.2.4. Connectivity Fault Notification and Alarm Suppression
       
           R6) NVO3 OAM MUST support fault notification to be triggered as
           a result of the IP underlay network faults.  This fault
           notification SHOULD be used for the suppression of redundant
           service-level alarms.
       
        5.3. Frame Loss
       
           R7) NVO3 OAM MUST support measurement of per VNI frame/packet
           loss between two NV Edge devices that support the same VNI
           within a given NVO3 domain.
       
        5.4. Frame Delay
       
           R8) NVO3 OAM MUST support measurement of per VNI two-way
           frame/packet delay between two NV edge devices that support the
           same VNI within a given NVO3 domain.
       
           R9) NVO3 OAM SHOULD support measurement of per VNI one-way
           frame/packet delay between two NV Edge devices that support the
           same VNI within a given NVO3 domain.
       
        5.5. Frame Delay Variation
       
           R10) NVO3 OAM MUST support measurement of per VNI frame/packet
           delay variation between two NV Edge devices that support the
           same VNI within a given NVO3 domain.
       
        5.6. Availability
       
           A service may be considered unavailable if the service
           frames/packets do not reach their intended destination (e.g.,
           connectivity is down or frame/packet loss is occurring) or the
           service is degraded (e.g., frame/packet delay and/or delay
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 10]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           variation threshold is exceeded). Entry and exit conditions may
           be defined for the unavailable state. Availability itself may
           be defined in the context of a service type. Since availability
           measurement may be associated with connectivity, frame/packet
           loss, frame/packet delay, and frame/packet delay variation
           measurements, no additional requirements are specified
           currently.
       
        5.7. Data Path Forwarding
       
           R11) NVO3 OAM frames MUST be forwarded along the same path
           (i.e., links (including LAG members) and nodes) as the NVO3
           data frames.
       
           R12) NVO3 OAM frames MUST provide a mechanisms to
           exercise/trace all data paths that result due to ECMP/LAG hops.
       
        5.8. Scalability
       
           R13) NVO3 OAM MUST be scalable such that an NV edge device can
           support proactive OAM for each VNI that is supported by the
           device. (Note - Likely very hard to achieve with hash based
           ECMP/LAG).
       
         5.9. Extensibility
       
           R14) NVO3 OAM MUST be extensible such that new functionality
           and information elements related to this functionality can be
           introduced in the future.
       
           R15) NVO3 OAM MUST be defined such that devices not supporting
           the OAM are able to forward the OAM frames in a similar fashion
           as the regular NVO3 data frames/packets.
       
         5.10. Security
       
           R16) NVO3 OAM frames MUST be prevented from leaking outside
           their NVO3 domain.
       
           R17) NVO3 OAM frames from outside an NVO3 domain MUST be
           prevented from entering the NVO3 domain when such OAM frames
           belong to the same level or to a lower-level OAM. (Trivially
           met because hierarchical domains are independent technologies)
       
           R18) NVO3 OAM frames from outside an NVO3 domain MUST be
           transported transparently inside the NVO3 domain when such OAM
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 11]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           frames belong to a higher-level NVO3 domain. (Trivially met
           because hierarchical domains are independent technologies).
       
         5.11. Transport Independence
       
           Similar to transport requirement from [L2VPN-OAM], we expect
           NOV3 OAM will leverage the OAM capabilities of the transport
           layer (e.g., IP underlay).
       
           R19) NVO3 OAM MAY allow adaptation/interworking with its IP
           underlay OAM functions.  For example, this would be useful to
           allow fault notifications from the IP layer to be sent to the
           NVO3 layer and likewise exposure of LAG / ECMP will require
           such non-independence.
       
         5.12. Application Independence
       
           R20) NVO3 OAM MUST be independent of the application
           technologies and specific application OAM capabilities.
       
        6. Security Considerations
       
           TBD.
       
        7. IANA Considerations
       
           This memo includes no request to IANA.
       
        8. References
       
        8.1. Normative References
       
          [RFC2119]         Bradner, S., "Key words for use in RFCs to
                            Indicate Requirement Levels", BCP 14, RFC
                            2119, March 1997.
       
        8.2. Informative References
       
          [NVO3-framework]  Lasserre, M. et al, "Framework for DC Network
                            Virtualization", draft-lasserre-nvo3-framework
                            work in progress)
       
          [NVO3-DP-Reqs]    Bitar, N. Et al, "NVO3 Data Plane
                            Requirements",draft-bl-nvo3-dataplane-
                            requirements,
                            (work in progress)
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 12]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
          [IEEE802.1ag]    "IEEE Standard for Local and metropolitan area
                            networks - Virtual Bridged Local Area
                            Networks, Amendment 5: Connectivity Fault
                            Management", 2007.
       
          [IEEE802.1ah]    "IEEE Standard for Local and metropolitan area
                            networks - Virtual Bridged Local Area
                            Networks, Amendment 6: Provider Backbone
                            Bridges", 2008.
       
          [Y.1731]         "ITU-T Recommendation Y.1731 (02/08) - OAM
                            functions and mechanisms for Ethernet based
                            networks", February 2008.
       
          [L2VPN-OAM]       A. Sajassi and D. Mohan, "Layer 2 Virtual
                            Private Network (L2VPN) Operations,
                            Administration, and Maintenance (OAM)
                            Requirements and Framework", RFC   6136, March
                            2011.
       
          [NM-Standards]   "TMN Management Functions", M.3400, February
                            2000.
       
       
        9. Authors' Addresses
       
           Peter Ashwood-Smith
           Huawei
           303 Terry Fox Drive, Suite 400, Kanata, Ontario K2K 3J1
           Email: Peter.AshwoodSmith@huawei.com
       
           Ranga Iyenger
           Huawei
           2330 Central Expy, Santa Clara, CA 95050
           Email: ranga.Iyenger@huawei.com
       
       
       
       
       
       
       
       
       
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 13]


        Internet-Draft   OAM Requirements for NVO3              June 2012
       
       
           Ting Zou
           Huawei
           2330 Central Expy, Santa Clara, CA 95050
           Email: Tina.Tsou.Zouting@huawei.com
       
           Ali Sajassi
           Cisco
           170 West Tasman Drive
           San Jose, CA  95134
           Email: sajassi@cisco.com
       
        10. Contributors
       
           We invite more contributors.
       
        11. Acknowlegement
       
           We invite more feedback.
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
        Ashwood-Smith, et al.Expires November 18, 2012           [Page 14]
       

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/