Technical Committee

Customer Network Management (CNM)
for ATM Public Network Service
(M3 Specification)

af-nm-0019.000
Revision 1.04
October, 1994

© 1994  The ATM Forum.  All Rights Reserved.  Limited reproduction of this specification is authorized for internal use only by companies that received it from the ATM Forum.  External distribution is prohibited.  The authors believe that the information in this publication is accurate as of its publication date.  Such information is subject to change without notice.  The ATM Forum is not responsible for any errors.

The receipt or any use of this document or its contents does not in any way create by implication or otherwise:

• Any express or implied license under any of the member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein: nor

• Any warranty or representation that the member companies will announce any product(s) and/or services(s) related thereto, or if such announcements are made, that such announced products(s) and/or services(s) embody any or all of the ideas, technologies, or concepts contained herein; nor

• Any form of relationship between the member companies and the recipient or user of this document.

Editors:	Thomas A. Meserole

		Anil Prasad

TABLE OF CONTENTS

1.  Introduction
1.1   Purpose of Document
1.2   Definitions
1.3   Relevant Standards
1.4   ATM Network Management Reference Model
1.5   Definition of the M3 Interface

2.   Customer Network Management Requirements
2.1   Introduction
2.2   Classes of Requirements
2.3   General M3 Requirements
2.3.1    Data Currentness of M3 Management Information
2.3.2    Message Response Times Across the M3 Interface
2.3.3    M3 Interface Transaction Related Requirements
2.4   Class I Requirements
2.5   Class II Requirements
2.5.1    Class II ATM Subgroup
2.5.2    Class II VPC / VCC Subgroup
2.5.3    Class II Traffic Subgroup

3.   M3 Management Information Base for Class I

4.   M3 Management Information Base for Class II

5.   M3 Link Transport
5.1   Transport Alternatives
5.2   Factors Affecting Selection of an M3 Transport Alternative

1. Introduction

1.1 Purpose of Document

This document defines the possible types of Asynchronous Transfer Mode (ATM) network management service that a public network provider could offer to a customer using a public ATM network.   This document is an ATM customer network management requirements definition, interface specification and object definition. This specification is intended to be used for Customer Network Management (CNM) of an ATM Permanent Virtual Circuit (PVC) Service. It provides information that allows customers to manage performance, fault and configuration information about their ATM service interfaces.

1.2 Definitions

For purposes of this specification the follow terms are used:

Must, Shall, or Mandatory - the item is an absolute requirement for a class of M3 service.  This is highlighted with an R(n) prior to the item.

Should - the item is highly desirable for this class of M3 service.

May or Optional - the item is not compulsory for this class of M3 service and may be followed or ignored according to the needs of the public network provider.   This is highlighted with an O(n) prior to the item.

Not Applicable - the item is outside the scope of this specification.

For Further Study - the item needs additional work prior to recommendation of a specification.

Conditional Requirement - the item is required if certain specified conditions apply.   This is highlighted with an CR(n) prior to the item.

1.3 Relevant Standards

The following is a list of standards and interworking agreements on which this ATM Service Customer Network Management specification is based:

[1] ATM Forum User-Network Interface Specification,  Version 3.0

[2] Internet Engineering Task Force RFC 1213, K. McCloghrie, M. Rose, “Management Information Base for Network Management of TCP/IP-based Internets: MIB-II”, 03/26/1991.

[3] Internet Engineering Task Force RFC 1573, K. McCloghrie, F. Kastenholz, “Evolution of the Interfaces Group of MIB-II”, 01/20/1994.

[4] Internet Engineering Task Force RFC 1695, M. Ahmed and K. Tesink, “Definitions of Managed Objects for ATM Management, Version 8.0 using SMIv2”, 08/25/1994.

[5] Internet Engineering Task Force RFC 1407, T. Cox, K. Tesink, “Definitions of Managed Objects for the DS3/E3 Interface Type”, 01/26/1993.

[6] Internet Engineering Task Force RFC 1406, F. Baker, J. Watt, “Definitions of Managed Objects for the DS1 and E1 Interface Types”, 01/26/1993.

[7] Internet Engineering Task Force RFC 1595, T. Brown, K. Tesink, “Definitions of Managed Objects for the SONET/SDH Interface Type”, 03/11/1994.

[8] Internet Engineering Task Force RFC 1334, B. Lloyd, W. Simpson, “PPP Authentication Protocols”, 10/20/1992

[9] Internet Engineering Task Force RFC 1483, J. Heinanen, “Multiprotocol Encapsulation over ATM Adaptation Layer 5”, 07/20/1993.

[10] Internet Engineering Task Force RFCs:
	RFC 1155 K. McCloghrie, M. Rose, “Structure and Identification of Management 	Information for TCP/IP-based Internets”, 05/10/1990.
	RFC 1157 M. Schoffstall, M. Fedor, J. Davin, J. Case, “A Simple Network 	Management Protocol (SNMP)”, 05/10/1990.
	RFC 1212 K. McCloghrie, M. Rose, “Concise MIB Definitions”, 03/26/1991.
	RFC 1215 M. Rose, “A Convention for Defining Traps for use with the SNMP”, 	03/27/1991.

[11] Internet Engineering Task Force RFCs:
	RFC 1441 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Introduction to version 	2 of the Internet-standard Network Management Framework”, 05/03/1993.
	RFC 1442 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Structure of 		Management Information for version 2 of the Simple Network Management 	Protocol (SNMPv2)”, 05/03/1993.
	RFC 1443 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Textual Conventions 	for version 2 of the Simple Network Management Protocol (SNMPv2)”, 	05/03/1993.
	RFC 1444 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Conformance 	Statements for version 2 of the Simple Network Management Protocol 	(SNMPv2)”, 05/03/1993.
	RFC 1445 J. Davin, K. McCloghrie, “Administrative Model for version 2 of the Simple 	Network Management Protocol (SNMPv2)”, 05/03/1993.
	RFC 1446 J. Galvin, K. McCloghrie, “Security Protocols for version 2 of the Simple 	Network Management Protocol (SNMPv2)”, 05/03/1993.
	RFC 1447 K. McCloghrie, J. Galvin, “Party MIB for version 2 of the Simple Network 	Management Protocol (SNMPv2)”, 05/03/1993.
	RFC 1448 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Protocol Operations for 	version 2 of the Simple Network Management Protocol (SNMPv2)”, 05/03/1993.
	RFC 1449 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Transport Mappings for 	version 2 of the Simple Network Management Protocol (SNMPv2)”, 05/03/1993.
	RFC 1450 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Management 	Information Base for version 2 of the Simple Network Management Protocol 	(SNMPv2)”, 05/03/1993.
	RFC 1451 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Manager to Manager 	Management Information Base”, 05/03/1993.
	RFC 1452 J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Coexistence between 	version 1 and version 2 of the Internet-standard Network Management 	Framework”, 05/03/1993.

1.4   ATM Network Management Reference Model

	Figure 1:  ATM Network Management Model

The model shown in Figure 1 is the ATM Forum Network Management Sub-Working Group’s model for describing the various types of network management needed to support ATM devices, private networks, public networks and the interaction between them.  In this model, M1 is the ATM management interface needed to manage an ATM terminal device.  M2 is the management interface needed to manage a private ATM network.  M4 is the management interface needed to manage a public network service, including both network element management and service management functions.  M3 is the management interface needed to allow a customer to supervise their use of their portion of a public ATM network.  M5 is the management interface needed for management interaction between two public network providers.  M3 functions defined in this document include configuration, fault and performance management at this time.  

While the M2, M3, M4 and M5 management definitions can provide a top down network wide view, they are not the only management functions relevant to ATM.  The Interim Local Management Interface (ILMI) provides an ATM link specific view of the configuration and fault parameters of a User Network Interface (UNI).  The UNI also provides some layer management functionality via Operations Administration And Maintenance (OAM) cells.    Since the ILMI allows information retrieval by customers from a public network, it can be considered a CNM service.  However, the ILMI is embedded in the UNI and must be processed by equipment directly connected to a UNI.  In contrast the M3 interface described by this document allows direct access by customer premises based management systems to the CNM service.  Refer to the UNI specification for more ILMI and OAM details.  

1.5 Definition of the M3 Interface

This document defines the ATM management requirements and interface specifications for the M3 public network provider to private network manager.  These M3 requirements are defined in two classes to allow public network providers to offer modular, incremental capabilities to meet different levels of customer’s needs.  Figure 2 shows how a typical customer might use an M3 interface to manage the interaction of his own ATM and the public ATM networks.

	Figure 2: Customer Management of Private & Public Networks

The first class of M3 functions, Class I, identifies those requirements by which a public network provider can provide monitoring information on the configuration, fault and performance management of a specific customer’s portion of a public ATM network.  Examples of this class are:
   A) retrieving performance management data for a UNI link
   B) reporting an alarm (or trap) message following the loss of a UNI link
       from a customer site to the public network.  
Section 2.4 defines the requirements for Class I and section 3 identifies the specific objects for Class I.

The second class of M3 functions, Class II, identifies those requirements by which a customer can request the addition, modification or deletion of virtual connections and subscription information in a public ATM network.  The connections shall occur between existing physical facilities, and all of the facilities should belong to a single customer.  An example of this class would be when a customer requests a new ATM virtual path between two of his existing UNI connections to the public network.  Section 2.5 defines the requirements for Class II and section 4 defines the specific objects for Class II.

With the M3 interface a customer is provided a view of a virtual ATM network, showing the customer’s logical portion of the public ATM network.  Management of the actual internal aspects of the network (e.g., switching elements, line cards, and network routing tables) is outside the scope of this specification. 

The M3 service is provided by the public network provider via a Customer Network Management (CNM) agent in the provider’s ATM network.  Typically a CNM agent represents only a single public ATM network provider.  The public network supports only a segment of a PVC.  The CNM agent supports the MIBs defined for the supported M3 Classes.  These MIBs model a PVC segment through one public ATM network. If the customer's PVCs traverse multiple public networks, then the customer NMS could obtain information from multiple CNM agents to retrieve the customer’s end-to-end view of their service.

M3 Transport

There are several methods for how the M3 information is physically transported between the public network provider and the customer.  Section 5 of this document discusses some of the various alternatives and their respective benefits.

2. Customer Network Management Requirements

2.1 Introduction

This section describes the Customer Network Management requirements for the M3 interface. The purpose of this section is to identify those general requirements needed to provide an M3 service.  The requirements are listed as general requirements, which are applicable to all classes and as individual requirements for each class.

2.2 Classes of Requirements

Requirements for the M3 interface are classified into two categories to allow public network providers to offer modular incremental capabilities to meet different levels of customer’s needs as follows:

Class I: This class identifies those requirements by which a public network provider can provide monitoring information on the configuration, fault and performance management of a specific customer’s portion of a public ATM network.

Class II: This class identifies those requirements by which a customer can request the addition, modification or deletion of virtual connections and subscription information in a public ATM network. 

2.3 General M3 Requirements

All of the requirements listed in this section are mandatory if a public network provider offers any of the two classes of M3 service.

R(1)  Class I is mandatory.  

CR(1)  Within Class I, the requirements for support of some objects are conditional on the specific configuration (e.g. SONET support for SONET access facilities or DS3 support for DS3 facilities).

O(1)  Class II is optional.

R(2)  The M3 protocol shall be the Simple Network Management Protocol (SNMP) for the functions specified in Class I and II.  

R(3)  The M3 Management Information Bases (MIBs) shall be primarily based on the Internet Engineering Task Force’s (IETF) SNMP standards.  Reference items 2 through 7 in section 1.3.

O(2)  This specification allows use of either SNMPv1 or SNMPv2.  SNMPv1 is currently widely supported by potential ATM users.  However, SNMPv2 supports enhanced security which is particularly useful for Class II.

While the M3 interface deals primarily with configuration, fault and performance management of a customer’s portion of a public ATM network, it should be noted that:

R(4)  It is a mandatory security requirement of the public network provider to supply information on the public ATM network that is relevant only to the specific customer.  That is, the public network provider shall maintain security management such that no customer may view another customer’s portion of the network.

R(5)  The M3 service shall support management of point-to-point Permanent Virtual Connections (PVC) and ATM UNI interfaces.

CR(2)  M3 support for multipoint PVCs is required if multipoint service is offered.

The primary scope of this document is for PVCs.  This specification’s applicability to Switched Virtual Connections (SVC) is for further study.

Support for M3 management of multi-customer interoperation is for further study.

2.3.1  Data Currentness of M3 Management Information

Data currentness refers to the maximum elapsed time since the value of a managed information item across the M3 interface was known to be current.  This section defines the data currentness of the various objects and traps used to support the M3 services.

R(6)  The data currentness of ATM information retrievable via the M3 interface shall have a maximum value of T1 seconds.  The value of T1 is public network provider specific.

R(7)  In addition, the public network provider is required to notify appropriate CNM system(s) within a specific time T2 of the occurrence of an event in an ATM network.  The value of T2 is public network provider specific.  T2 is required for those events that affect the performance of a user's use of the ATM network and services including, but not limited to, the following:

- ATM UNI physical link status change, i.e., when there is a link failure or when the link is up after the failure.

- ATM UNI Transmission Convergence (TC) sub layer status change, i.e., when the TC sub layer fails or when the TC sub layer is up after the failure.

- PVC status change, i.e., when there is a PVC failure or when the PVC is up after the failure.

- Restart of the public network provider NM agent after the failure.

2.3.2  Message Response Times Across the M3 Interface

Response time refers to the elapsed time from the submission of a request message by the private NMS across the M3 interface to the receipt of the corresponding response message from the public network provider’s NM Agent.  The response times will vary for different types of request messages and are public network provider specific.

2.3.3  M3 Interface Transaction Related Requirements

R(8)  The public network provider network management agent is required to keep track of SNMP request messages that it receives across the M3 interface.

R(9)  The public network provider network management agent shall support the information identified in the SNMP Group defined in reference 3.  In addition, the public network provider NM agent may maintain a log of all received Set-Request messages and may allow customer retrieval of the log information via a public network provider specific mechanism.

2.4  Class I Requirements:

This section defines the requirements for an ATM M3 Class I service.  Class I identifies those requirements by which a public network provider can provide monitoring information on the configuration, fault and performance management of a specific customer’s portion of a public ATM network.  The requirements are as follows:

R(10)  Class I shall be an SNMP "read-only" class of service.

Retrieve General UNI Protocol Stack Information
R(11)  The M3 link shall provide the CNM customer with general information on the public network provider's CNM agent and protocols used for customer's UNIs, and the status of the layers.

Retrieve General ATM Level Performance Information
R(12)  The M3 link shall provide the CNM customer with performance information of the ATM level of customer's UNIs.

Retrieve Physical Level Performance and Status Information
R(13)  The M3 link shall provide the CNM customer with performance information of the physical level of customer's UNIs.

Retrieve ATM Level Configuration Information
R(14)  The M3 link shall provide the CNM customer with configuration information of the ATM level of customer's UNIs.  The ATM UNI cell layer configuration information provides information about how the ATM UNI is configured and the status of the ATM UNI at the ATM cell level.

Retrieve Physical Level Configuration Information
R(15)  The M3 link shall provide the CNM customer with configuration information of the Physical level of customer's UNIs.  The ATM UNI physical layer configuration information provides information about how the ATM UNI is configured at the physical level and the alarm status of the physical line.

Retrieve ATM Level Virtual Path Link Configuration and Status Information
R(16)  The M3 link shall provide the CNM customer with configuration information of the ATM Virtual Path Link level of customer's UNIs.  The VPL ATM level configuration information can be used to determine the configuration and the status of the VPL at an ATM UNI.

Retrieve ATM Level Virtual Channel Link Configuration and Status Information
CR(3)  The M3 link shall provide the CNM customer with configuration information of the ATM Virtual Channel Link level of customer's UNIs.  The VCL ATM level configuration information can be used to determine the configuration and the status of the VCL at an ATM UNI.  If a public network provider does not offer virtual channel switching service, then requirements CR(3) and CR(5) are not required.

Retrieve Virtual Path Connection Configuration and Status Information
CR(4)  The M3 link shall provide the CNM customer with configuration and status information of the ATM Virtual Path Connections of customer's UNIs.  The Virtual Path Connection identifies the path connection through a public ATM network between two or more virtual paths at individual UNIs.  If a public network provider does not offer virtual path switching service, then requirement CR(4) is not required.

Retrieve Virtual Channel Connection Configuration and Status Information
CR(5)  The M3 link shall provide the CNM customer with configuration and status information of the ATM Virtual Channel Connections of customer's UNIs.  The Virtual Channel Connection identifies the channel connection through a public ATM network between two or more virtual channels at individual UNIs.  If a public network provider does not offer virtual channel switching service, then requirements CR(3) and CR(5) are not required.

Retrieve Traffic Characterization Information
R(17)  The M3 link shall provide the CNM customer with information on preconfigured or configured traffic descriptors for customer's UNIs.  

Receive Event Notifications from the Public Network Provider
R(18)  The M3 link shall provide the CNM customer with all linkUp and linkDown alarms associated with the status of customer's UNIs.

2.5 Class II Requirements

This section defines the requirements for an ATM M3 Class II service.  Class II identifies those requirements by which a customer can request the addition, modification or deletion of virtual connections and subscription information in a public ATM network. 

R(19)  It is a requirement that the public network provider support Class I M3 service if that provider supports Class II M3 service.

Class II functionality is subdivided into three subgroups to allow for functional implementations that meet the modular needs of customers.  These three subgroups aligned as follows:
- ATM Level Subgroup:  contains all configuration information for the ATM
	 level.
- VPC/VCC Level Subgroup:  contains all configuration information for the
	 VPC and VCC levels.
- Traffic Subgroup:  contains traffic related information.

R(20)  For conformance to Class II, the public network provider shall implement one or more Class II subgroups.  If the Traffic Subgroup is supported, then the VPC/VCC Level Subgroup shall be supported.

2.5.1  Class II ATM Level Subgroup

The following functionality shall be supported if the ATM Level Subgroup of Class II is supported.

Modify ATM Level Information Configuration Information
O(3)  The M3 interface may provide the CNM customer the ability to modify ATM Level Information Configuration Information.

2.5.2  Class II VPC/VCC Subgroup

The following functionality shall be supported if the VPC/VCC Subgroup of Class II are supported.

Modify ATM Level Virtual Path Link Configuration and Status Information
O(4a)  The M3 interface may provide the CNM customer the ability to modify ATM Virtual Path Link Configuration and Status Configuration Information.

Modify ATM Level Virtual Channel Link Configuration and Status Information
O(4b)  The M3 interface may provide the CNM customer the ability to modify ATM Virtual Channel Link Configuration and Status Configuration Information.

Modify Virtual Path Connection Configuration and Status Information
O(4c)  The M3 interface may provide the CNM customer the ability to modify ATM Virtual Path Connection Configuration and Status Configuration Information.  The Virtual Path Connection identifies the path connection through a public ATM network between two or more virtual paths at individual UNIs.

Modify Virtual Channel Connection Configuration and Status Information
O(4d)  The M3 interface may provide the CNM customer the ability to modify ATM Virtual Channel Connection Configuration and Status Configuration Information.  The Virtual Channel Connection identifies the channel connection through a public ATM network between two or more virtual channels at individual UNIs.

2.5.3  Class II Traffic Subgroup

The following functionality shall be supported if the Traffic Subgroup of Class II is supported.

Modify Traffic VC Characterization Information
O(5a)  The M3 interface may provide the CNM customer the ability to modify ATM Traffic descriptors and information objects for Virtual Channel Connections.

Modify Traffic VP Characterization Information
O(5b)  The M3 interface may provide the CNM customer the ability to modify ATM Traffic descriptors and information objects for Virtual Path Connections.

3.  M3 Management Information Base for Class I

This section identifies several managed object definitions to support the Class I M3 interface requirements.  All of the objects referred to by this section are already defined in other MIB standards.  They will be referenced here, but will not be redefined here in order to insure future compatibility with those other standards.  Please refer to the appropriate standards for exact definitions of the relevant objects.

The interfaces group of MIB II defines generic managed objects for managing interfaces.  Section 8.2.1 of the ATM MIB defines specific interpretation of the IfTable that are relevant to Class I.

Figures 3 and 4 provide a high level graphical view of many of the relevant MIB objects needed to support this specification and the objects’ respective locations in the MIB tree.  

	Figure 3:  MIB Object Tree

	Figure 4: Internet Engineering Task Force ATM MIB Tree

The following objects support the Class I requirements.  The relevant requirement number is listed with each requirement to allow easy reference. Note that for Class I, the Class I objects referred to should be defined as read-only if Class II is not supported.

Retrieve General CNM Agent and UNI Protocol Stack Information  R(11)
The following MIB portion(s) shall be supported in order to support this feature:
- MIB II: system group
- RFC1573: Interfaces group, including ifTable and ifStackTable as per references [3][4].  Note that ifTable is applied to each protocol level
	(e.g. see [4] [7]).
- MIB II: SNMP group, indicating the CNM agent's SNMP-related statistics 
	pertinent to a particular customer

Retrieve General ATM Level Performance Information  R(12)
The following MIB portion(s) shall be supported in order to support this feature:
- RFC1573: ifTable as specified in [3][4]

Retrieve Physical Level Performance and Status Information  R(13)
The following MIB portion(s) shall be supported in order to support this feature (only one of these MIBs is supported for a given UNI as applicable):
- RFC1407: all tables except the dsx3ConfigTable
- RFC1406: all tables except the dsx1ConfigTable (fractional DS1/E1 is not 
	supported)
- RFC1595: all tables except the configuration tables and the VT tables.
	(SONET MIB).

- ATM MIB: atmInterfaceDs3PlcpTable or atmInterfaceTCTable if applicable.

Retrieve ATM Level Information Configuration Information  R(14)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmInterfaceConfTable.

Retrieve Physical Level Configuration Information  R(15)
The following MIB portion(s) shall be supported in order to support this feature.  Only one of these MIBs is supported for a given UNI as applicable:
- RFC1407:  dsx3ConfigTable
- RFC1406:  dsx1ConfigTable except fractional DS1/E1 is not supported.
- RFC1595:  all configuration tables except the sonetVtConfigTable.

Retrieve ATM Level Virtual Path Link Configuration and Status 
  Information  R(16)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmVplTable.

Retrieve ATM Level Virtual Channel Link Configuration and Status Information  CR(3)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmVclTable.

Retrieve Virtual Path Connection Configuration and Status Information  CR(4)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmVpCrossConnectTable and atmVpCrossConnectIndexNext.

Retrieve Virtual Channel Connection Configuration and Status 
  Information  CR(5)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmVcCrossConnectTable and atmVcCrossConnectIndexNext.

Retrieve Traffic Characterization Information  R(17)
The following MIB portion(s) shall be supported in order to support this feature (read-only):
- ATM MIB: atmTrafficDescrParamTable.

Receive Event Notifications from the Public Network Provider  R(18)
- SNMP: warmStart, coldStart, linkUp, linkDown.

4.  M3 Management Information Base for Class II

This section identifies several managed object definitions to support the Class II M3 interface requirements.  All of the objects referred to by this section are already defined in other MIB standards.  They will be referenced here, but will not be redefined here in order to insure future compatibility with those other standards.  Please refer to the appropriate standards for exact definitions of the relevant objects.

Many of the objects in this section are identical to the objects mentioned for Class I.  The key difference is that with Class II many of these objects can now be modified (write) by the customer instead of being read only. If Class II is supported, some of these objects which were defined as read-only in Class I, are redefined here as read-write access. Exact details are noted below.

The following managed object definitions are identified in support of the Class II M3 interface requirements.  The relevant requirement number is listed with each requirement to allow easy reference.

Modify ATM Level Information Configuration Information  O(3)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmInterfaceConfTable.

Modify ATM Level Virtual Path Link Configuration and Status 
  Information  O(4a)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmVplTable.

Modify ATM Level Virtual Channel Link Configuration and Status  
  Information  O(4b)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmVclTable.

Modify Virtual Path Connection Configuration and Status 
  Information  O(4c)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmVpCrossConnectTable and atmVpCrossConnectIndexNext.

Modify Virtual Channel Connection Configuration and Status 
  Information  O(4d)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmVcCrossConnectTable and atmVcCrossConnectIndexNext.

Modify Traffic Characterization Information  O(5a & b)
The following MIB portion(s) shall be supported in order to support this feature (read-write as per [4]):
- ATM MIB: atmTrafficDescrParamTable.

5.  M3 LINK TRANSPORT

The M3 link of the ATM Forum Network Management Model provides for communication between a private ATM network management system and a public ATM network management system.  This section does not establish implementation requirements, but describes for information purposes only possible alternatives for M3 link physical transport.  The exact alternative used for the connection may vary by customer or public network provider and can be based on trade-offs in security, cost, traffic volumes, traffic priorities, reliability and other features.  This section discusses some of the benefits and limits of the various alternatives.  The alternatives shown are not exhaustive.

The customer's NMS will typically access the SNMP proxy agent within the provider's ATM network using SNMP over UDP over IP.  When accessing the public network provider's M3 interface over a dial up or leased line, then PPP [8] is used.  When accessing the M3 interface via an ATM UNI, then a PVC with AAL5 encapsulation is used from the customer's premises equipment to the provider's SNMP proxy agent.

The M3 link may be used to transport additional public network provider specific information between the provider and their customers.

5.1  Transport Alternatives:

There are three typical options for the lower layer connection: dedicated circuit, circuit switched and packet/cell (ATM) switched.  Figure 5 shows how these three alternatives would be used to transport the M3 information.

Dedicated Circuit:
With this method of connection a dedicated circuit (private line) is installed between the private network management system site and the public network management system site.  The dedicated circuit is used solely for the transmission of management system information.  The circuit bandwidth could vary depending upon the ability of both network operators ability to handle larger or smaller transmission speeds.

Circuit Switched:
With this method of connection a dial up circuit is used upon demand between the private network management system site and a connection to public network management system.   This dial up circuit can be traditional public switched voice network with modems on both ends or a digital switched network.  For security reasons, dial back facilities may be recommended.

Packet/Cell (ATM) Switched:
With this method of connection a cell switched circuit is established between the private network management system and the public network management system.  This is envisioned as using the ATM network being managed to transport the M3 management information.

Multiple Combinations: 
It is possible to use 2 or more of the above methods to provide enhanced reliability or handle large data volumes.  In this case a primary method from the above 3 alternatives is selected and a backup method is used when the primary method fails or has insufficient capacity to handle the traffic volume.  It is also possible to have duplicate transport links of any of the above types.

	Figure 5: M3 Link Transport Alternatives

5.2  Factors Affecting Selection of an M3 Transport Alternative

There are several factors which affect which M3 transport alternative is the best fit for a given customer.  These factors include, but are not limited to cost, security, traffic volumes, ATM class of service, reliability and availability of the desired alternative.  These factors are discussed below in more detail.

5.1. Cost:  Exact costs will of course vary with the specific public network provider's rate structure for the various options.  However, cell switched services tend to be distance insensitive, whereas circuit switched and dedicated circuits tend to be distance band specific.  This means that if the sites of the private and public network management systems are close (or at least priced that way), a dedicated or circuit switched connection may be cheaper.  Several of the items below also affect the potential cost of the alternatives.

5.2. Traffic Volume:  If a large volume of network management information is to be moved across the M3 link it may be cheaper to put in a dedicated circuit directly from the private network management system site to the public network management system site.  If the traffic volume is low and there is little competing traffic across the cell switched (ATM) link, the use of the cell switched link may be less costly.  

5.3. Class of service for Network Management information:  If the alternative of cell switched (ATM) data is chosen, the customer should insure that the class of service (traffic priority) assigned to the network management data is of sufficient priority to insure its delivery.  If not, other data sharing the link may take priority and cause delays or loss of data for the management information being transmitted.  If multiple classes of service are available for the transport of network management data, it may be desirable to transport alarm or fault data at a higher priority than configuration or performance management data.

5.4. Security:  Routing network management data across the private or public ATM links and networks may pose more of a security problem that the use of dedicated or circuit switched links due to ability of unwanted parties to eavesdrop on the shared media provided by the transport network.  The security will vary with the specific implementations of the public and private network manufacturers and providers.  Use of dial back modems is possible for circuit switched links and adds increased security.  No matter which type of physical connection is used, additional security measures in the upper level communication protocols can also be used.   Use of secure PPP also provides a more secure level of connection.

5.5. Reliability:  Depending upon the specific implementations of the public network operators, cell (ATM) switched connections may be more reliable and survive link and switch failures.  However for this to occur the public and private networks must be able to dynamically re-establish a connection following a switch or link failure within a network.  This is not always true for all manufacturer's implementations.  Specific public network providers may provide automatic restoral for failure of dedicated or circuit switched connections.  There may be a premium cost for this service.

If the M3 connection is cell switched and the cell switched network encounters problems, the management information to detect or correct the problem may be prevented from arriving  due to the network problem.  Thus it may be more desirable to use a transport alternative different from the actual network being managed.

5.6. Availability:  Not all public network providers may offer all three methods of connection.  Each public network provider may have chosen only one method of connection based on existing facilities, market demand, ability to offer service quickly, etc.  The choice of how to connect the M3 link may also be limited based on the private network management system supplier's ability to support a specific alternative.

==================================================================