Network Working Group D. King
Internet-Draft Old Dog Consulting
Intended status: Informational M. Boucadair
Expires: January 1, 2015 France Telecom
S. Aldrin
Huawei USA
G. Mirsky
Ericsson
Q. Wu
Huawei
June 30, 2014
Use Cases for Transport Independent Multiple Layer OAM
draft-king-opsawg-time-multi-layer-oam-use-case-00
Abstract
This document identifies and discusses use-cases for transport
independent OAM that need to interface multi-layer or multi-domain
transport networks to cover heterogeneous networking technologies.
As providers face multi-layer networks and diverse transport
technologies, generic and integrated OAM is desirable for simplifying
network operations and maintenance.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 1, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
King, et al. Expires January 1, 2015 [Page 1]
Internet-Draft Multi-Layer OAM UC June 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multi-Layer OAM use cases illustration . . . . . . . . . . . 3
2.1. Multi-Level OAM Consolidated in the Data Plane and
Management Plane . . . . . . . . . . . . . . . . . . . . 3
2.2. OAM at Top of Layer 3 . . . . . . . . . . . . . . . . . . 5
2.3. Overlay OAM . . . . . . . . . . . . . . . . . . . . . . . 8
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
This document discusses use-cases for transport independent OAM that
need to interface multi-layer or multi-domain transport networks to
to cover heterogeneous networking technologies. As providers (e.g.,
network providers, data center providers, etc.) face multi-layer
networks and diverse transport technology, generic and integrated OAM
is desirable for keeping network complexity down and simplifying OAM.
This document is a part of the TIME effort, called Transport
Independent OAM in Multi-Layer Environment. The goal of TIME is as
follows
o Understand and discuss situations where an OAM protocol can be
tuned and optimized for a specific data plane.
o OAM consolidation in the data plane:
* Exchange OAM information at the service layer atop of layer 3.
* Deployed over various encapsulating protocols, and in various
medium types
o OAM consolidation in the management plane:
King, et al. Expires January 1, 2015 [Page 2]
Internet-Draft Multi-Layer OAM UC June 2014
* Abstract OAM information common to different layers.
* Expose OAM information via unified interface to management
entities, independently of the layer they belong to.
* Discuss how information gathered from various layers can be
correlated for the sake of network operations optimization
purposes.
* Propose means to help during service diagnosis; these means may
rely on filtering information to be leaked to other layers so
that time recovery can be optimized. A typical example would
be efficient root cause analysis that is fed with input from
various layers.
* Propose means that would help to optimize a network as a whole
instead of the monolithic approach that is specific to a given
layer. For example, investigate means that would help in
computing diverse and completely disjoint paths, not only at
layer 3 but also at the physical layer.
These objectives are not frozen; further discussion is required to
target key issues and scope the work to be conducted within IETF
accordingly.
The problem statement and architecture is discussed in [TIME-PS].
2. Multi-Layer OAM use cases illustration
2.1. Multi-Level OAM Consolidated in the Data Plane and Management
Plane
King, et al. Expires January 1, 2015 [Page 3]
Internet-Draft Multi-Layer OAM UC June 2014
Domain A Domain B
---------- ----------
//-MPLS/IP -\\ //-MPLS/IP -\\
// \\ // \\
/ \ / \
|| || || ||
| | | |
+---+ +----+ +----+ +----+ +----+ +----+ +----+ +---+
|CE |--| PE |------| P +----| PE |-+ PE +---- | P |-----| PE |--|CE |
+-+-+ +--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ +-+-+
| | | | | | | | | | | |
| ||| | ||| ||| | ||| |
| | | | | | | |
| |\\ | //| |\\ | //| |
| | \\- | -// | | \\- | -// | |
| | ------+--- | | -----+---- | |
L1 | |Ethernet OAM(CC,CV,etc.) | | |
o-------D-----------+--------+-------+----------+---------D-------o
| | | | | | | |
L2| | |IP OAM(Ping, Tracerroute, etc.) | |
o-------o-----------D--------o-------o----------D---------o-------o
| | | | | | | |
L3| Transport Independent OAM(Integrated Ethernet with IP OAM |
o-------o-----------D--------o-------o----------D---------o-------o
| | | | | | | |
| | | | | | | |
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Figure 1 illustrates a multi-layer network in which IP traffic
between two customer edges is transported over an IP/MPLS provider
Figure 1 illustrates a multi-layer network in which IP traffic
between two customer edges is transported over an IP/MPLS provider
network and multiple layers OAMs are used. Ethernet OAM is used at
the customer level for monitoring the end-to-end connection between
the two customer edges, while IP OAM is used at the provider level
for monitoring the connection between any two provider edges in each
network. In addition to Ethernet OAM, transport independent OAM is
also used for monitor end to end connection between the two customer
edges at the abstract level.
With transport independent OAM in the data plane, a user who wishes
to issue a IP Ping Command or use connectivity verification command
can do so in the same manner regardless of the underlying protocol or
transport technology. Consider a scenario where both Ethernet OAM
and IP OAM can be decomposed into a set of various OAM functions and
King, et al. Expires January 1, 2015 [Page 4]
Internet-Draft Multi-Layer OAM UC June 2014
an Ethernet OAM can be integrated with IP OAM in one protocol. When
one OAM function is invoked, it will be invoked in the same way as
the other OAM function regardless of the underlying protocol.
Alternatively, when Ethernet OAM and IP OAM can be consolidated
through uniformed interface at the management plane, A user who
wishes to issue a IP Ping command or a IP Traceroute or initiate a
session monitoring can also do so in the same manner regardless of
the underlying protocol or technology.
Consider a scenario where an IP ping to PE B from CE A failed.
Between CE A and PE B there are IEEE 802.1 bridges a,b and c. Let's
assume a,b and c are using [8021Q] CFM. Upon detecting IP layer ping
failure, the user may wish to "go down" to the Ethernet layer and
issue the corresponding fault verification (LBM) and fault isolation
(LTM) tools, using the same API.
2.2. OAM at Top of Layer 3
King, et al. Expires January 1, 2015 [Page 5]
Internet-Draft Multi-Layer OAM UC June 2014
+--------+
|Unified |
+---------------------------+OSS/NMS +---------------------------+
| +--------+ |
| Domain A Domain B |
| ---------- ---------- |
| // MPLS/IP -\\ //- MPLS/IP -\\ |
+----+ // \\ // \\ |
|SF- | SN1 SN2 SN3 SN4 SN5 SN6 +-+--+
| |+++--+ +----| +--+++ +++--+ +----+ +--+++-|SF- |
|Ingr||SF1 | | | |SF4|| || | |SF7 | | || |Egr |
| ++ +------| +----+ +-+ +-----| +-----| +-+ |
|ess ||SF2 | | SF3| |SF5 | |SF6 | |SF8 | |SF9 | |ess |
+-+-+|+--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ |+-+-+
| | | | | | | | | | | |
| ||| | ||| ||| | ||| |
| | | | | | | |
| |\\ | //| |\\ | //| |
| | \\- | -// | | \\- | -// | |
| | ------+--- | | -----+---- | |
L1 | |Ethernet OAM(CC,CV, etc.) | | |
o-------D-----------+--------+-------+----------+---------D-------o
| | | | | | | |
L2 | |IP OAM(Ping, Tracerroute, etc.) | |
o-------o-----------D--------o-------o----------D---------o-------o
| | | | | | | |
L3 Transport Independent OAM(Integrated Ethernet with IP OAM |
o-------o-----------D--------o-------o----------D---------o-------o
| | | | | | | |
| | | | | | | |
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Layer7- SF1 --------------------- SF6 ------- SF7-------------
Layer6------------------------F4 --------------------------------
Layer5------------ SF3-------SF5------------------------- SF9----
Layer4---SF2 ---------------------------------- SF8--------------
In Service Function Chain, the service packets are steered through a
set of Service Function Nodes distributed in the network. Overlay
technologies (or tunneling techniques in general) can be used to
stitch these Service Function Nodes in order to form end to end path.
When the service packet enters into the network, OAM information
needs to be imposed by ingress node of the network into the
packet(e.g., packet header extension or TLV extension in the overlay
header) and pass through the network in the same path as the service
King, et al. Expires January 1, 2015 [Page 6]
Internet-Draft Multi-Layer OAM UC June 2014
traffic and processed by a set of Service Functions that are hosted
in Service Function Nodes and located in different layers at the top
of layer 3.
When any Service Function Nodes or any service segment between two
service nodes fails to deliver user traffic, there is a need to
provide a tool that would enable users to detect such failures, and a
mechanism to isolate faults.
In case of several SFs co-located in the same Service Function Node,
the packet is processed by all SFs in the Service Function Node, Once
the packet is successfully handled by one SF, the packet is forwarded
to the next SF that is in the same Service Function Node.
When the packet leave the network, the OAM information needs to
stripped out from the packet.
To provide unified view of OAM information common to different
layers, different domains, different operators, these OAM information
needs to gathered from various layer using different encapsulation
and tunneling techniques and abstracted and provided to the
management application via the unified management interface.
As indicated in [I-D.boucadair-sfc-requirments], the following OAM
functions are to be supported:
o Support means to verify the completion of the forwarding actions
until the SFC Border Node is reached (see Section 3.4.1 of
[RFC5706]).
o Support means to ensure coherent classification rules are
installed in and enforced by all the Classifiers of the SFC
domain.
o Support means to correlate classification policies with observed
forwarding actions.
o Support in-band liveliness and functionality checking mechanisms
for the instantiated Service Function Chains and the Service
Functions that belong to these chains.
Other service diagnosis and troubleshooting requirements are
discussed in [I-D.boucadair-sfc-requirments].
King, et al. Expires January 1, 2015 [Page 7]
Internet-Draft Multi-Layer OAM UC June 2014
2.3. Overlay OAM
Domain A Domain B
---------- ----------
//-MPLS/IP -\\ //-MPLS/IP -\\
// \\ // \\
/ \ / \
|| || || ||
| | | |
+---+ +----+ +----+ +----+ +----+ +----+ +----+ +---+
|CE |--| PE +------| P +----| PE +-+ PE +-----+ P +-----+ PE +--|CE |
+-+-+ +--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ +-+-+
| | | | | | | | | | | |
| ||| | ||| ||| | ||| |
| | | | | | | |
| |\\ | //| |\\ | //| |
| | \\- | -// | | \\- | -// | |
| | ------+--- | | -----+---- | |
L1 | |Ethernet OAM(CC,CV,etc) | | |
o-------D-----------+--------+-------+----------+---------D-------o
| | | | | | | |
| L2 | |IP OAM(Ping, Tracerroute, etc.) |
o-----------D--------o-------o----------D---------o-
| | | | | |
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Overlay network is referred to a network that is built on top of
another underlying network and provides various services to tenant
system. With the growth of network virtualization technology, the
needs for inter-connection between various overlay technologies/
networks (e.g., VXLAN or NVGRE) in the Wide Area Network (WAN) become
important since it can provide end to end connectivity.
When a packet traverses a set of overlay networks in the data path,
each overlay network will comprise an overlay segment used to connect
overlay nodes in the same network and these overlay segment are
stitched together to form end to end data path.
When any Overlay Segment fails to deliver user traffic, there is a
need to provide a tool that would enable users to detect such
failures, and a mechanism to isolate faults. It may also be
desirable to test the data path before mapping user traffic to the
Overlay Segment.
King, et al. Expires January 1, 2015 [Page 8]
Internet-Draft Multi-Layer OAM UC June 2014
3. Requirements
This section provides high-level requirements to fulfill transport
independent OAM in Multi-layer Environment to support various use
cases discussed in the previous sections.
o The interfaces between the management entity and each Managed
device in the transport network domain SHOULD support standards-
based abstraction with a common information/data model.
o The management entity should be able to create a single unified
view of OAM information that is common to various layers, various
domain and various operators.
o The following capability should be supported:
* Support customized service diagnostic.
* Support diagnose the availability of a End to End path.
* Support diagnose the availability of a segment Path that is
subpath of end to end path.
* Support verification on the correct value of Path ID between
any two pair of overlay nodes or any two pair of service nodes.
* Support verifying Overlay Control Plane and Data Plane
consistency at either two overlay nodes or two service nodes.
* Support local diagnostic procedures specific to each Service
Node.
* Support in-band liveliness and functionality checking
mechanisms for the overlay node or service node.
* Support Trace on the underlying network.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
TBD.
King, et al. Expires January 1, 2015 [Page 9]
Internet-Draft Multi-Layer OAM UC June 2014
6. Normative References
[I.D-quinn-sfc-problem-statement]
Quinn, P., "Network Service Chaining Problem Statement",
ID draft-quinn-nsc-problem-statement-03, August 2013.
[TIME-PS] Wu, Q., "Problem Statement and Architecture for Transport-
Independent Multiple Layer OAM", ID draft-ww-opsawg-multi-
layer-oam-01, June 2014.
Authors' Addresses
Daniel King
Old Dog Consulting
UK
Email: daniel@olddog.co.uk
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Sam Aldrin
Huawei Technologies USA
2330 Central Expressway
NSanta Clara, CA 95051
USA
Email: aldrin.ietf@gmail.com
Greg Mirsky
Ericsson
Email: gregory.mirsky@ericsson.com
King, et al. Expires January 1, 2015 [Page 10]
Internet-Draft Multi-Layer OAM UC June 2014
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
King, et al. Expires January 1, 2015 [Page 11]