One document matched: draft-edprop-opsawg-multi-layer-oam-ps-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1157 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY RFC3410 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY RFC4176 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4176.xml">
<!ENTITY RFC4379 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4443 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4443.xml">
<!ENTITY RFC4656 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4656.xml">
<!ENTITY RFC5357 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5357.xml">
<!ENTITY RFC5706 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5706.xml">
<!ENTITY RFC5880 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5880.xml">
<!ENTITY RFC6020 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
<!ENTITY RFC6123 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6123.xml">
<!ENTITY RFC6241 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6291 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6291.xml">
<!ENTITY RFC6310 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6310.xml">
<!ENTITY RFC6374 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6374.xml">
<!ENTITY RFC6378 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6378.xml">
<!ENTITY RFC6428 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6428.xml">
<!ENTITY RFC7023 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7023.xml">
<!ENTITY RFC7276 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.7276.xml">
]>
<rfc category="info" docName="draft-edprop-opsawg-multi-layer-oam-ps-00.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Layer Independent OAM">Problem Statement for Layer
and Technology Independent OAM in a Multi-Layer Environment</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Mishael Wexler" initials="M." surname="Wexler">
<organization>Huawei</organization>
<address>
<postal>
<street>Riesstr. 25</street>
<region>Munich</region>
<code>80992</code>
<country>Germany</country>
</postal>
<email>mishael.wexler@huawei.com</email>
</address>
</author>
<author initials="T." surname="Taylor" fullname="T. Taylor"
role="editor">
<organization>PT Taylor Consulting</organization>
<address>
<postal>
<street></street>
<city>Ottawa</city>
<region></region>
<code></code>
<country>Canada</country>
</postal>
<phone></phone>
<email>tom.taylor.stds@gmail.com</email>
</address>
</author>
<date year="2014"/>
<area>OPS</area>
<workgroup>Operations and Management Area Working Group</workgroup>
<keyword>Multi-Layer OAM </keyword>
<keyword>Technology Independent</keyword>
<abstract>
<t>Operations, Administration, and Maintenance (OAM) mechanisms are
critical building blocks in network operations. They used for service
fulfillment assurance, and for service diagnosis, troubleshooting, and
repair. The current practice is that many technologies rely on their own
OAM protocols and procedures that are exclusive to a given layer.
</t>
<t>At present, there is little consolidation of OAM in the management
plane or well-documented inter-layer OAM operation. Vendors and operators
dedicate significant resources and effort through the whole OAM life-cycle
each time a new technology is introduced. This is exacerbated when dealing
with integration of OAM into overlay networks, which require better OAM
visibility since there is no method to exchange OAM information between
overlay and underlay.</t>
<t>This document analyzes the problem space for multi-layer OAM in the
management plane with a focus on layer and technology independent OAM
management considerations. It concludes that an attempt to define an
architecture for consolidated management should be undertaken, and if this
attempt satisfies key objectives, a gap analysis and a program of
standardization should follow.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Operations, Administration, and Maintenance (OAM, <xref
target="RFC6291"/>) mechanisms are critical tools, used for service
assurance, fulfillment, or service diagnosis, troubleshooting, and repair,
as well as supporting functions such as accounting and security
management. The key foundations of OAM and its functional roles in
monitoring and diagnosing the behavior of networks have been studied at
OSI layers 1, 2 and 3 for many years. </t>
<t>When operating networks with more than one technology in an overlay
network, maintenance and troubleshooting are achieved per technology and
per layer. As a result, operational processes can be very cumbersome.
Stitching together the OAM of adjacent transport segments (as defined
in <xref target="terms"/> in one administrative domain is often not
defined and left to proprietary solutions. </t>
<t>Current practice, which consists in enabling specific OAM techniques
for each layer, has shown its limits. Concretely, we see today a large
number of layer 1/2/3 OAM protocols being well developed and some of them
being successfully deployed, but how these OAM protocols in each layer can
be applied to overlay networks that are using different encapsulation
protocols so as to provide better OAM visibility is still a challenging
issue. When no mechanism is defined to exchange performance and
liveliness information between the underlay and overlay(s) by a
coordination system, it is hard, for instance, to determine whether a
fault originates in higher or lower layer.</t>
<t>Section 1.1 of <xref target="RFC7276"/> makes the point that
each layer in a multi-layer architecture has its own OAM protocols.
From this follows the basic principle that OAM in the data plane
cannot cross layer boundaries. A similar constraint holds for
boundaries between different transport technologies in the same layer,
barring the stitching mentioned above.</t>
<t>One concludes that to simplify OAM and make it more responsive in a
multi-layer network requires further consolidation in the management
plane. The work on management consolidation would benefit from at least
some new standardization. A detailed examination of the potential scope of
the work is left for a gap analysis following successful definition of an
architecture.
</t>
<t>This document further argues that in addition to the ability to
retrieve technology specific information from managed entities when
following up on problems, consolidated management requires
a technology independent view of the network and supporting
layers. How this view is obtained is a key architectural issue outside
the scope of the present document.</t>
<section anchor="vision" title="A Vision of Layer and Technology
Independent Management">
<t>What follows is based on the assumption of a network supported by a
strict hierarchy of underlying layers in the data plane. There may be
multiple layers at a given level of the OSI layer 1-2-3 hierarchy, but
that is irrelevant to the vision.</t>
<t>A management application presents to an user a view of this network
and its supporting layers that is strictly topological, free of any
technology specific information. The user notes a defect along a path
serving a particular customer. Looking at the next lower path, the
user also sees a defect. Looking the next lower path again, there is
also a defect. No lower defect is noted.</t>
<t>At this point it is appropriate to indicate what the user can see
along a given path. The path is divided into one or more segments,
each spanned by a specific transport technology. However, as already
stated, the user does not see any technology specific information.
Instead, as well as distinguishing the segments, the user can identify
the managed elements at the beginning and end of each segment.</t>
<t>To clarify the situation, the user issues an abstract Continuity
Check command, directed toward the initial managed element of the
segment in which a fault appears to lie (i.e., in the lowest layer
where a defect was observed). By means to be determined by
architectural choice, this command is converted into a technology-
specific request which is executed across the selected segment.
Possible outcomes include:
<list style="numbers">
<t>The fault could come clear as a result of the test. The
immediate problem is solved (and may have affected multiple upper
paths besides the one of initial interest) and the point at which it
occurred could be flagged for follow-up maintenance.</t>
<t>Local craft action to clear the fault is available in timely
fashion. </t>
<t>Timely local craft action is not possible, and capacity is
reallocated on other paths to ensure that service levels are
maintained. Note that capacity reallocation can be done based on the
topological view of the network, still on a layer and technology
independent basis.</t>
</list></t>
<t>In case (2), technology specific management capabilities are likely
to be required by the craftperson following up on the problem.</t>
</section> <!-- vision -->
<section anchor="forward" title="Looking Forward">
<t>The remainder of this document develops the ideas just stated
at a greater level of detail. <xref target="terms"/> provides
terminology
that is important to the understanding of the rest of the document.
<xref target="preObject"/> establishes preliminary objectives that
are key to determining whether a complete program of standardization
of consolidated management should be undertaken. <xref target="psAnal"/>
provides the problem analysis. It is divided into three parts: an
argument
for consolidated management (<xref target="argConsol"/>), an argument
for
layer and technology independent management (<xref target="argLITI"/>),
and an examination of some more detailed issues. <xref target="psStat"/>
provides the problem statement, and <xref target="archCons"/> provides
some considerations that should be taken into account in the proposed
work on architecture.
</t>
</section> <!-- forward -->
</section> <!-- intro -->
<section anchor="terms" title="Terminology">
<t><xref target="RFC6291"/>, cited above, provides the official IETF
description of Operations, Administration, and Maintenance (OAM)
terminology. For a more extensive description of OAM and related terms,
see the opening sections, but particularly
Sections 2.2.1 through 2.2.3, of <xref target="RFC7276"/>.</t>
<t>Section 2.2.4 of <xref target="RFC7276"/> introduces the terms data
plane, control plane, and management plane.</t>
<t>This document introduces its own interpretation of the following
terms, which are in wide use but in that general usage present
ambiguities:
<list style="hanging">
<t hangText="Management:"><vspace blankLines="1"/>
A definition of management can be inferred from <xref
target="RFC6123"/>, which in turn refers to <xref target="RFC5706"/>.
Unfortunately the latter chose to divide operations from management, at
least from a documentation point of view. The present document chooses
to define management as a function that is concerned with all three of
operations, administration, and maintenance.</t>
<t hangText="Layer:"><vspace blankLines="1"/>
The word "layer" has two potential meanings. In the first instance, it
is a topological concept, representing a position in a hierarchy of
layers. In the second instance, it refers to OSI layers 1, 2 and 3.
Within this document, "layer independent OAM management" as defined
below emphasizes the latter meaning when talking about independence, but
is intended to extend to all layers of the hierarchy supporting a given
network or overlay (the topological view of "layer").</t>
</list></t>
<t>This document makes use of the following additional terms:
<list style="hanging">
<t hangText="Layer independent OAM management:">
<vspace blankLines="1"/>
In a multi-layer network, layer independent OAM
management refers to OAM in the management plane that can be
deployed independently of media, data protocols, and routing
protocols. It denotes the ability to gather OAM information at the
different layers, correlate it with layer-specific identifiers
and expose it to the management application through a unified
interface.</t>
<t hangText="Managed entity:"><vspace blankLines="1"/> An architectural
concept, an instance of what the management function manages. By
definition, a managed entity is capable of communicating with the
management function in the management plane.</t>
<t hangText="Local Management Entity (LMgmtE):">
<vspace blankLines="1"/>
An instance of a management function that is restricted in scope to
communication with the managed entities associated with a specific
transport segment in a specific layer. This term includes legacy
management entities in an existing network, and may include entities of
a similar scope if they are defined in a consolidated management
architecture. </t>
<t hangText="Consolidated Management Entity (CMgmtE):">
<vspace blankLines="1"/>
An instance of the management function that is capable of communicating
with all of the LMgmtEs and/or managed entities in a scoped part of the
network in order to achieve end-to-end and service-level views of
network performance and status and initiate actions when required. The
phrase "LMgmtEs and/or managed entities" allows for the possibility that
the target architecture allows for direct communication between the
CMgmtE and the managed entities or alternatively chooses to assume a
distributed management architecture. In any case, as discussed
in <xref target="archCons"/>,
the CMgmtE will have to communicate with legacy LMgmtEs during the
transition from the existing to the target architecture.</t>
<t hangText="Management subsystem:"><vspace blankLines="1"/>
The implementation of the management function in a given network.</t>
<t hangText="Managed device:"><vspace blankLines="1"/>
A network element associated with at least one technology layer and one
managed entity.</t>
<t hangText="Transport segment:"><vspace blankLines="1"/>
Refers to the portion of a path at a given layer bounded by
two points between which a specific transport technology
is used and beyond which either a different technology is
used or the path is terminated.</t>
<t hangText="Three-dimensional topology:"><vspace blankLines="1"/>
Refers to a three-dimensional view of the topology of the network and
supporting layers. The view of paths along a layer comprises two
dimensions. The third dimension is provided by the ordered hierarchy of
layers from bottom to top at any point along a path.
The three-dimensional topology includes per-path capacity and flow
information, permitting layer and technology independent reallocation
of capacity as required.</t>
</list></t>
</section> <!-- terms -->
<section anchor="preObject" title="A Preliminary Set Of Objectives">
<t>Before going further, it is possible to state a preliminary set of
objectives for this work. If it does not appear that these can be
satisfied, there is no point in undertaking further effort.</t>
<t>As a first objective, the outcome of the work must reduce
the time required to respond to and mitigate service-affecting
events. The ideal result is that the system be able to do so
before the customer notices a service degradation. It is possible
that satisfaction of this objective alone is sufficient to carry on.</t>
<t>A second objective relates to the business case for the work
and is more difficult for the IETF to judge but crucial for
operators attempting to justify changes in their network infrastructure.
It should be possible to expect a reduction in life cycle capex and
opex as a result of making those changes, even taking account of the
potential costs of abandoning or upgrading existing equipment. This
objective may influence work on architecture for consolidated management
toward minimizing those latter costs (capex). On the positive side, likely
savings in craftsperson time implied by the first objective are helpful to
the business case (opex).</t>
<t>At a more detailed level, the outcome of the work must allow management
to have end-to-end and service-level views of network performance, down to
the granularity of service instance. Pre-supposing the arguments made
in <xref target="argLITI"/>, it must also allow management to have a
layer and technology independent view of the network, at least in the
form of the three-dimensional topology, as defined in <xref
target="terms"/>. </t>
</section> <!-- preObject -->
<section anchor="psAnal" title="Analysis of the Problem">
<section anchor="argConsol" title="Argument For Consolidated Management">
<t>Multi-layer OAM actually presents two separate but inter-related
issues. The first is technology dependency, at the same or
different layers. The second is correlation of events between
layers.</t>
<t>OAM mechanisms have a strong technology dependency because each
technology (or layer) has its best suited OAM tools. Some of them
provide rich functionality with one protocol, while the others provide
each function with a different protocol. Today a variety of OAM tools
have been developed by different Standards Development Organizations
(SDOs) for Optical Transport Network (OTN), Synchronous Digital
Hierarchy (SDH), Ethernet, MPLS, and IP networks. </t>
<t>However, orchestrating and coordinating OAM in multi-layer networks
to provide better network visibility and efficient OAM operations is
still a challenging issue since no mechanisms are defined, for example,
to exchange performance and liveliness information between different
layers. This means that the required coordination has to happen in the
management function through communication with the managed entities.</t>
<t>The development of overlay networks, where one network is the
client of another, adds to the magnitude of the problem. To take a
specific example, in the Service Function Chaining (SFC) <xref
target="I.D-ietf-sfc-problem-statement"/> environment, every Service
Function (SF) may operate at a different layer and may use a different
encapsulation scheme. When taking into account overlay technologies, the
number of encapsulation options increases even more.</t>
<t>At this point, it is useful to recall the preliminary objectives
stated in <xref target="preObject"/>. To achieve end-to-end and
service-level views of network performance requires that the management
function be capable of receiving and reacting to related information
from every transport segment at every layer in the network. This is a
working definition of consolidated management. </t>
<t>A key issue with "management consolidation" is that it may include
a requirement for management to interact with every technology used in
the network on a per-technology basis either initially or when it has
to follow up on detected problems by collecting detailed information.
It is an architectural challenge beyond the scope of this document to
determine whether consolidated management then becomes an aggregation of
local managers of legacy type tied together by a coordination function,
or whether simplifications are possible. </t>
</section> <!-- argConsol -->
<section anchor="argLITI" title="Argument For Layer and Technology
Independent Management">
<t>The argument for consolidated management to have a layer and
technology independent view of the network and supporting layers is
two-pronged. The first argument is fairly straightforward and initially
independent of architectural considerations. Some management functions
are concerned solely with the topology of the network and supporting
layers as represented by the three-dimensional topology defined in
<xref target="terms"/>. These include network optimization, efficient
enforcement of Traffic Engineering (TE) techniques including assurance
of path diversity in one layer and over the complete hierarchy of
layers, and fine-grained tweaking. Even in this case management action
may require interaction with the managed elements at a
technology-specific level, barring an alternative architectural
solution.</t>
<t>The second argument for a layer and technology independent view
involves considerably more substance than the first one. The
three-dimensional topology would be a starting point for this view, but
in addition it would include an abstracted view of service-affecting or
potentially service-affecting events, identified by layer and reporting
managed device. This allows management to correlate events in different
layers and identify the devices from which it must seek further
information or to which it must direct other requests, without being
burdened with excess information. The intention is to ease root cause
analysis and improve the ability to maintain end-to-end and
service-level visibility.</t>
<t>Where this second version of a technology independent view is
created is an architectural issue, beyond the scope of the present
document. One possibility is that the work is all done in the
"consolidated management" function, in which case the latter
just becomes an aggregation of legacy technology-specific managers
tied together by a coordination function, as mentioned above.
A contrasting possibility is that the managed devices
also support the abstraction, with a view to minimizing the amount
of technology specific information and management actions the management
function has to support.</t>
</section> <!-- argLITI -->
<section anchor="details" title="Detailed Issues">
<section title="Strong Technology Dependency For MIB Modules"
anchor="techDep">
<t>OAM protocols rely heavily on the specific network technology they
are associated with. For example, ICMPv6 <xref target="RFC4443"/> and
LSP Ping <xref target="RFC4379"/> provide the same OAM functionality,
path discovery, for IPv6 and MPLS Label Switched Path (LSP)
technologies respectively.</t>
<t>SNMP MIB modules to manage these protocols were developed on a per
OAM protocol basis. As a result, there was little reuse of MIB modules
for other existing OAM protocols. To the extent that management
operations are being redesigned in terms of YANG modules <xref
target="RFC6020"/> over NETCONF <xref target="RFC6241"/>, the
opportunity exists to use the concept of layer and technology
independent abstraction to extract the reusable parts, simplifying the
work on the remainder. </t>
</section> <!-- techDep -->
<section title="Issues of Abstraction" anchor="abstrIss">
<t>In a multi-layer network, OAM functions are enabled at different
layers and OAM information needs to be gathered from various
layers independently. Without multi-layer OAM in place, it is hard for
management applications to understand what information (e.g., Context,
OAM functionalities) at different layers stands for and have a unified
view of OAM information at different layers. A mechanism is required
to provide this information to management.</t>
<t>The challenge is to abstract in a way that retains in the
management plane as much useful information as possible while
filtering the data that is not needed. An important part of this
effort is a clear understanding of what information is actually
needed. There is a close relationship between this issue and
the issue already identified in the previous section.</t>
</section> <!-- abstrIss -->
<section title="OAM Interworking Issues" anchor="OAMinter">
<t>When multiple layer OAMs are used in the different parts of the
network, two layer OAMs interworking at the boundaries need to be
considered:
<list style="symbols">
<t>How one layer OAM in given part of the network interworks with
another layer OAM in another part of the network operated by the
same administrative entity through a consolidated management
interface? e.g., E-LMI used in UNI interworks with Ethernet link OAM
used on an IEEE 802.3 link in the same domain?</t>
<t>How one layer OAM interworks with another layer OAM in the same
part of the network through a conssolidated management interface?
e.g., Ethernet OAM interworks with MPLS OAM in the same part of the
network? In this case, Ethernet OAM and MPLS OAM are both supported
by the same two managed devices in communication.</t>
</list></t>
<t>In these cases, mapping and notifications of defect states between
different layer OAMs is required at the boundary nodes of the two
parts of the network <xref target="RFC6310"/> <xref
target="RFC7023"/> <xref target="I-D.ietf-l2vpn-vpws-iw-oam"/>.
Management must provide the interworking
function to establish dynamic mapping and translation, supervise
defects, and suppress alarms. [Issue for debate. The original
text from draft-ww-oamwg provides for a separate interworking
function. To me, that violates the concept of consolidated
management. Maybe this is a case of local versus consolidated
management as discussed in <xref target="archCons"/> --
PTT as individual contributor]</t>
</section> <!-- OAMinter -->
<section title="Multiple (ECMP) Paths OAM Issue" anchor="ECMP">
<t>Network devices typically use fields in the MAC or IP header or
MPLS header and perform hash computations (e.g., 5-tuple hash
consisting of IP protocol, source address, destination address, source
port, and destination port) on these packet header fields to classify
packets into flows and select the forwarding path for the flow among
multiple equal cost paths, ECMP becomes more important when network
overlay, service chain technology are introduced, e.g., in case of
multi-instances of the same service function is invoked for a given
chain to provide redundancy, how 5-tuple hash is used based on
contents in the outer headers and inner encapsulated packet.</t>
<t>Multiple path OAM requires that Connectivity Check and Continuity
Check must follow the same path as the data traffic (e.g., TCP traffic
and UDP traffic). Overlay encapsulation allows OAM data to piggyback
packets, in the way record route is used in IPv4 options. However,
there is no standard way to exercise end to end continuity and
connectivity verification that covers all of ECMP paths in the IP
networks. Such a standard is desirable.</t>
</section> <!-- ECMP -->
</section> <!-- details -->
</section> <!-- psAnal -->
<section anchor="psStat" title="Problem Statement">
<t>OAM functions are used heavily during service and network life-cycle.
Today, OAM management requires expertise due to technology dependency
despite the similarity in functions (adding to CAPEX and OPEX).
Troubleshooting is cumbersome due to protocol variety and lack of multi-
layer OAM. This requires expertise and long troubleshooting cycles (OPEX).
Last but not least, today's various management interfaces make it
difficult to accept and introduce new protocols and technologies</t>
<t>There is value in attempting to define an architecture for consolidated
management that may reasonably be argued to meet the objectives stated in
<xref target="preObject"/>. If this attempt succeeds, it can be followed
up with a gap analysis, which in turn will define a further program of
standardization.</t>
<t>At the detailed level, <xref target="techDep"/> and <xref
target="abstrIss"/> deal with the matter of abstraction and its
relationship to the specification of YANG modules. This is work beyond the
initial definition of architecture and awaits justification and
prioritization by the gap analysis. A similar consideration relates to the
solution to the ECMP problem.</t>
<t>The remaining issue is the OAM interworking issue identified in
<xref target="OAMinter"/>. This is architectural in nature, and should
be addressed by the proposed work on architecture.</t>
</section> <!-- psStat -->
<section anchor="archCons" title="Considerations For the Work On
Architecture">
<t>Definition of an architecture for consolidated management is beyond
the scope of the present document. This section instead provides
considerations that should be taken into account when defining such an
architecture. </t>
<section anchor="archTerm" title="Terminology">
<t>The following entities are defined strictly for purposes of the
present discussion. This terminology is not meant to restrict other work
in any way. This section also uses the term "managed entity" defined
in <xref target="terms"/>.
<list style="hanging">
<t hangText="Local Management Entity (LMgmtE):">
<vspace blankLines="1"/>
An instance of a management function that is restricted in scope to
communication with the managed entities associated with a specific
transport segment in a specific layer. This term includes legacy
management entities in an existing network, and may include entities
of
a similar scope if they are defined in the consolidated management
architecture. </t>
<t hangText="Consolidated Management Entity (CMgmtE):">
<vspace blankLines="1"/>
An instance of the management function that is capable of
communicating with all of the LMgmtEs and/or managed entities in a
scoped part of the network in order to achieve end-to-end and
service-level views of network performance and status and initiate
actions when required. The phrase "LMgmtEs and/or managed entities"
allows for the possibility that the target architecture allows for
direct communication between the CMgmtE and the managed entities or
alternatively chooses to assume a distributed management architecture.
In any case, as discussed below, the CMgmtE will have to communicate
with legacy LMgmtEs during the transition from the existing to the
target architecture.</t>
</list></t>
</section> <!-- archTerm -->
<section anchor="archDefine" title="What the Architecture Must Define">
<t>This section is a discussion in the nature of a very general use
case rather than a discussion of functions and entities. However, as a
preliminary remark, the architecture must be thought through for all
five of the FCAPS areas (fault, configuration, accounting,
performance, and security management). RFC 5706 Section 3, while
nominally directed to protocol design, reviews operational issues
associated with each of these areas. </t>
<t>To begin with, previous analysis (<xref target="argLITI"/>) has
indicated that the CMgmtE needs to work with a view of network
topology that is layer and technology independent in order to achieve
the objectives stated in <xref target="preObject"/>. Two questions
immediately come to mind: where is this view prepared, taking account
of the limited processing power of network devices in particular, and
what model is used to present the topology to the CMgmtE? Of course,
these questions are evaded if the architecture makes the CMgmtE
responsible for creating the abstracted topology from data gathered
from the LMgmtEs and/or managed entities within its scope. </t>
<t>Note that from the end-to-end point of view multiple network
topologies will typically exist in the network at one time, possibly
down to the granularity of a service instance. The relationship of the
scope of a CMgmtE to the set of available topologies is subject to the
condition that it has end-to-end and service-level views of all paths
between the endpoints within its scope, and is otherwise undefined.
</t>
<t>The CMgmtE must be aware of all of the LMgmtEs and/or managed
entities
within its scope. The architecture must define how the CMgmtE
identifies the correct sequence of these entities along a path in a
given layer, and similarly, must identify the correct ordering of
layers from bottom to top. In effect, the CMgmtE requires a
three-dimensional topological view of the data plane maintenance
infrastructure. Entity identification may be implicit in this work.
Note that management actions may alter this topology (e.g., for
routine maintenance or installation of new equipment). </t>
<t>The next issue is how the CMgmtE and the other entities discover
each other. Bound up in this is the issue of trust. This bootstrapping
problem is a hard one, constantly recurring in IETF work but never yet
solved. The architecture work will have to come to its own conclusions
on this topic. </t>
<t>Where correlation of events from different layers and transport
segments is done is not an issue. By definition it can be done only by
the CMgmtE. The architecture must decide whether the necessary data
gathering is done as required or continuously. </t>
<t>As a final point, the architecture must specify how an existing
network evolves from legacy operation to the target architecture. The
existing network will have LMgmtEs in place. The question is whether
the CMgmtE simply replaces them or communicates with them. If it
simply replaces them, the architecture must define (in an operational
considerations section) how testing of the new management
configuration takes place before cutover. Considerations of data
continuity during cutover should also be addressed. </t>
<t>The above is not an exhaustive list of considerations, but should
give a good start to the architectural work.</t>
</section> <!-- archDefine -->
</section> <!-- archCons -->
<section title="Security Considerations">
<t>The architectural work must include work on the security architecture
of the whole system. Beyond that, potential future work on individual
interfaces must include the appropriate security mechanisms within
the architectural framework. The present document cannot be more specific
by its nature.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="contrib" title="Contributors">
<t>In the understanding of the Editor, the following individuals (listed
in alphabetical order by last name) contributed text to or strongly
influenced the development of versions of draft-ww-opsawg-multi-layer-oam,
from which this document was derived:
<list style="symbols">
<t>Sam Aldrin mailto:aldrin.ietf@gmail.com, Huawei USA;</t>
<t>Mohamed Boucadair mailto:mohamed.boucadair@orange.com,
France Telecom;</t>
<t>Huub van Helvoort mailto:huubatwork@gmail.com, Hai Gaoming BV;</t>
<t>Tom Herbert mailto:therbert@google.com, Google;</t>
<t>Pradeep Jain mailto:pradeep@nuagenetworks.net, Nuage Networks;</t>
<t>Daniel King mailto:daniel@olddog.co.uk, Olddog Consulting;</t>
<t>Greg Mirsky mailto:gregory.mirsky@ericsson.com, Ericsson;</t>
<t>Dan Romascanu mailto:dromasca@avaya.com, Avaya;</t>
<t>Ravi Shekhar mailto:rshekhar@juniper.net, Juniper.</t>
</list></t>
</section> <!-- contrib -->
<section title="Acknowledgements">
<t>The authors would like to thank Jan Lindblad, Tissa Senevirathne, Yuji
Tochio, Ignas Bagdonas, Eric Osborne, Rob Shakir, Georgis Karagiannis,
Melinda Shore and Jouni Korhonen for their reviews and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC6291;
&RFC7276;
</references> <!-- Normative -->
<references title="Informative References">
<!-- &RFC1157;
&RFC3410;
&RFC4176;
-->
&RFC4379;
&RFC4443;
<!-- &RFC4656;
&RFC5357;
-->
&RFC5706;
<!-- &RFC5880;
-->
&RFC6020;
&RFC6123;
&RFC6241;
&RFC6310;
<!--
&RFC6374;
&RFC6378;
&RFC6428;
-->
&RFC7023;
<!--
<reference anchor="I.D-ietf-nvo3-framework">
<front>
<title>Framework for DC Network Virtualization (Work
in progress)</title>
<author fullname="M.Lasserre" initials="M." surname="Lasserre">
<organization/>
</author>
<date month="July" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-ietf-nvo3-framework-00"/>
</reference>
<reference anchor="I-D.sridharan-virtualization-nvgre">
<front>
<title>NVGRE: Network Virtualization using Generic Routing Encapsulation
(Work in progress)</title>
<author initials="M." surname="Sridharan">
<organization>Microsoft</organization>
</author>
<author initials="A." surname="Greenberg">
<organization>Microsoft</organization>
</author>
<author initials="Y." surname="Wang">
<organization>Microsoft</organization>
</author>
<author initials="P." surname="Garg">
<organization>Microsoft</organization>
</author>
<author initials="N." surname="Venkataramiah">
<organization>Microsoft</organization>
</author>
<author initials="K." surname="Duda">
<organization>Arista Networks</organization>
</author>
<author initials="I." surname="Ganga">
<organization>Intel</organization>
</author>
<author initials="G." surname="Lin">
<organization>Google</organization>
</author>
<author initials="M." surname="Pearson">
<organization>Hewlett-Packard</organization>
</author>
<author initials="P." surname="Thaler">
<organization>Broadcom</organization>
</author>
<author initials="C." surname="Tumuluri">
<organization>Emulex</organization>
</author>
<date month="July" year="2014"/>
</front>
</reference>
<reference anchor="I-D.gross-geneve">
<front>
<title> Geneve: Generic Network Virtualization Encapsulation
(Work in progress)</title>
<author initials="J." surname="Gross">
<organization>VMware</organization>
</author>
<author initials="T." surname="Sridhar">
<organization>VMware</organization>
</author>
<author initials="P." surname="Garg">
<organization>Microsoft</organization>
</author>
<author initials="C." surname="Wright">
<organization>Red Hat</organization>
</author>
<author initials="I." surname="Ganga">
<organization>Intel</organization>
</author>
<date month="August" year="2014"/>
</front>
</reference>
-->
<?rfc include='reference.I-D.ietf-l2vpn-vpws-iw-oam'?>
<!--
<?rfc include='reference.I-D.tissa-netmod-oam'?>
-->
<reference anchor="I.D-ietf-sfc-problem-statement">
<front>
<title>Network Service Chaining Problem Statement
(Work in progress)</title>
<author fullname="P.Quinn" initials="P." surname="Quinn">
<organization/>
</author>
<author fullname="J.Guichard" initials="J." surname="Guichard">
<organization/>
</author>
<author fullname="S.Surendra" initials="S." surname="Surendra">
<organization/>
</author>
<date month="August" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-ietf-sfc-problem-statement"/>
</reference>
<!--
<reference anchor="I-D.jain-nvo3-overlay-oam">
<front>
<title>Generic Overlay OAM and Datapath Failure Detection
(Expired Internet Draft)</title>
<author fullname="P. Jain" initials="P." surname="Jain">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-jain-nvo3-overlay-oam-01"/>
</reference>
<reference anchor="I-D.tissa-nvo3-yang-oam">
<front>
<title>YANG Data Model for NVO3 Operations, Administration, and
Maintenance (OAM) (Work in progress)</title>
<author fullname="T.Senevirathne" initials="T."
surname="Senevirathne">
<organization/>
</author>
<date month="June" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-tissa-nvo3-yang-oam-00"/>
<format target="http://tools.ietf.org/html/draft-tissa-nvo3-yang-oam-00"
type="TXT"/>
</reference>
<reference anchor="I-D.penno-sfc-yang">
<front>
<title>Yang Data Model for Service Function Chaining
(Work in progress)</title>
<author fullname="R. Penno" initials="R." surname="Penno">
<organization/>
</author>
<date month="July" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-penno-sfc-yang-06"/>
<format target="http://tools.ietf.org/html/draft-penno-sfc-yang-06"
type="TXT"/>
</reference>
<reference anchor="I-D.herbert-gue">
<front>
<title>Generic UDP Encapsulation (Work in progress)</title>
<author initials="T." surname="Herbert">
<organization>Google</organization>
</author>
<date month="March" year="2014"/>
</front>
</reference>
<reference anchor="G.806">
<front>
<title>Characteristics of transport equipment - Description methodology
and generic functionality</title>
<author initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="March" year="2006"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="G.806" />
</reference>
<reference anchor="MEF-38">
<front>
<title>Service OAM Fault Management YANG Modules</title>
<author>
<organization/>
</author>
<date month="April" year="2012"/>
</front>
<seriesInfo name="MEF" value="38"/>
</reference>
<reference anchor="MEF-39">
<front>
<title>Service OAM Performance Monitoring YANG Module</title>
<author>
<organization/>
</author>
<date month="April" year="2012"/>
</front>
<seriesInfo name="MEF" value="39"/>
</reference>
<reference anchor="Y.1375">
<front>
<title>Protocol-neutral management information model for the MPLS-TP
network element</title>
<author>
<organization/>
</author>
<date month="September" year="2014"/>
</front>
<seriesInfo name="Draft Recommendation ITU-T" value="Y.1375"/>
</reference>
<reference anchor="Y.1346">
<front>
<title>Protocol-neutral management information model for the
Ethernet transport capable network element</title>
<author>
<organization/>
</author>
<date month="September" year="2014"/>
</front>
<seriesInfo name="Draft Recommendation ITU-T" value="Y.1346"/>
</reference>
<reference anchor="Y.1370.1">
<front>
<title>Architecture of MPLS Transport Profile (MPLS-TP) layer
network</title>
<author>
<organization/>
</author>
<date month="December" year="2011"/>
</front>
<seriesInfo name="ITU-T" value="Y.1370.1"/>
</reference>
-->
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 02:41:39 |