idnits 2.17.1
draft-lam-lime-summary-l0-l2-layer-independent-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (April 27, 2015) is 3287 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 6424 (Obsoleted by RFC 8029)
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 LIME Working Group K. Lam, Ed.
3 Internet-Draft E. Varma, Ed.
4 Intended status: Informational Alcatel-Lucent
5 Expires: October 29, 2015 S. Mansfield, Ed.
6 Ericsson
7 Y. Tochio, Ed.
8 Fujitsu
9 H. van Helvoort, Ed.
10 Hai Gaoming BV
11 M. Vissers, Ed.
12 Huawei
13 P. Doolan, Ed.
14 Coriant
15 April 27, 2015
17 Existing Support for Network Operations in Multilayer Transport Network
18 based upon unified approach to OAM (Layer 0 - Layer 2)
19 draft-lam-lime-summary-l0-l2-layer-independent-02
21 Abstract
23 This draft summarizes the existing ITU-T SG 15 standards, (Layer 0 -
24 Layer 2) both technology-specific and generic across these
25 technologies, relevant to leveraging OAM to support fault management,
26 performance monitoring, and configuration management. Knowledge from
27 this domain may be leveraged for the benefit of developing generic
28 layer independent management for other layers.
30 Status of This Memo
32 This Internet-Draft is submitted in full conformance with the
33 provisions of BCP 78 and BCP 79.
35 Internet-Drafts are working documents of the Internet Engineering
36 Task Force (IETF). Note that other groups may also distribute
37 working documents as Internet-Drafts. The list of current Internet-
38 Drafts is at http://datatracker.ietf.org/drafts/current/.
40 Internet-Drafts are draft documents valid for a maximum of six months
41 and may be updated, replaced, or obsoleted by other documents at any
42 time. It is inappropriate to use Internet-Drafts as reference
43 material or to cite them other than as "work in progress."
45 This Internet-Draft will expire on October 29, 2015.
47 Copyright Notice
49 Copyright (c) 2015 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the Simplified BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67 3. Network Operation Supported by L0-L2 OAM . . . . . . . . . . 5
68 4. L0-L2 Architecture and Management Standards . . . . . . . . . 6
69 4.1. Generic Transport Layer and Technology Independent
70 Standards . . . . . . . . . . . . . . . . . . . . . . . . 6
71 4.1.1. Generic Transport Architecture . . . . . . . . . . . 6
72 4.1.2. Generic processing of transport equipment OAM
73 functions . . . . . . . . . . . . . . . . . . . . . . 7
74 4.1.3. Generic management requirements . . . . . . . . . . . 7
75 4.1.4. Generic information model of transport network
76 resources . . . . . . . . . . . . . . . . . . . . . . 8
77 4.2. Layer and Technology Specific Standards . . . . . . . . . 8
78 4.2.1. Architecture . . . . . . . . . . . . . . . . . . . . 8
79 4.2.2. Transport Equipment Functions . . . . . . . . . . . . 9
80 4.2.3. Transport management requirements . . . . . . . . . . 10
81 4.2.4. Management Information Models . . . . . . . . . . . . 11
82 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13
83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
84 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13
85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
88 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
89 10.2. Informative References . . . . . . . . . . . . . . . . . 18
90 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 18
91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
93 1. Introduction
95 A comprehensive set of Operations, Administration, and Maintenance
96 (OAM) capabilities is essential for supporting the critical network
97 operations of fault management, performance monitoring, and
98 configuration management. For this reason in the ITU-T, Layer 0 -
99 Layer 2 technologies have been designed with extensive OAM
100 capabilities (e.g., as specified in [ITU-T_G.709], [ITU-T_G.707],
101 [ITU-T_G.8012], etc.) Considerable effort has been expended to
102 establish a coherent approach to OAM that allows monitoring of the
103 status and performance of (stacked) connections, including generic
104 layer independent principles and inter-layer interworking. Thus, the
105 OAM architecture used in transport networks has a common behavior
106 across all technologies and layer networks. This draft summarizes
107 ITU-T Recommendations that specify the generic architecture,
108 principles, and models, both technology specific and generic,
109 developed to support management of L0-L2 connections based upon a
110 unified and consistent OAM view of multi-layer networks. It should
111 be noted that the OAM and management framework and requirements for
112 MPLS-TP, which is L2.5, has also been based upon these principles
113 (e.g., RFC 6371 [RFC6371], RFC 5860 [RFC5860], RFC 5950 [RFC5950],
114 and RFC 5951 [RFC5951].
116 It is believed that the generic architecture, principles and models
117 specified in the material summarized herein may be leveraged in
118 considerations of a common approach to OAM management for other layer
119 networks (e.g., Layer 3-Layer 7).
121 1.1. Requirements Language
123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
125 document are to be interpreted as described in RFC 2119 [RFC2119].
127 2. Terminology
129 Anomaly: The smallest discrepancy that can be observed between actual
130 and desired characteristics of an item. The occurrence of a single
131 anomaly does not constitute an interruption in ability to perform a
132 required function. Anomalies are used as the input for the
133 Performance Monitoring (PM) process and for detection of defects
134 (from [ITU-T_G.806], Section 3.7).
136 Defect: The density of anomalies has reached a level where the
137 ability to perform a required function has been interrupted. Defects
138 are used as input for performance monitoring, the control of
139 consequent actions, and the determination of fault cause (from
140 [ITU-T_G.806], Section 3.24).
142 Fault: A fault is the inability of a function to perform a required
143 action. This does not include an inability due to preventive
144 maintenance, lack of external resources, or planned actions (from
145 [ITU-T_G.806], Section 3.26).
147 Fault cause: A single disturbance or fault may lead to the detection
148 of multiple defects. A fault cause is the result of a correlation
149 process that is intended to identify the defect that is
150 representative of the disturbance or fault that is causing the
151 problem (from [ITU-T_G.806], Section 3.27).
153 Failure: The fault cause persisted long enough to consider the
154 ability of an item to perform a required function to be terminated.
155 The item may be considered as failed; a fault has now been detected
156 (from [ITU-T_G.806], Section 3.25).
158 Equipment Management Function (EMF): The management functions within
159 an NE (see [ITU-T_G.7710]).
161 Element Management System (EMS)
163 Information Model (IM): An information model condenses domain
164 knowledge and insights to provide a representation of its essential
165 concepts, structures, and interrelationships. It models managed
166 objects at a conceptual level, independent of any specific
167 implementations or protocols used to transport the data.
169 Layer 0 - Layer 2: Refers to physical (photonic), physical
170 (electrical), and data link (e.g., Ethernet) transport technology,
171 respectively.
173 Network Management System (NMS)
175 Network Element (NE)
177 Operations, Administration, and Maintenance (OAM)
179 o On-demand OAM - OAM actions that are initiated via manual
180 intervention for a limited time to carry out diagnostics. On-
181 demand OAM can result in singular or periodic OAM actions during
182 the diagnostic time interval.
184 o Proactive OAM - OAM actions that are carried on continuously to
185 permit timely reporting of fault and/or performance status.
187 3. Network Operation Supported by L0-L2 OAM
189 OAM mechanisms include the tools and utilities to plan, install,
190 monitor and troubleshoot a network layer. While the specific set of
191 OAM mechanisms in a layer depends upon the technology (e.g.,
192 [ITU-T_G.709] on OTN, [ITU-T_G.707] on SDH, [ITU-T_G.8013] on
193 Ethernet), they all support the same fault management, performance
194 monitoring, and configuration management operations and processes.
195 As noted previously, MPLS-TP OAM (e.g., [ITU-T_G.8113.2], [RFC6424],
196 [RFC6428], etc.) was also designed to support L0-L2 operations and
197 processes. Some OAM functions are implemented in hardware (data
198 plane inherent, such as Tandem Connection Monitoring (TCM) or
199 Performance Monitoring (PM)), while other functions can be
200 implemented mostly in lower software layers.
202 Fault management includes defect detection, fault localization, fault
203 reporting, and protection switching [OTN Handbook, Chapter 3].
205 o Defect detection: Failures affecting the transport of client
206 information are detected by continuous pro-active checking.
207 Persistent failures are considered to be service-affecting
208 defects. Detected defects are correlated with other detected
209 defects to find the most probable cause of the failure and
210 consequent actions, such as protection switching, are taken.
212 o Fault localization: If the defect information is insufficient to
213 locate the failure, on-demand OAM functions can be used to
214 determine the cause of the defect more accurately.
216 o Fault reporting: Persistent defects are reported to the network
217 management system to provide the appropriate alarm reports to
218 maintenance staff for maintaining the desired quality of service
219 level.
221 o Protection switching: After a defect has been detected, a
222 protection switch can be initiated as a consequent action to
223 restore the interrupted traffic, and thus improve the
224 availability.
226 Performance monitoring includes measuring the performance (e.g.,
227 packet losses, bit errors, etc.) of the transport of client
228 information in order to verify the quality of service and to estimate
229 the transport integrity.
231 Configuration management includes indicating the operational state of
232 a connection; e.g., whether it can be used to transport client data
233 or whether the set-up of the connection is completed.
235 4. L0-L2 Architecture and Management Standards
237 Figure 1 below is a summary of relevant technology specific and
238 generic L0-L2 transport architecture and management standards.
240 +-------------------------------------------------+
241 |Transport| Transport Technology Specific |
242 | Tech. |---------------------------------------+
243 | Generic | OTN | Carrier | MPLS-TP | SDH |
244 | | | Ethernet | Note 2 | |
245 +------------------------------------------------------------------+
246 | Transport | G.800 | G.872 | G.8010 | G.8110.1 | G.803 |
247 | Architecture | G.805 | | | | |
248 +------------------------------------------------------------------+
249 | Equipment | G.806 | G.798 | G.8021 | G.8121.x | G.783 |
250 | Function | | | | series | |
251 +------------------------------------------------------------------+
252 | Management | G.7710 | G.874 | G.8051 | G.8151 | G.784 |
253 | Requirement | | | | | |
254 +------------------------------------------------------------------+
255 | Mgmt Interface | | | | | G.774 |
256 |Protocol-neutral| G.gim | G.874.1 | G.8052 | G.8152 | series|
257 | Info Model | | | | | Note 1|
258 +------------------------------------------------------------------+
259 Note 1: The model had been specified, but not in a protocol neutral
260 manner.
261 Note 2: MPLS-TP is actually L2.5; it is included as it falls
262 under the generic transport management umbrella (as per design).
264 Figure 1: L0-L2 Architecture and Management Standards
266 4.1. Generic Transport Layer and Technology Independent Standards
268 4.1.1. Generic Transport Architecture
270 Recommendations [ITU-T_G.800] and [ITU-T_G.805] provide a technology
271 independent and model-based description of transport network
272 functionality. The first generic functional model based architecture
273 Recommendation was ITU-T G.805, which describes connection oriented
274 networks. ITU-T G.800 was subsequently developed to provide a common
275 framework to describe both connection-oriented and connectionless
276 networks. The descriptions are compatible with those of the earlier
277 generic Recommendations (e.g., ITU-T G.805). These standard model-
278 based approaches:
280 o Enable the description of the generic characteristics of networks
281 using a common language at a level that transcends technology and
282 physical architecture choices.
284 o Provide a view of functions or entities that may be distributed
285 among various equipment.
287 o Concurrently specify transport and management functionality.
289 These generic functional architectures of transport networks are the
290 basis for a harmonized set of functional architecture Recommendations
291 for specific transport layer network technologies that use circuit
292 switching or packet switching technology (e.g. [ITU-T_G.803] for
293 SDH, [ITU-T_G.872] for OTN, [ITU-T_G.8010] for Carrier Ethernet,
294 [ITU-T_G.8110.1] for MPLS-TP). These transport technology specific
295 architecture Recommendations are used as the basis for a
296 corresponding set of Recommendations for equipment specifications,
297 including OAM and management.
299 4.1.2. Generic processing of transport equipment OAM functions
301 The development of the OAM architecture used by ITU-T in transport
302 networks started around 1990, and basic generic OAM functions were
303 first defined in the period 1990-1993 and described in Recommendation
304 [ITU-T_G.806]. Since that time, this initial OAM architecture has
305 been extended to assure it remains generic with respect to emerging
306 transport technologies. The extended OAM functionality included the
307 definition of a transport maintenance entity with end-points and
308 intermediate-points, pro-active and on-demand OAM functions, defect
309 correlation, and alarm suppression, etc. The generic OAM
310 architecture in ITU-T G.806 has been used as the common basis for all
311 technology-specific transport equipment specifications (e.g.,
312 [ITU-T_G.783] for SDH, [ITU-T_G.798] for OTN, [ITU-T_G.8021] for
313 Carrier Ethernet, and also [ITU-T_G.8121] for MPLS-TP).
315 4.1.3. Generic management requirements
317 Recommendation [ITU-T_G.7710] specifies the equipment management
318 function (EMF) requirements that are common to multiple transport
319 technologies and common to packet-based and circuit-based transport
320 networks. The Recommendation addresses the EMF inside a transport
321 network element, including the configuration, fault, and performance
322 (i.e. the C, F, P of FCAPS) management functions. The generic
323 management requirements in ITU-T G.7710 have been used as the common
324 basis for all technology-specific transport management specifications
325 (e.g., [ITU-T_G.784] for SDH, [ITU-T_G.874] for OTN, [ITU-T_G.8051]
326 for Carrier Ethernet, and [ITU-T_G.8151] for MPLS-TP.
328 4.1.4. Generic information model of transport network resources
330 ITU-T Recommendation [ITU-T_G.gim] and ONF Common Information Model
331 (ONF-CIM) (see [ONF_Liaison]) specify a core information model
332 [I-D.lam-topology] for transport resources. The model is also
333 applicable to the management and control of the transport network
334 regardless of the technology of the underlying transport network.
335 Furthermore, the applicability of the information model is
336 independent of the choice of protocol to be used in the management
337 and control interfaces. The core information model defined in this
338 Recommendation can be used as the basis for the extension of
339 transport/control-technology-specific information models. Such
340 extension will be specified in the technology-specific
341 Recommendations, such as [ITU-T_G.774] series for SDH,
342 [ITU-T_G.874.1] for OTN management, [ITU-T_G.8052] for Carrier
343 Ethernet management, [ITU-T_G.8152] for MPLS-TP management, and
344 [ITU-T_G.7718.1] for ASON control plane management.
346 4.2. Layer and Technology Specific Standards
348 4.2.1. Architecture
350 Recommendations [ITU-T_G.803] and [ITU-T_G.872] describe respectively
351 the functionality of the SDH and optical transport networks (OTN), L0
352 and L1, from a network level perspective using the generic principles
353 defined in ITU-T G.805 and ITU-T G.800. ITU-T G.803 and ITU-T G.872
354 describe the specific aspects concerning the SDH and optical
355 transport network layered structure, characteristic information,
356 client/server layer associations, network topology, and layer network
357 functionality. In accordance with ITU-T G.805 and ITU-T G.800, the
358 optical transport network is decomposed into independent transport
359 layer networks where each layer network can be separately partitioned
360 in a way which reflects the internal structure of that layer network.
361 In addition to reflecting the generic fault, configuration, and
362 performance management requirements, it describes requirements for
363 connection supervision (e.g., continuity, connectivity, required
364 maintenance information), signal quality supervision, adaptation
365 management, etc.) and connection supervision techniques (i.e.,
366 inherent, non-intrusive, intrusive, and sublayer monitoring).
368 Recommendation [ITU-T_G.8010] describes the functional architecture
369 of L2 Ethernet networks using the modelling methodology described in
370 ITU-T G.800 and ITU-T G.805. The Ethernet network functionality is
371 described from a network level viewpoint, taking into account an
372 Ethernet network layered structure, client characteristic
373 information, client/server layer associations, networking topology,
374 and layer network functionality providing Ethernet signal
375 transmission, multiplexing, routing, supervision, performance
376 assessment, and network survivability. Recommendation ITU-T G.8010/
377 Y.1306 describes the relevant parts of the Ethernet specifications in
378 [IEEE_802.1Q] and [IEEE_802.3] using the ITU-T transport network
379 modelling methodology. The ETH layer network provides the transport
380 of adapted information through an ETH connectionless trail between
381 ETH access points. The adapted information is a (non-) continuous
382 flow of MAC service data units (IEEE 802.3).
384 Recommendation [ITU-T_G.8110.1] provides functional components, based
385 on Recommendation ITU T G.805, that allow the Multi Protocol Label
386 Switching Transport Profile (MPLS-TP) to be modeled in a way that is
387 consistent with the description of other transport technologies
388 defined by the ITU-T to simplify integration with other transport
389 technologies. It provides a representation of the MPLS-TP technology
390 using the methodologies that have been used for other transport
391 technologies (e.g., SDH, OTN and Ethernet). In G.8110.1, the
392 architecture of MPLS-TP forwarding, OAM, and network survivability
393 are modeled from a network-level viewpoint.
395 4.2.2. Transport Equipment Functions
397 Recommendations [ITU-T_G.783] and [ITU-T_G.798] specify both the
398 components and the methodology that should be used in order to
399 specify the respective SDH and OTN functionality of network elements.
400 This Recommendations uses the specification methodology defined in
401 [ITU-T_G.806], in general for transport network equipment, and is
402 based on the architecture of SDH transport networks defined in
403 [ITU-T_G.783] and optical transport networks defined in [ITU-T_G.872]
404 and the interfaces for SDH transport networks defined in
405 [ITU-T_G.707] and optical transport networks defined in
406 [ITU-T_G.709]. The description is generic and no particular physical
407 partitioning of functions is implied. The input/output information
408 flows associated with the functional blocks serve for defining the
409 functions of the blocks and are considered to be conceptual, not
410 physical. They also provides processes for SDH OAM based on ITU-T
411 G.707 and OTN OAM based on ITU-T G.709. The functionality defined in
412 this Recommendation can be applied at user-to-network interfaces
413 (UNIs) and network node interfaces (NNIs) of the optical transport
414 network.
416 Recommendation [ITU-T_G.8021] specifies both the functional
417 components and the methodology that should be used in order to
418 specify the L2 Ethernet transport network functionality of network
419 elements. This Recommendation uses the specification methodology
420 defined in [ITU-T_G.806] in general for transport network equipment
421 and is based on the architecture of Ethernet layer networks defined
422 in [ITU-T_G.8010], the interfaces for Ethernet transport networks
423 defined in [ITU-T_G.8012], and in support of services defined in the
424 ITU-T G.8011.x series of Recommendations. It also provides processes
425 for Ethernet OAM based on [ITU-T_G.8013]. The description is generic
426 and no particular physical partitioning of functions is implied. The
427 input/output information flows associated with the functional blocks
428 serve to define the functions of the blocks and are considered to be
429 conceptual, not physical. The functionality defined in this
430 Recommendation can be applied at user-to-network interfaces (UNIs)
431 and network-to-network interfaces (NNIs) of the Ethernet transport
432 network.
434 Recommendation [ITU-T_G.8121] specifies both the functional
435 components and the methodology that should be used in order to
436 specify the multi-protocol label switching transport profile (MPLS-
437 TP) layer network functionality of network elements. This
438 Recommendation provides a representation of MPLS-TP technology which
439 uses the methodologies that have been used for other transport
440 technologies (e.g., optical transport network (OTN) and Ethernet).
441 It also provides generic processes for MPLS-TP OAM. It specifies a
442 library of basic building blocks and a set of rules by which they may
443 be combined in order to describe digital transmission equipment. The
444 library comprises the functional building blocks needed to specify
445 completely the generic functional structure of the MPLS-TP layer
446 network.
448 4.2.3. Transport management requirements
450 Recommendation [ITU-T_G.874] addresses management aspects of L0 and
451 L1 optical transport network elements containing transport functions
452 of one or more layer networks of the optical transport network (OTN).
453 It is based on the architecture of optical transport networks defined
454 in [ITU-T_G.872], the interfaces for OTN networks defined in
455 [ITU-T_G.709], and the OTN equipment function description defined in
456 [ITU-T_G.798]. The management functions for fault management,
457 configuration management, and performance management are specified.
458 Generic requirements in ITU-T G.7710/Y.1701 that are applicable to
459 OTN are identified in ITU-T G.874 via pointer references to ITU-T
460 G.7710/Y.1701. OTN-specific requirements explicitly specified
461 include separation of management communication network and signaling
462 communication network, OTN fault causes and failures, alarm reporting
463 control (ARC) setting, operational state, trail trace identifier
464 configuration, adaptation function configuration, connection function
465 configuration, tandem connection monitoring control function
466 configuration, and the management of the performance primitives.
468 Recommendation [ITU-T_G.8051] addresses management aspects of the L2
469 Ethernet Transport capable network element containing transport
470 functions of one or more of the layer networks of the Ethernet
471 transport network. The L2 Ethernet specific equipment functional
472 blocks are defined in [ITU-T_G.8021]. In this Recommendation, fault
473 management, configuration management, and performance management are
474 specified. Generic requirements in ITU-T G.7710/Y.1701 that are
475 applicable to Ethernet are identified in ITU-T G.8051/Y.1345 via
476 pointer references to ITU-T G.7710/Y.1701. Ethernet-specific
477 requirements explicitly specified include the management
478 communication channel, fault causes and failures, alarm reporting
479 control setting, operational state, flow termination function
480 configuration, adaptation function configuration, connection function
481 configuration, diagnostic function configuration, traffic
482 conditioning and shaping function configuration, performance
483 monitoring requirements, and the management of the performance
484 primitives.
486 Recommendation [ITU-T_G.8151] addresses management aspects of the
487 MPLS Transport Profile (MPLS-TP) capable network element, which is
488 separable from that of its client layer networks so that the same
489 means of management can be used regardless of the client. In this
490 Recommendation, fault management, configuration management, and
491 performance management are specified. The generic requirements for
492 managing transport network elements are specified in [ITU-T_G.7710]
493 and the requirements for the management of equipment used in networks
494 supporting an MPLS Transport Profile (MPLS-TP) are specified in [IETF
495 RFC 5951]. This Recommendation specifies the requirements for
496 managing the MPLS-TP specific equipment functional blocks, which are
497 defined in [ITU-T_G.8121].
499 4.2.4. Management Information Models
501 Recommendation [ITU-T_G.874.1] provides a management-protocol-neutral
502 information model for managing network elements in the L0 and L1
503 optical transport network (OTN) [ITU-T_G.872], [ITU-T_G.709], and
504 [ITU-T_G.798] and supporting the management requirements specified in
505 [ITU-T_G.7710] and [ITU-T_G.874]. It identifies the managed entities
506 required for the management of OTN network elements, including
507 Termination Points (TP), Tandem Connection Monitoring (TCM), Non-
508 Intrusive Monitoring (NIM), Delay Measurement (DM), and the general
509 Performance Monitoring (PM) Current Data (CD) and History Data (HD).
510 These entities are relevant to information exchanged across
511 standardized management interfaces. The management-protocol-neutral
512 information model should be used as the base for defining management-
513 protocol-specific data schema. The specific mapping of the
514 management-protocol-neutral information model into management-
515 protocol-specific data schema is the decision of the management-
516 protocol-specific solution designer. The information model specified
517 in this Recommendation allows for managing the OTN functional
518 capabilities of the NE.
520 Recommendation [ITU-T_G.8052] provides a management-protocol-neutral
521 information model for managing network elements in the L2 Ethernet
522 transport network [ITU-T_G.8010], [ITU-T_G.8012], and [ITU-T_G.8021]
523 and supporting the management requirements specified in
524 [ITU-T_G.7710] and [ITU-T_G.8051]. It identifies the managed
525 entities required for the management of Ethernet transport network
526 elements, including Termination Points (TP), Maintenance Entity Group
527 (MEG) End Point (MEP), MEG Intermediate Point (MIP), Traffic
528 Conditioning and Shaping (TCS), Loss Measurement (LM), Delay
529 Measurement (DM), and the general Performance Monitoring (PM) Current
530 Data (CD) and History Data (HD). These entities are relevant to
531 information exchanged across standardized management interfaces. The
532 management-protocol-neutral information model should be used as the
533 base for defining management-protocol-specific data schema. The
534 specific mapping of the management-protocol-neutral information model
535 into management-protocol-specific data schema is the decision of the
536 management-protocol-specific solution design. The information model
537 specified in this Recommendation allows for managing the Ethernet
538 functional capabilities of the NE.
540 It should also be noted that [MEF_7.2] specifies the EMS-NMS
541 interface profile needed to support Metro Ethernet services, which
542 provides the profile of management entities based on [ITU-T_Q.840.1]
543 and [ITU-T_G.8052] and a mapping to the TMF's MTNM 3.5[TMF_MTNM]
544 Ethernet model.
546 Recommendation [ITU-T_G.8152] provides a management-protocol-neutral
547 information model for managing network elements in the L2 MPLS-TP
548 network [ITU-T_G.8110.1], [ITU-T_G.8112], and [ITU-T_G.8121] series
549 and supporting the management requirements specified in
550 [ITU-T_G.7710] and [ITU-T_G.8151]. It identifies the managed
551 entities required for the management of MPLS-TP network elements,
552 including Termination Points (TP), Maintenance Entity Group (MEG) End
553 Point (MEP), MEG Intermediate Point (MIP), Loss Measurement (LM),
554 Delay Measurement (DM), and the general Performance Monitoring (PM)
555 Current Data (CD) and History Data (HD). These entities are relevant
556 to information exchanged across standardized management interfaces.
557 The management-protocol-neutral information model should be used as
558 the base for defining management-protocol-specific data schema. The
559 specific mapping of the management-protocol-neutral information model
560 into management-protocol-specific data schema is the decision of the
561 management-protocol-specific solution design. The information model
562 specified in this Recommendation allows for managing the MPLS-TP
563 functional capabilities of the NE.
565 5. Discussion
567 This draft has provided an introduction to the significant body of
568 specifications developed in ITU-T that detail the generic
569 architectural principles for OAM in (multi layer) transport networks.
570 It also provides an introduction to the specifications that apply
571 those general principles in a consistent way to various layered
572 transport network technologies. It is anticipated that the generic
573 and layer specific OAM architecture and management specifications
574 described in this draft will prove valuable in considerations of
575 generic unified approaches to OAM and management for additional
576 multilayer networks.
578 6. Acknowledgements
580 7. Contributors
582 8. IANA Considerations
584 This memo includes no request to IANA.
586 9. Security Considerations
588 This informational document is solely intended to provide a summary
589 of the existing ITU-T SG 15 standards, (Layer 0 - Layer 2) both
590 technology-specific and generic across these technologies, relevant
591 to leveraging OAM to support fault management, performance
592 monitoring, and configuration management. No security threat is
593 introduced by this informational document.
595 10. References
597 10.1. Normative References
599 [I-D.lam-topology]
600 Lam, K., Varma, E., Doolan, P., Davis, N., Zeuner, B.,
601 Betts, M., Busi, I., and S. Mansfield, "Usage of IM for
602 network topology to support TE Topology YANG Module
603 Development", 2015, .
606 [IEEE_802.1Q]
607 IEEE, "Media Access Control (MAC) Bridges and Virtual
608 Bridged Local Area Networks, IEEE Std 802.1Q-2014", 2014.
610 [IEEE_802.3]
611 IEEE, "Carrier sense multiple access with collision
612 detection (CSMA/CD) access method and physical layer
613 specifications, IEEE Std 802.3-2005", 2005.
615 [ITU-T_G.707]
616 ITU-T, "ITU-T G.707/Y.1322 - Network node interface for
617 the synchronous digital hierarchy (SDH), 01/2007, Amd.1
618 07/2007, Amd. 2 11/2009", 2007,
619 .
621 [ITU-T_G.709]
622 ITU-T, "ITU-T G.709/Y.1331 - Interfaces for the optical
623 transport network (OTN), 02/2012", 2012,
624 .
626 [ITU-T_G.7710]
627 ITU-T, "ITU-T G.7710/Y.1701 - Common Equipment Management
628 Function Requirements; 02/2012", 2012,
629 .
631 [ITU-T_G.7718.1]
632 ITU-T, "ITU-T G.7718.1/Y.1709.1 - Protocol-neutral
633 management information model for the control plane view;
634 12/2006", 2006,
635 .
637 [ITU-T_G.774]
638 ITU-T, "ITU-T G.774 - Synchronous digital hierarchy (SDH)
639 - Management information model for the network element
640 view ; 02/2001", 2001,
641 .
643 [ITU-T_G.783]
644 ITU-T, "ITU-T G.783 - Characteristics of Synchronous
645 Digital Hierarchy (SDH) equipment functional blocks;
646 03/2006", 2006, .
648 [ITU-T_G.784]
649 ITU-T, "ITU-T G.784 - Management aspects of synchronous
650 digital hierarchy (SDH) transport network elements ;
651 03/2008", 2008, .
653 [ITU-T_G.798]
654 ITU-T, "ITU-T G.798 - Characteristics of optical transport
655 network hierarchy equipment functional blocks; 12/2012",
656 2012, .
658 [ITU-T_G.800]
659 ITU-T, "ITU-T G.800 - Unified Model; 02/2012", 2012,
660 .
662 [ITU-T_G.8010]
663 ITU-T, "ITU-T G.8010/Y.1306 - Architecture of Ethernet
664 Layer Networks; 02/2004", 2004,
665 .
667 [ITU-T_G.8012]
668 ITU-T, "ITU-T G.8010/Y.1308 - Ethernet UNI and Ethernet
669 NNI; 08/2004", 2004,
670 .
672 [ITU-T_G.8013]
673 ITU-T, "ITU-T G.8013/Y.1731 - OAM functions and mechanisms
674 for Ethernet based networks; 11/2013", 2013,
675 .
677 [ITU-T_G.8021]
678 ITU-T, "ITU-T G.8021/Y.1341 - Characteristics of Ethernet
679 transport network equipment functional blocks; 04/2015",
680 2012, .
682 [ITU-T_G.803]
683 ITU-T, "ITU-T G.803 - Architecture of Transport Networks
684 based on the Synchronous Digital Hierarchy (SDH);
685 03/2000", 2000, .
687 [ITU-T_G.805]
688 ITU-T, "ITU-T G.805 - Generic functional architecture of
689 transport networks; 10/2000", 2000,
690 .
692 [ITU-T_G.8051]
693 ITU-T, "ITU-T G.8051/Y.1345 - Management aspects of the
694 Ethernet - over - Transport (EoT) capable network element;
695 08/2013", 2013, .
697 [ITU-T_G.8052]
698 ITU-T, "ITU-T G.8052/Y.1346 - Protocol-neutral management
699 information model for the Ethernet transport capable
700 network element; 08/2013", 2013,
701 .
703 [ITU-T_G.806]
704 ITU-T, "ITU-T G.806 - Characteristics of Transport
705 Equipment - Description Methodology and Generic
706 Functionality, 02/2012", 2012,
707 .
709 [ITU-T_G.8110.1]
710 ITU-T, "ITU-T G.8110.1/Y.1370.1 - Architecture of MPLS
711 Transport Profile (MPLS-TP) layer network; 12/2011", 2011,
712 .
714 [ITU-T_G.8112]
715 ITU-T, "ITU-T G.8110.1/Y.1371 - Interfaces for the MPLS
716 Transport Profile layer network ; 10/2012", 2012,
717 .
719 [ITU-T_G.8113.2]
720 ITU-T, "ITU-T G.8113.2/Y.1372.2 - Operations,
721 administration and maintenance mechanisms for MPLS-TP
722 networks using the tools defined for MPLS; 11/2012", 2012,
723 .
725 [ITU-T_G.8121]
726 ITU-T, "ITU-T G.8121/Y.1371 - Characteristics of MPLS-TP
727 equipment functional blocks; 11/2013", 2013,
728 .
730 [ITU-T_G.8151]
731 ITU-T, "ITU-T G.8151/Y.1374 - Management aspects of the
732 MPLS-TP network element; 01/2015", 2015,
733 .
735 [ITU-T_G.8152]
736 ITU-T, "ITU-T G.8152/Y.1375 (draft in progress), Protocol-
737 neutral management information model for the MPLS-TP
738 network element", 201x.
740 [ITU-T_G.872]
741 ITU-T, "ITU-T G.872 - Architecture of optical transport
742 networks; 10/2012", 2012,
743 .
745 [ITU-T_G.874]
746 ITU-T, "ITU-T G.874 - Management aspects of the optical
747 transport network element; 08/2013", 2013,
748 .
750 [ITU-T_G.874.1]
751 ITU-T, "ITU-T G.874.1 - Optical transport network (OTN)
752 protocol-neutral management information model for the
753 network element view; 10/2012", 2012,
754 .
756 [ITU-T_G.gim]
757 ITU-T, "ITU-T G.gim (draft in progress), Generic protocol-
758 neutral management Information Model for transport network
759 resources", 201x.
761 [ITU-T_Q.840.1]
762 ITU-T, "ITU-T Q.840.1 - Requirements and analysis for NMS-
763 EMS management interface of Ethernet over Transport and
764 Metro Ethernet Network (EoT/MEN)", 2007,
765 .
767 [MEF_7.2] MEF, "Carrier Ethernet Management Information Model",
768 2013, .
771 [ONF_Liaison]
772 ONF, "ONF Liaison Statement "Information Modeling Work In
773 Progress"", 2015, .
776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
777 Requirement Levels", BCP 14, RFC 2119, March 1997.
779 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for
780 Operations, Administration, and Maintenance (OAM) in MPLS
781 Transport Networks", RFC 5860, May 2010.
783 [RFC5950] Mansfield, S., Gray, E., and K. Lam, "Network Management
784 Framework for MPLS-based Transport Networks", RFC 5950,
785 September 2010.
787 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management
788 Requirements for MPLS-based Transport Networks", RFC 5951,
789 September 2010.
791 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
792 Maintenance Framework for MPLS-Based Transport Networks",
793 RFC 6371, September 2011.
795 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
796 Performing Label Switched Path Ping (LSP Ping) over MPLS
797 Tunnels", RFC 6424, November 2011.
799 [RFC6428] Allan, D., Swallow Ed. , G., and J. Drake Ed. , "Proactive
800 Connectivity Verification, Continuity Check, and Remote
801 Defect Indication for the MPLS Transport Profile", RFC
802 6428, November 2011.
804 [TMF_MTNM]
805 TM Forum, "TM Forum Multi Technology Network Management,
806 Release 3.5", 2009,
807 .
810 10.2. Informative References
812 [OTN_Handbook]
813 ITU-T, "ITU-T OTN Handbook - Optical Transport Networks
814 from TDM to Packet, ITU-T Manual 2010", 2010.
816 Appendix A. Additional Stuff
818 TBD
820 Authors' Addresses
822 Kam Lam (editor)
823 Alcatel-Lucent
824 USA
826 Phone: +1 732 331 3476
827 Email: kam.lam@alcatel-lucent.com
829 Eve Varma (editor)
830 Alcatel-Lucent
831 USA
833 Email: eve.varma@alcatel-lucent.com
834 Scott Mansfield (editor)
835 Ericsson
836 USA
838 Phone: +1 724 931 9316
839 Email: scott.mansfield@ericsson.com
841 Yuji Tochio (editor)
842 Fujitsu
843 Japan
845 Email: tochio@jp.fujitsu.com
847 Huub van Helvoort (editor)
848 Hai Gaoming BV
849 The Netherlands
851 Phone: +31 924 8936
852 Email: huubatwork@gmail.com
854 Maarten Vissers (editor)
855 Huawei
856 China
858 Phone: +31 62 611 2004
859 Email: maarten.vissers@huawei.com
861 Paul Doolan (editor)
862 Coriant
863 Germany
865 Phone: +1 972 357 5822
866 Email: paul.doolan@coriant.com