Internet DRAFT - draft-king-opsawg-lime-multi-layer-oam-use-case
draft-king-opsawg-lime-multi-layer-oam-use-case
Operations and Management Area Working Group D. King
Internet-Draft Lancaster University
Intended status: Informational M. Boucadair
Expires: March 25, 2014 France Telecom
S. Aldrin
Huawei USA
G. Mirsky
Ericsson
Mishael Wexler
Huawei
September 25, 2014
Use Cases and Requirements for Layer Independent OAM Management
in multi-layer environments
draft-king-opsawg-lime-multi-layer-oam-use-case-00
Abstract
As operators deploy and operate multi-layer networks and diverse
transport technologies, layer independent Operations, Maintenance &
Administration Management (OAM) would be beneficial for monitoring
and troubleshooting operations of network and service infrastructure.
This document identifies and discusses the key use-cases and high-
level requirements for layer independent Operations, Administration,
and Maintenance management to facilitate operations and maintenance
in multi-layer and multi-domain networks utilizing a wide variety of
heterogeneous networking technologies.
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 March 25, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
King, et al. Expires March, 2015 [Page 1]
Internet-Draft OAM Use Cases July 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3
2.1. Conventions used in this document . . . . . . . . . . . .3
2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . .3
3. Layer Independent OAM Management Use Cases . . . . . . . . .5
3.1. Multi-layer multi-region OAM Consolidation in the
Management Plane . . . . . . . . . . . . . . . . . . . .5
3.2. Multiple layer OAMs stitching in different part of the
network . . . . . . . . . . . . . . . . . . . . . . . . .6
3.3. Stitching OAM at layer requiring L4 to L7 service . . . .8
3.4. Multi-Region Overlay OAM Stitching . . . . . . . . . . .10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . .11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .12
6. Security Considerations . . . . . . . . . . . . . . . . . . .12
7. References . . . . . . . . . . . . . . . . . . . . . . . . .12
7.1. Normative References . . . . . . . . . . . . . . . . . .12
7.2. Informative References . . . . . . . . . . . . . . . . .12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .13
Contributor's Addresses . . . . . . . . . . . . . . . . . . . . .14
1. Introduction
This document discusses use-cases for layer independent OAM
management that would interface to multi-layer or multi-domain
networks to cover various heterogeneous networking technologies.
As operators and providers (e.g., network operators, data center
operators, service providers, etc.) continue to deploy and operate
multi-layer networks using a wide range of transport technologies,
layer independent OAM Management for stitching different layer OAMs
is desirable to minimise operational complexity and simplifying O&M
(OAM and O&M are used as specified in [RFC6291]).
This document discusses Layer Independent OAM in Multi-Layer
Environment (LIME), and is intended to:
o outline use cases for layer independent OAM management
and highlight the issues encountered with existing OAM
protocols;
King, et al. Expires March, 2015 [Page 2]
Internet-Draft OAM Use Cases July 2014
o discuss OAM requirements for when designing and deploying new
technologies;
o outline eixsting technologies to facilitate layer independent OAM
management, including MEF work, ITU-T work, IETF related work;
o discuss how OAM might be configured via a unified management
interface:
* Establishment of OAM Entities(e.g., MEG, ME,MIP,MEP) and
Functions(e.g.,CC,CV)
* Adjustment of OAM Parameters
* Deleting OAM Entities
o highlight a generic OAM Management model that may be applied to
various OAM technologies:
* Defining common objects and relationships model for various
technologies
* Defining a common set of methods/calls to use for the various
functions
* Defining a common set of attributes per object
* Defining a common set of alarms and notifications
Specific OAM technology models will augment the basic OAM
management model defined by the LIME Group.
o detail OAM fault management(e.g., fault location, path
discovery) data model using layer independent OAM Management:
* Propose means to help during service diagnosis; these means may
rely on filtering information 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
the overlay but also at the underlay.
o discuss the security model for layer independent OAM management:
* Propose means to avoid leaking OAM information to no authorized
entities, and to avoid altering OAM information exposed by each
King, et al. Expires March, 2015 [Page 3]
Internet-Draft OAM Use Cases July 2014
layer.
* Propose means to ensure reliability of OAM information exposed
by each layer.
These requirements 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 [LIME-PS].
2. Terminology
2.1. 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 RFC2119 [RFC2119].
2.2. Acronyms and Abbreviations
LIME - Layer Independent OAM in Multi-Layer Environment
OAM - Operations, Administration, and Maintenance
O&M - OAM and Management
ABNO -Application Based Network Operation
MEG - Maintenance Entity Group [RFC6371]
MEP - Maintenance Entity Group End Point [RFC6371]
MIP - Maintenance Entity Group Intermediate Point [RFC6371]
CC -Continuity Check [RFC7276]
CV - Connectivity Verification [RFC7276]
CFM -Connectivity Fault Management
EFM - Ethernet In the First Mile
BFD -Bidirectional Forwarding Detect
LBM -Loopback Message
LBR -Loopback Reply
LTM -Linktrace Message
King, et al. Expires March, 2015 [Page 4]
Internet-Draft OAM Use Cases July 2014
LTR -Linktrace Reply
OSS -Operation Support System
NMS -Network Management System
SFC -Service Function Chain [I-D.ietf-sfc-problem-statement]
SF - Service Function [I-D.ietf-sfc-problem-statement]
TES -Tenant End System [I-D.ietf-nvo3-framework ]
NVO3 -Network Virtualization Overlay [I-D.ietf-nvo3-overlay-
problem-statement]
WAN -Wide Area Network
VXLAN -Virtual eXtensible Local Area Network [RFC7348]
NVGRE -Network Virtualization using Generic Routing Encapsulation
[I-D.sridharan-virtualization-nvgre]
PW -Pseudowire
LSP -Label Switching Path
MPLS -Multi-Protocol Label Switching
3. Layer Independent OAM Management Use Cases
3.1. Multi-layer multi-region OAM Consolidation in the Management Plane
A multi-layer multi-region network will often require data traffic
between two customer edges to be transported across two regions, as
illustrated in figure 2. In this scenario the same domain and
multiple layer OAMs(i.e.,PW OAM,end to end LSP OAM, segment LSP OAM)
are used.
For PW OAM is used at the customer level for monitoring the end-to
-end connection between the two Provider edges(PEs), while end to end
LSP OAM and segment LSP OAM is used at the provider level for
monitoring the segment LSP and end to end LSP respectively. A
segment is between MEPs and The OAM in each segment is independent of
any other segment.
King, et al. Expires March, 2015 [Page 5]
Internet-Draft OAM Use Cases July 2014
+--------------------------------------------------+
| Carrier 1 |
|+---------------------+ +---------------------+|
|| Region1 | | Region2 ||
+----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+
| PE ------| PE --|P|--| PE ----------| PE ----|P|--| PE ------| PE |
+----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+
|| | | ||
|+---------------------+ +---------------------+|
+--------------------------------------------------+
End to end LSP OAM
o----------D----------------------------------------D----------D
Segment LSP
Carrier 1 LSP OAM segment OAM
o------------D-------------D-------------o-o--------o
Carrier1 Region 1 Carrier1 Region 2
LSP OAM segment LSP OAM segment
o----D-------o o-------D------o
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Figure 1: Multi-Region Multi-Layer OAM
With single OSS/NMS in the management plane, customized service
diagnose can be provided, e.g.,
o initiating tests on any layer in the multi-layer network
o initiating test on any segment of the end to end path
o initiate test on end to end path
o check end-to-end connectivity test results across a multi-layer
network even when each layer runs a different technology.
3.2. Multiple layer OAMs stitching in different part of the network
Figure 2 illustrates a multi-layer network in which data traffic
between two access nodes is transported through access section
between access node(AN) and aggregation node(AGG Node) and
aggregation section between aggregation node and edge node and even
core section from edge node to Internet or WAN. EFM OAM is used at
the access section for monitoring the access connection between the
access node and aggregation node, CFM OAM and IP OAM is used at the
aggregation section for monitoring end to end connection between
aggregation node and edge node. BFD is used at the core section for
monitoring end to end connection from edge node to Internet or WAN.
King, et al. Expires March, 2015 [Page 6]
Internet-Draft OAM Use Cases July 2014
| | | |
----EFM---------CFM/IP-----------BFD---------|
| | | |
+---|----------|---+ | |
| +----+ +-----+| | |
| | AN | |AGG +---+ | |
| +----+ |Node || | | |
| +-----+| | +------+ +-----+ /-----\
+------------------+ | | Edge +---+Core |++|Internet|
---| Node | |Node | | |
+------------------+ | +------+ +-----+ \-----/
| ------ |AGG || |
| | AN | |Node +---+
| +----+ +-----+| |
| +----+ +-----+| |
| | AN | |AGG || |
| +----+ |Node +---- +-------+ +-----+ /----\
| +-----+| | | Edge +--+Core |+-+| WAN ||
+------------------+ --- Node | |Node | | |
+------------------+ | +-------+ +-----+ \----/
| +-----+| | | |
| +----+ |AGG +---+ | |
| | AN | |Node || | |
| +----+ +-----+| | |
+---|----------|---+ | |
| | | |
----Access---Aggregation-| -----Core----------
| | | |
Figure 2
With single OSS/NMS in the management plane, different layer OAM at
the different part of the network can be stitching together to
provide unified view for network problem reporting by consuming all
status reports from the network, aggregating them, correlating them.
In addition, a user who wishes to issue a IP Ping Command or use
connectivity verification command in the Ethernet layer can do so in
the same manner regardless of the underlying protocol or transport
technology. This can be achieved by invoking IP Ping Command or
connectivity verification command through uniform interface between
management plane and data plane. Consider a scenario where an IP
ping to Edge node B from Aggregation node A failed. Between AGG node
A and Edge Node 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. IP layer
Ping can be invoked using uniform interface between single OSS/NMS
and AGG node A. 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 uniform interface used by IP Layer Ping.
King, et al. Expires March, 2015 [Page 7]
Internet-Draft OAM Use Cases July 2014
3.3. Stitching OAM at layer requiring L4 to L7 service
In Service Function Chain ([I-D.ietf-sfc-problem-statement]), the
service packets are steered through a set of Service Function
distributed in the network. Overlay technologies and other tunneling
techniques can be used to stitch these Service Function Nodes in
order to form end to end path (see Figure 3).
+---------+
| Single |
|----------------------| OSS/NMS -------------------------
| +---------+ |
| |
| ---------------------- |
| /////-- --\\\\\ |
| ///// \\\\\ |
| //// |->SF1 SF2-+ SF3----+ +->Proxy-SF4 \\\\ |
|/ | | ^ | ^ | | \|
| V | | | | |
+-------+ | +---+-+ | +-+---+ | | +-----+ +-----+
| SFC | |--| +<+ | |<- |->| | | |
|Ingress|------ NE-a -------+NE-b +------- NE-c --------+NE-d |
| Node | | | | | | | | |
+-------+ +-----+ +-----+ +-----+ +-----+
\\\\ ////
\\\\\ /////
\\\\\-- --/////
----------------------
SF OAM
o o o o D
SFC OAM
o-------------D---D-----------D-------------D
NVO3 OAM
o---------------o----------------D----------D----------------o
Link OAM
o--o---o--o- o---o o--o--o--o
o Maintenance Endpoint(MEP)
D Maintenance Intermediary point (MIP)
Layer7- SF1 ---------------------------------------------------
Layer6------------------------F4 --------------------------------
Layer5------------ SF3-------------------------------------------
Layer4---SF2 ---------------------------------- -----------------
Figure 3: Stitching OAM at layer requiring L4 to L7 service
King, et al. Expires March, 2015 [Page 8]
Internet-Draft OAM Use Cases July 2014
In figure 3, Link OAM is used between any two adjacent SFs hosted in
the same service node in the SFC layer or between a SF and the
service node hosting that SF. NVO3 OAM is used between SFC ingress
node and NVO3-enabled Network element or any two NVO3-enabled network
element in the SFC domain. SFC OAM is used between a set of Service
Functions belong to the same service function chain in the SFC
domain. SF OAM is used between SF and SF Controller.
When the service packet enters into the network, OAM information
needs to be imposed by ingress node of the network into the OAM
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 requiring L4-L7
service.
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 (e.g., fault
element in the path), 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 from different layers and
different segment of the Service Function Path, 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 uniform management interface.
As indicated in [I-D.boucadair-sfc-requirements], 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-
enabled domain.
o Support means to correlate classification policies with observed
forwarding actions.
King, et al. Expires March, 2015 [Page 9]
Internet-Draft OAM Use Cases July 2014
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-requirements].
3.4. Multi-Operator OAM Stitching
Multi-operator networks can be abstracted, virtualized and shared by
several tenants. A tenant has an end-to-end view of its virtual
network. Figure 5 illustrates an example of multi-layer
multi-operator network in which data traffic between two tenant
systems is transported across three operators.
+--------+
-----------------------------+ Tenant +-----------------------------
| | | |
| +--------+ |
| | |
| + - - - - - - + |
| | Abstraction | |
| - - - --- - - - - | Layer (opt.)| - - - - - - - - |
| | + - - - - - - + | |
| | | | |
| +--------+ +--------+ +--------+ |
| + Single + + Single + + Single + |
| |OSS/NMS | |OSS/NMS | |OSS/NMS | |
| +--------+ +--------+ +--------+ |
| --------- --------- --------- |
| /// \\\ /// \\\ /// \\\ |
| / \ / \ / \ |
| | | | | | | |
+-----+ +-----+ +-----+ +----+ +-----+ +-----+
| A1 | | A2 | | B1 | | B2 | | C1 | | C2 |
+-----+ +-----+ +-----+ +----+ +-----+ +-----+
| | | | | |
\ / \ / \ /
\\\ /// \\\ /// \\\ ///
--------- --------- ---------
Oper A Oper B Oper C
o-------------D----------D---------------D----D-----------------o
Figure 4: Multi-Operator OAM Stitching
Each operator is using a different management system and is handling
only a segment of the whole end-to-end service. Each operator can
also use a different technology to transport the clients over its
King, et al. Expires March, 2015 [Page 10]
Internet-Draft OAM Use Cases July 2014
segment. Within one operator region, multi-layers acn be used, e.g.
IP over WDM to transport L3VPN service.
The tenants has to view an end-to-end OAM model via abstraction of
each region and/or using abstraction layer between tenants and the
OSS/NMSs.
4. Requirements
This section identifies high-level requirements to fulfill layer
independent OAM management 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 one administrative 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
segment of the same domain.
o The management entity should provide an unified management
interface for multiple OAM technologies that will expose a common
set of management interface capabilities for different OAM
technologies (e.g. Continuity Check(CC),Connectivity
Verification(CV)). The management interface implementation will
convert the defined common management capabilities to the OAM
technology specific operations.
o The management entity should Model OAM operations management and
represent OAM information and mechanisms in the same way using
YANG at the management plane to provide consistent configuration,
reporting, and presentation for the OAM mechanisms. Specific OAM
technology models will augment the basic OAM management model
defined by the LIME Group.
o The following capability for layer independent OAM management
entity 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
sub-path 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.
King, et al. Expires March, 2015 [Page 11]
Internet-Draft OAM Use Cases July 2014
* Support out-band liveliness and functionality checking
mechanisms for the overlay node or service node.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
7.2. Informative References
[I-D.boucadair-sfc-requirements]
Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R.,
Pignataro, C., and K. Kengo, "Requirements for Service
Function Chaining (SFC)", draft-boucadair-sfc-
requirements-05 (work in progress), July 2014.
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-10
(work in progress), August 2014.
[IEEE-802.1Q]
IEEE 802.1Q-2011, "IEEE standard for local and
metropolitan area networks: Media access control (MAC)
bridges and virtual bridged local area networks", August
2011.
[IEEE-802.1ag]
IEEE 802.1ag-2007, "IEEE Standard for Local and
Metropolitan Area Networks Virtual Bridged Local Area
Networks Amendment 5: Connectivity Fault Management",
December 2007.
[LIME-PS] Taylor, T. and Q. Wu, "Problem Statement and Architecture
for Layer-Independent OAM in Multi-Layer Environment", ID
draft-edprop-opsawg-multi-layer-oam-ps-01, (work in
progress).
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC
5706, November 2009.
King, et al. Expires March, 2015 [Page 12]
Internet-Draft OAM Use Cases July 2014
[RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D.,
and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", RFC 6291, June 2011.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC7276] Mizrahi, T. et al., "An Overview of Operations,
Administration, and Maintenance (OAM) Tools," June 2014
[RFC7348]
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang,
Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P.,
and C. Tumuluri, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-
virtualization-nvgre-05 (work in progress).
Authors' Addresses
Daniel King
Lancaster University
UK
Email: d.king@lancaster.ac.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 March, 2015 [Page 13]
Internet-Draft OAM Use Cases July 2014
Mishael Wexler
Huawei
Riesstr. 25
Munich 80992
Germany
Email: mishael.wexler@huawei.com
Contributors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
King, et al. Expires March, 2015 [Page 14]
Internet-Draft OAM Use Cases July 2014
