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]