| Operations and Management Area Working Group | D. King |
| Internet-Draft | Old Dog Consulting |
| Intended status: Informational | M. Boucadair |
| Expires: January 5, 2015 | France Telecom |
| S. Aldrin | |
| Huawei USA | |
| G. Mirsky | |
| Ericsson | |
| Q. Wu | |
| Huawei | |
| July 4, 2014 |
Use Cases and Requirements for Transport-Independent Multiple Layer OAM
draft-king-opsawg-time-multi-layer-oam-use-case-01
This document identifies and discusses use-cases and high level requirements for transport technology 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.
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 5, 2015.
Copyright (c) 2014 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.
This document 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 (e.g., network providers, data center providers, etc.) face multi-layer networks and diverse transport technologies, generic and integrated OAM is desirable for keeping network complexity down and simplifying O&M (OAM and O&M are used as specified in [RFC6291]).
This document is part of Transport Independent OAM in Multi-Layer Environment (TIME) effort which is meant to:
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].
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 [RFC2119].
Figure 1 illustrates a multi-layer network in which IP traffic between two customer edges is transported over both an IP/MPLS provider network and an Ethernet/MPLS provider network and multiple layers OAM 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 and MPLS 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.
Domain A Domain B
---------- ----------
//-IP/MPLS -\\ //Ethernet/MPLS
// \\ // \\
/ \ / \
|| || || ||
| | | |
+---+ +----+ +----+ +-------+ +----+ +----+ +---+
|CE |--| PE |------| P +---- | PE | ---- | P |-----| PE |--|CE |
+-+-+ +--+-+ +--+-+ +---+---+ +--+-+ +-+--+ +-+-+
| | | | | | | | | | |
| ||| | || | || | ||| |
| | | | | | | | |
| |\\ | // | \\ | //| |
| | \\- | -// | \\- | -// | |
| | ------+--- | -----+---- | |
L1 | |Ethernet OAM(CC,CV,etc.) | | |
o-------D-----------+--------+---o---+----------+---------D-------o
| | | | | | |
L2| | |IP OAM(Ping,|Traceroute, etc.) | |
o-------o-----------D-------- ---o--- ----------D---------o-------o
| | | | | | |
L?| Transport Independent OAM(Integrated Ethernet with IP OAM |
o-------o-----------D-------- ---o--- ----------D---------o-------o
| | | | | | |
| | | | | | |
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Figure 1: Multi-Domain Multi-Layer OAM
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 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 [IEEE-802.1Q] bridges a,b and c. Let's assume a,b and c are using [IEEE-802.1ag] 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/LBR) and fault isolation (LTM/LTR) tools, using the same API.
In Service Function Chain ([I-D.ietf-sfc-problem-statement]), 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 (see Figure 2).
+--------+
|Unified |
+---------------------------+OSS/NMS +---------------------------+
| +--------+ |
| SFC-enabled Domain A SFC-enabled Domain B |
| ---------- ---------- |
| // IP/MPLS -\\ //- IP/MPLS -\\ |
+----+ // \\ // \\ |
|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, Traceroute, 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--------------
Figure 2: OAM at Top of Layer 3
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 traffic and processed by a set of Service Functions that are hosted in Service Nodes and located in different layers at the top of layer 3.
When any Service 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 Node, the packet is processed by all SFs in the Service Node, Once the packet is successfully handled by one SF, the packet is forwarded to the next SF that is in the same Service Node.
When the packet leaves the network, the OAM information needs to be stripped out from the packet.
To provide unified view of OAM information common to different layers and different domains, 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-requirements], the following OAM functions are to be supported:
Other service diagnosis and troubleshooting requirements are discussed in [I-D.boucadair-sfc-requirements].
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.
Domain A Domain B
---------- ----------
//- IP/MPLS -\\ //- IP/MPLS -\\
// \\ // \\
/ \ / \
|| || || ||
| | | |
+---+ +----+ +----+ +----+ +----+ +----+ +----+ +---+
|CE |--| PE +------| P +----| PE +-+ PE +-----+ P +-----+ PE +--|CE |
+-+-+ +--+-+ +--+-+ +-+--+ +--+-+ +--+-+ +-+--+ +-+-+
| | | | | | | | | | | |
| ||| | ||| ||| | ||| |
| | | | | | | |
| |\\ | //| |\\ | //| |
| | \\- | -// | | \\- | -// | |
| | ------+--- | | -----+---- | |
L1 | |Ethernet OAM(CC,CV,etc) | | |
o-------D-----------+--------+-------+----------+---------D-------o
| | | | | | | |
| L2 | |IP OAM(Ping, Traceroute, etc.) |
o-----------D--------o-------o----------D---------o-
| | | | | |
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Figure 3: Overlay OAM
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 (Figure 3).
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.
This section identifies high-level requirements to fulfill transport independent OAM in Multi-layer Environment to support various use cases discussed in the previous sections.
This memo includes no request to IANA.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [TIME-PS] | Wu, Q., "Problem Statement and Architecture for Transport-Independent Multiple Layer OAM", ID draft-ww-opsawg-multi-layer-oam-01, June 2014. |