Technical Committee

Circuit Emulation Service
Interoperability
Specification
Version 2.0

af-vtoa-0078.000

January 1997

Circuit Emulation Service Interoperability Specification
af-vtoa-0078.000
January 1997
(C) 1997 The ATM Forum. All Rights Reserved. No part of this publication may be reproduced in any form or by any means.
The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication.
Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication.
The receipt or any use of this document or its contents does not in any way create by implication or otherwise:
o	Any express or implied license or right to or under any ATM Forum 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
o	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
o	Any form of relationship between any ATM Forum member companies and the recipient or user of this document.
Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them be virtue of participation in The ATM Forum.
The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.
NOTE: The user’s attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require the use of an invention covered by patent rights held by ATM Forum member companies or others. By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights. ATM Forum member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. For additional information contact:
The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Ste 304
Mountain View, CA, CA 94040-1313
Tel: +1-415-949-6700
Fax: +1-415-949-6705

Table of Contents
1. Introduction	
1.1 Purpose of Document	
1.2 Scope of Document	
1.3 Structure of Document	
1.4 Terminology	
1.5 Reference Model and Terms	
1.6 References	
1.6.1 Normative	
1.6.2 Informative	
1.7 ATM Physical Interfaces	
2. Structured DS1/E1/J2 Nx64 kbit/s Service	
2.1 Service Description	
2.1.1 Framing	
2.1.2 Timeslot Assignment	
2.1.3 Clocking	
2.1.4 Jitter and Wander	
2.1.5 Facility Data Link	
2.1.6 Bit Oriented Messages	
2.1.7 Alarms	
2.1.8 Signalling Bits	
2.1.9 Service Performance Characteristics	
2.1.9.1 End-to-End Delay	
2.1.9.2 Error Ratios	
2.1.10 Electrical	
2.2 AAL 1 Requirements	
2.2.1 Data Transfer Service Type	
2.2.2 Cell Utilization	
2.3 AAL User Entity Requirements	
2.3.1 Cell Coding	
2.3.1.1 Cell Coding for DS1, E1 and J2 Nx64 Basic Service	
2.3.1.2 Cell Coding for DS1, E1 and J2 Nx64 with CAS	
2.3.2 Bit Ordering	
2.3.3 Loss/Error Response	
2.3.3.1 Lost and Misinserted Cells	
2.3.3.2 Buffer Overflow/Underflow	
2.4 Clock Distribution Guidelines	
3. DS1/E1/J2 Unstructured Service	
3.1 Service Description	
3.1.1 Framing	
3.1.2 Clocking	
3.1.3 Jitter and Wander	
3.1.4 Facility Data Link	
3.1.5 Alarms	
3.1.6 Service Performance Characteristics	
3.1.6.1 End-to-End Delay	
3.1.6.2 Error Ratios	
3.1.7 Electrical	
3.2 AAL 1 Requirements	
3.2.1 Data Transfer Service Type	
3.2.2 Cell Utilization	
3.3 AAL User Entity Requirements	
3.3.1 Cell Coding	
3.3.2 Loss/Error Response	
3.3.2.1 Lost and Misinserted Cells	
3.3.2.2 Buffer Overflow/Underflow	
3.4 Clock Recovery	
3.4.1 SRTS	
3.4.2 Adaptive	
4. Unstructured DS3/E3 Service	
4.1 Service Description	
4.1.1 Framing	
4.1.2 Clocking	
4.1.3 Jitter and Wander	
4.1.4 Alarms	
4.1.5 Service Performance Characteristics	
4.1.5.1 End-to-End Delay	
4.1.5.2 Error Ratios	
4.1.6 Electrical	
4.2 AAL1 Requirements	
4.2.1 Data Transfer Service Type	
4.2.2 Cell Utilization	
4.3 AAL User Entity Requirements	
4.3.1 Cell Coding	
4.3.2 Loss/Error Response	
4.3.2.1 Lost and Misinserted Cells	
4.3.2.2 Buffer Overflow/Underflow	
4.4 Clock Recovery	
4.4.1 SRTS	
4.4.2 Adaptive	
5. ATM Virtual Channel Requirements	
5.1 Traffic Parameters and Tolerances	
5.1.1 Unstructured DS1 Cell Rate	
5.1.2 Unstructured E1 Cell Rate	
5.1.3 Structured Nx64 Service Cell Rate	
5.1.3.1 Basic Service	
5.1.3.2 DS1/E1/J2 Service w/CAS	
5.1.4 Unstructured DS3 Cell Rate	
5.1.5 Unstructured E3 Cell Rate	
5.1.6 Unstructured J2 Cell Rate	
5.2 ATM Virtual Channel Payload Type and CLP	
5.2.1 Cell Loss Priority (CLP)	
5.2.2 Payload Type Identifier	
5.3 Impairments	
5.3.1 Cell Transfer Delay	
6. Signalling	
6.1 Addresses and Identifiers for CES Switched Virtual Channels (SVCs)	
6.2 SETUP Message Contents	
6.2.1 ATM Traffic Descriptor	
6.2.2 Broadband Bearer Capability	
6.2.3 Quality of Service Parameter	
6.2.4 ATM Adaptation Layer Parameters	
6.2.5 Broadband Low Layer Information	
7. Call Initiation Procedures	
7.1 Overview of SVC Procedures	
7.2 MIB Variables	
7.3 Active SVC Procedures	
7.4 Call Collision	
7.5 Call Retry	
8. Management	
8.1 CES IWF Interfaces (per RFC 1573)	
8.2 CES IWF Layers (per RFC 1573)	
8.3 CES IWF to DS0 Mapping (per RFC TBD [the new IETF DS0 MIB])	
8.4 CES MIB	
8.4.1 CES Version 1 MIB	
8.4.2 CES Version 2 MIB	
Annex A:  Impairment Analysis	
Annex B:  Abbreviations	

List of Figures
Figure 1-1:  Circuit Emulation Service Reference Model	
Figure 2-1:  N64 Service Taxonomy	
Figure 2-2:  DS1/E1/J2 Structured Service Interworking Function - Layering Perspective	
Figure 2-3:  Crossconnect Example	
Figure 2-4:  Nx64 Service Interface Fault Indication	
Figure 2-5:  Example Singleframe Structure Format for 3x64 kbit/s	
Figure 2-6: Example Multiframe Structure for 3x64 kbit/s DS1/E1 with CAS	
Figure 2-7: Example Multiframe Structure for 3x64 kbit/s J2 with CAS	
Figure 2-8:  Example DS1/ESF and E1 Signalling Substructure	
Figure 2-9:  Example J2 Signalling Substructure	
Figure 2-10:  Example DS1/SF Signalling Substructure	
Figure 2-11: DS1/E1/J2 vs. ATM Bit Ordering	
Figure 2-12:  Virtual Channel Fault Indication	
Figure 3-1:  DS1/E1/J2 Unstructured Service Interworking Function - Layering Perspective	
Figure 3-2:  Unstructured DS1/E1/J2 Service Interface Fault Indication	
Figure 3-3:  Virtual Channel Fault Indication	
Figure 4-1: Unstructured DS3/E3 Service Interworking Function -- Layering Perspective	
Figure 4-2: Unstructured DS3/E3 Service Interface Fault Indication	
Figure 4-3: Unstructured DS3/E3 Virtual Channel Fault Indication	
Figure 5-1:  Reference Network Configuration	
Figure 8-1:  CES IWF Instances Mapping CBR Instances to ATM Instances	
Figure 8-2:  CES Layers from CBR Interface to ATM Interface	
Figure 8-3:  ATM, CES and CBR Mappings	

List of Tables
Table 2-1: Sample AAL1 Structure Sizes for Nx64 Service with CAS	
Table 6-1:  Broadband Bearer Capability IE Field Values for CES SVCs	
Table 6-2: QoS Parameter IE Field Values for CES SVCs	
Table 6-3:  AAL Parameters IE Field Values for Nx64 Service SVCs	
Table 6-4:  AAL Parameters IE Field Values for DS1 Unstructured Service and DS1 Logical Unstructured Service SVCs	
Table 6-5:  AAL Parameters IE Field Values for E1 Unstructured Service and E1 Logical Unstructured Service SVCs	
Table 6-6:  AAL Parameters IE Field Values for J2 Unstructured Service and J2 Logical Unstructured Service SVCs	
Table 6-7: AAL Parameters IE Field Values for DS3 Unstructured Service and DS3 Logical Unstructured Service SVCs	
Table 6-8: AAL Parameters IE Field Values for E3 Unstructured Service and E3 Logical Unstructured Service SVCs	
Table 6-9:  Broadband Low Layer Information IE Field Values for CES SVCs	
Table 8-1:  Sample CBR (9) ifTable entry of ifType ds1(18)	
Table 8-2:  Sample DS3 (10) ifTable entry of ifType ds3 (30)	
Table 8-3:  Sample ATM (1) ifTable entry of ifType atm (37)	
Table 8-4:  Sample Logical (7) ifTable entry of ifType other (1)	
Table 8-5:  Sample ds0Bundle (20) ifTable entry of ifType ds0Bundle (82)	
Table 8-6:  Sample ds0 (12) ifTable entry of ifType ds0 (81)	
Table 8-7:  Example ifStackTable Entries	

Notice:
Bellcore asserts that its U.S. Patent No 5,260,978 for Synchronous Residual Timestamp (SRTS) Timing Recovery in a Broadband Network may apply to the ATM Adaptation Layer Type 1 (AAL1) ANSI Standard (T1.630-1993) referenced in Section 3.4 of this specification.

1.	Introduction
There is a user demand for carrying certain types of constant bit rate (CBR) or “circuit” traffic over Asynchronous Transfer Mode (ATM) networks. As ATM is essentially a packet- rather than circuit-oriented transmission technology, it must emulate circuit characteristics in order to provide good support for CBR traffic.
A critical attribute of a Circuit Emulation Service (CES) is that the performance realized over ATM should be comparable to that experienced with the current PDH/SDH technology.
1.1	Purpose of Document 
This document -- referred to as the Circuit Emulation Service Interoperability Specification (CES-IS) -- specifies the ATM Forum’s interoperability agreements for supporting CBR traffic over ATM networks that comply with the Forum’s other interoperability agreements.
Note that all of the specific types of CBR service and/or specific interfaces identified within this document need not be supported in order to be compliant with this specification. Although no specific type of CBR service nor specific interface is required for compliance, support for any one or more of these will be considered as implementing a Circuit Emulation Service. However, if support for any of the specified types of CBR service and/or specific interfaces identified within this specification is provided, this support must then be provided in a manner consistent with this specification to be considered compliant.
For example, a compliant CES implementation may choose to implement a Structured DS1 Nx64 kbit/s Service and an Unstructured DS1 Service without implementing any E1, J2 or other service. This implementation would then be considered compliant for Structured DS1 Nx64 kbit/s Service and Unstructured DS1 Service, provided that these services are implemented in a manner consistent with their specification within this document.
1.2	Scope of Document 
The CES-IS specifically covers the following types of CBR service: 
1.	Structured DS1/E1 Nx64 kbit/s (Fractional DS1/E1) Service
2.	Unstructured DS1/E1 (1.544 Mbit/s, 2.048 Mbit/s) Service
3.	Unstructured DS3/E3 (44.736 Mbit/s, 34.368 Mbit/s) Service
4.	Structured J2 Nx64 kbit/s (Fractional J2) Service
5.	Unstructured J2 (6.312 Mbit/s) Service
The Structured Nx64 and Unstructured DS1/E1/J2 services described in this document offer two ways to connect DS1/E1/J2 equipment across emulated circuits carried on an ATM network. The two techniques can be used to solve different kinds of problems:
The Structured DS1/E1/J2 Nx64 service is modeled after a Fractional DS1/E1/J2 circuit, and is useful in the following situations:
1.	The Nx64 service can be configured to minimize ATM bandwidth, by only sending the timeslots that are actually needed.
2.	The Nx64 service provides clocking to the end-user equipment, so it fits into a fully-synchronous network environment.
3.	Because it terminates the Facility Data Link, the Nx64 service can provide accurate link quality monitoring and fault isolation for the DS1/E1 link between the IWF and the end-user equipment
The Unstructured DS1/E1/J2 Service provides transparent transmission of the DS1/E1/J2 data stream across the ATM network and is modeled after an asynchronous DS1/E1 leased private line. It allows for the following situations:
1.	End-user equipment may use either standard (SF, ESF, G.704 or JT-G.704) or non-standard framing formats.
2.	When end-to-end communication of the Facility Data Link or Alarm states is important.
3.	When timing is supplied by the end-user DS1/E1/J2 equipment and carried through the network. The end-user equipment may or may not be synchronous to the network.
The Unstructured DS3/E3 Service provides basic DS3/E3 Circuit Emulation Service and allows for the following situations:
1.	Standard or non-standard framing may be used by the end-user DS3/E3 equipment.
2.	End-to-end communication of P-Bit, X-Bit and C-Bit channels is provided.
3.	Timing is supplied by the end-user DS3/E3 equipment and carried through the network. The end-user equipment may or may not be synchronous to the network.
The scope of the CES-IS is limited to the essential agreements needed to reliably transport these bit rates across ATM networks that comply with the ATM Forum’s interoperability agreements. Specifying all the agreements needed to support a full service offering (for example, ATM-based video telephony) is explicitly beyond the scope of this document.
1.3	Structure of Document
Section 1 is an introduction and contains some technical material relating to all types of service. Sections 2, 3 and 4 cover Structured DS1/E1/J2 Nx64 kbit/s, Unstructured DS1/E1/J2 and Unstructured DS3/E3 Service, respectively. Each of these sections covers the following topics:
1.	Service description
2.	Service-specific AAL 1 requirements (e.g., clocking and error recovery)
3.	AAL user entity requirements (e.g., data coding/formatting, signalling)
Section 5 discusses service-specific ATM Layer requirements (e.g., cell rate and delay requirements), section 6 describes ATM signalling parameters, section 7 describes ATM call initiation procedures, and section 8 discusses the management of the CES service.
1.4	Terminology
This document uses three levels for indicating the degree of compliance necessary for specific functions, procedures and coding associated with the Circuit Emulation specification:
• 	Requirement (R-n): Functions, procedures and coding necessary for operational compatibility.
• 	Conditional Requirements (CR-n): Functions, procedures and coding necessary providing the specified optional function is implemented.
• 	Option (O-n): Functions, procedures and coding that may be useful, but are not necessary for operational compatibility.
1.5	Reference Model and Terms

Figure 1-1:  Circuit Emulation Service Reference Model
Figure 1-1 provides a reference model for circuit emulation services. Figure 1-1a) pictures two ATM Circuit Emulation Service (CES) Interworking Functions (IWFs) connected to an ATM network via physical interfaces defined in the ATM Forum UNI Specification. The CES IWFs are also connected to standard constant bit-rate (CBR) circuits (e.g., DS1/DS3, J2 or E1/E3). The job of the two IWFs is to extend the constant bit-rate circuit to which they are connected across the ATM network. They are to do this in a manner that is transparent to the terminating equipment of the CBR circuit. This means that the ATM portion of the connection should retain its bit integrity - i.e., analog signal loss can not be inserted and voice echo control cannot be performed. Thus for facilities intended to carry voice or multimedia services, any required echo control must be performed either by the terminal equipment or before the ATM CES IWF is encountered. The assumption in the CES-IS is that using AAL 1 over ATM constant bit-rate virtual channels is a simple, general, and effective method of addressing this type of application.
Figure 1-1b) shows a similar arrangement, but does not make any external physical interfaces explicit. This is intended to show that CES can be used to provide a “logical” structured or unstructured DS1/DS3/E1/E3/J2 service, even if that service is not used to bridge between existing traditional DS1/DS3, J2 or E1/E3 based circuits. It is also possible that one IWF would interface to a DS1/DS3, J2 or E1/E3 based circuit and the other would not.
1.6	References
1.6.1	Normative
UNI 3.1, ATM Forum User-Network Interface (UNI) Specification
af-bici-0013.003, ATM Forum Broadband Intercarrier Interface (B-ICI) Specification v2.0
ANSI T1.630-1993, B-ISDN ATM Adaptation Layer CBR Services
ANSI T1.627-1993, B-ISDN ATM Layer Functionality and Specification
ITU-T I.356-1993    B-ISDN ATM layer cell transfer performance
ITU-T I.362-1993 B-ISDN ATM adaptation layer (AAL) functional description
ITU-T I.363.1 1996, B-ISDN ATM Adaptation Layer (AAL) Specification, Types 1 and 2

ANSI T1.101-1994, Synchronization Interface Standard
ANSI T1.102-1993 Revised - Digital Hierarchy — Electrical Interfaces
ANSI T1.107-1995, Digital Hierarchy - Formats specifications
ANSI T1.403-1995, Carrier-to-Customer Installation — DS1 Metallic Interface
ANSI T1.404-1994, Carrier-to-Customer Installation - DS3 Metallic Interface Specification
ANSI T1.408-1990, Integrated Services Digital Network (ISDN) Primary Rate -- Customer Installation Metallic Interfaces Layer 1 Specification
ANSI T1.510-1994, Network Performance Parameters for Dedicated Digital Services — Specifications.
ITU-T G.824-1993, The control of jitter and wander within digital networks which are based on the 1544 kbit/s digital hierarchy
Bellcore TR-NWT-000170, Issue 2, January, 1993, Digital Crossconnect System Generic Requirements and Objectives

ITU-T G.702-1988 Digital hierarchy bit rates
ITU-T G.703-1991 Physical/electrical characteristics of hierarchical digital interfaces
ITU-T G.704-1995 Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44736 kbit/s hierarchical levels
ITU-T G.707-1996 Network node interface for the synchronous digital hierarchy (SDH)
ITU-T G.823-1993, The control of jitter and wander within digital networks which are based on the 2048 kbit/s digital hierarchy

IETF RFC1573, Evolution of Interfaces Group of MIB-II, January 1994.
IETF RFC TBD, Definitions of Managed Objects for the DS3/E3 Interface Type, Date TBD.
IETF RFC TBD, Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types, Date TBD.
IETF RFC TBD, Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Types, Date TBD.
IETF RFC1595, Definitions of Managed Objects for the SONET/SDH Interface Type, March 1994.

TTC Recommendation JT-G.704, Synchronous Frame Structures Used at Primary and Secondary Hierarchical Levels.
TTC Recommendation JT-G.703a, Secondary Rate User-Network Interface of Leased Line - Layer 1 Specification.
ISO/IEC 11573 (1994), Synchronization methods and technical requirements for Private Integrated Services Networks.
1.6.2	Informative
ETSI ETS 300 353 B-ISDN ATM adaptation layer (AAL) specification type 1
Bellcore GR-1113-CORE, Issue 1, July, 1994, Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols
Bellcore GR-1110-CORE, Issue 1, August 1994, Broadband ISDN Switching Systems Generic Requirements
Bellcore TA-TSV-001409, Issue 1, November 1993, Generic Requirements for Exchange Access PVC Cell Relay Services.
DTR/NA-52622 Optional aspects of AAL type 1
ANSI T1.511-1994, B-ISDN ATM Layer Cell Transfer Performance Parameters.
1.7	ATM Physical Interfaces
An ATM UNI physical interface has two characteristics that are relevant when supporting CES Service:
1.	Bandwidth - the ATM interface must provide adequate bandwidth to carry Nx64 or Unstructured traffic after segmentation.
2.	Timing - the ATM interface can be used to convey timing traceable to a Primary Reference Source from the ATM network to the CES Interworking Function, where external connection to network timing is not supported.

2.	Structured DS1/E1/J2 Nx64 kbit/s Service
A number of applications currently use Nx64 kbit/s services. For example, there are a number of DTE interfaces and video codecs that are capable of operating at Nx64 kbit/s rates for N>1. Within this section, the following conventions apply:
Nx64 Service = All modes of the Structured DS1/E1 and J2 Nx64 kbit/s Service.
DS1 Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the two IWFs involved are emulating DS1-based Nx64 kbit/s service supplied via a DSX-1 interface, T1.102-1993 Revised.
E1 Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the two IWFs involved are emulating E1-based Nx64 kbit/s service supplied via a G.703 interface.
J2 Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the two IWFs involved are emulating J2-based Nx64 kbit/s service supplied via a JT-G.703a interface.
DS1 Nx64 Basic Service = DS1 Nx64 Service with no support for carrying channel associated signaling (CAS).
E1 Nx64 Basic Service = E1 Nx64 Service with no support for carrying CAS.
J2 Nx64 Basic Service = J2 Nx64 Service with no support for carrying CAS.
DS1 Nx64 Service w/CAS = DS1 Nx64 Service with support for carrying CAS.
E1 Nx64 Service w/CAS = E1 Nx64 Service with support for carrying CAS.
J2 Nx64 Service w/CAS = J2 Nx64 Service with support for carrying CAS.
Logical Nx64 Service = All modes of Structured DS1/E1/J2 Nx64 kbit/s Service in which the non-ATM-related functions of the two IWFs involved are left unspecified.
Logical Nx64 Basic Service = Logical Nx64 Service with no support for carrying CAS.
Logical Nx64 Service w/CAS = Logical Nx64 Service with support for carrying CAS.

Figure 2-1:  N64 Service Taxonomy
Figure 2-1 shows the relationships among the members of the Nx64 Services family.
Note that the above conventions do not include any indication of specific support for CCS (Common Channel Signalling) services. The current version of this specification makes no particular provisions for its use in CCS systems, but this specification does not preclude its use in CCS systems. Specific provisions for its use in CCS systems are for further study.
2.1	Service Description
Nx64 Service is intended to emulate a point-to-point Fractional DS1, E1 or J2 circuit. The service is typically accessed via either 1.544 Mbit/s DSX-1 (T1.102 - 1993 Revised) interfaces, 2.048 Mbit/s (G.703) interfaces or 6.312 Mbit/s (JT-G.703a) interfaces. For DS1, N of the 24 timeslots available at the DSX-1 interface, where 1  N  24, are carried across the ATM network and reproduced at the output edge. For E1, 1 N  31. For J2, 1 N  96.

Figure 2-2:  DS1/E1/J2 Structured Service
Interworking Function - Layering Perspective
Because the Nx64 Service can be configured to use only a fraction of the timeslots available on the Service Interface, it is possible to allow several independent emulated circuits to share one Service Interface, as shown in Figure 2-2. The capability of allowing several AAL1 Entities to share one Service Interface, where each AAL1 Entity is associated with a different Virtual Channel Connection (VCC), allows for functional emulation of a DS1/DS0, E1/ DS0 or J2/DS0 Digital Crossconnect Switch.
In this configuration:
1.	The ATM layer is responsible for multiplexing and demultiplexing several VCCs, one to each AAL1 Entity.
2.	Each AAL1 Entity is responsible for performing segmentation and reassembly on one VCC.
3.	The Timeslot Mapping Function is responsible for assigning the stream input and output from the SAR process to specific time slots in the Service

Figure 2-3:  Crossconnect Example
Figure 2-3 shows an example crossconnect configuration in which two PBXs are connected across an ATM backbone to a Central Office switch. One virtual channel might carry 10 timeslots between one PBX and the Central Office switch; another virtual channel might carry 10 timeslots between the other PBX and the Central Office Switch. At the pair of IWF’s  near the Central Office switch, the two virtual channels are reassembled, and a total of 20 timeslots are carried across the last DS1/E1/J2 link connecting the Central Office switch and its CES IWF. Although the Nx64 Service should be useful in providing a crossconnect service, it is outside the scope of the current CES-IS to specify crossconnect service, such as that defined in Bellcore TR-NWT-000170.
(R-1) A CES IWF providing Nx64 Service shall provide one AAL1 Entity.
(O-1) Multiple CES IWF’s providing Nx64 Service may be used to provide multiple AAL1 Entities, allowing several Nx64 connections to be multiplexed onto a single service interface, with each connection utilizing different 64 kbps channels of the service interface.
2.1.1	Framing
(R-2) DS1 Nx64 Service shall be capable of interfacing with circuits using Extended Superframe Format.
(O-2) DS1 Nx64 Service may provide SF framing at a DS1 Service Interface.
(R-3) E1 Nx64 Service shall be capable of interfacing with circuits using G.704 framing.
(R-4) J2 Nx64 Service shall be capable of interfacing with circuits using JT-G.704 framing.
2.1.2	Timeslot Assignment
(R-5) The Nx64 Service shall carry any group of N 64 kbit/sec timeslots, where N can be 1 to 24, 1 to 31, or 1 to 96 for DS1/E1 and J2 respectively.
The timeslots assigned to a virtual channel are not required to be contiguous. Timeslots are assigned to a virtual circuit by MIB variables, and it should be noted that the assignment of timeslots is not required to be the same on the input and output ends of the virtual channel. Even though the timeslot assignment on input and output may be different, the CES IWFs must deliver octets at the output in the same order as they were received at the input. The Nx64 service also must maintain 125-msec frame integrity across a virtual channel. For example, given a 2x64 kbit/s emulated circuit, two octets that are sent into the input IWF’s Service Interface in one frame shall be delivered at the output IWF’s Service Interface in one frame, and in the same order.
2.1.3	Clocking
The DS1/E1/J2 Nx64 kbit/s Service requires the use of synchronous circuit timing, as recommended by ITU I.363.1. In order to support this synchronous clock recovery by the attached end-user equipment, the following requirements are stated:
(R-6) Any Nx64 Service IWF shall provide a means by which a timesource traceable to a Primary Reference Source (PRS) may be supplied.
(R-7) For DS1 Service, an IWF Service Interface shall provide 1.544 MHz timing to external DS1 equipment.
(R-8) For E1 Nx64 Service, an IWF Service Interface shall provide 2.048 MHz timing to external E1 equipment.
(R-9) For J2 Nx64 Service, an IWF Service Interface shall provide 6.312 MHz timing to external J2 equipment.
These requirements assume that the IWF provides the required synchronous circuit timing to the external equipment via the CES service interface itself. Note, however, that this does not preclude the provision of the synchronous circuit timing to the external equipment via a separate physical interface. The specification of such a separate timing interface is beyond the scope of this specification.
Section 2.4 gives more information about clock distribution techniques.
2.1.4	Jitter and Wander
(R-10) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface must meet ANSI T1.403 and G.824 for DS1 circuits.
(R-11) Wander must meet ANSI T1.403 and G.824 for DS1 circuits.
(R-12) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface must meet G.823 for E1 circuits.
(R-13) Wander must meet G.823 for E1 circuits.
(R-14) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface must meet JT-G.703a for J2 circuits.
(R-15) Wander must meet JT-G.703a for J2 circuits.
ANSI T1.403-1995 specifies that wander shall not exceed 28 UI (18 msec) peak-to-peak in any 24-hour period. Recommendations G.823 and G.824 require that network wander be maintained at less than 10 msec over any 10 000 second interval (approximately 3 hours).
2.1.5	Facility Data Link
This section applies only to DS1 ESF Nx64 service and J2 Nx64 service.
The DS1 ESF Facility Data Link associated with the Service Interface is terminated at the ESF/G.704 sublayer in the Interworking Function.
The DS1 ESF Facility Data Link is used to carry once-per-second Performance Report Messages as described in T1.403. These messages carry information on numbers of CRCs, framing errors, line code violations and other impairments detected over the last second.
(CR-1) For DS1, the CES IWF shall terminate the Facility Data Link as specified in ANSI T1.403-1995.
(CR-2) DS1 Performance-related information from T1.403-compliant FDL messages shall be stored in the IWF’s MIB, as described in Section 8.
DS1 ESF FDL messages which are not Link Management messages as defined in T1.403 may be ignored by the IWF.
The J2 Facility Data Link associated with the Service Interface is terminated at the J2/JT-G.704 sublayer in the Interworking Function.
(CR-3) For J2, the CES IWF shall terminate the Facility Data Link as specified in JT-G.704.
(CR-4) J2 Performance-related information from JT-G.704-compliant FDL messages shall be stored in the IWF’s MIB, as described in Section 8.
J2 FDL messages which are not Link Management messages as defined in JT-G.704 may be ignored by the IWF.
2.1.6	Bit Oriented Messages
This section applies only to DS1 Nx64 service.
(R-16) For DS1 using ESF, the IWF must terminate Bit Oriented Messages for Yellow Alarms and loopback as described in T1.403.
Loopbacks are handled as described in TR-NWT-000170.
2.1.7	Alarms
Several kinds of alarms can be detected at the point where the Service Interface is received by the IWF. Definition of alarm states is given in T1.403 for DS1, G.704 for E1, and JT-G.704 for J2.
Some alarm situations require that an alarm condition detected at the point where the Service Interface is received by an IWF (the “Upstream IWF”) be propagated downstream to the IWF responsible for reproducing the bit stream (the “Downstream IWF”).
When alarms are detected by the Upstream IWF, a Trunk Conditioning procedure is used to signal these alarms to downstream DS1/E1/J2 equipment.  In this case, the Upstream IWF continues to emit cells at the nominal rate, but sets the DS1/E1/J2 payload to an appropriate code to indicate Idle or Out-of-Service.  Additionally, if signalling bits are being carried by the IWF, the Upstream IWF will insert appropriate signalling codes into the DS1/E1/J2 stream before AAL1 segmentation takes place.  Trunk conditioning procedures are specified in Bellcore TR-NWT-000170 Issue 2, Section 2.5.
This technique allows DS1/E1/J2 alarm conditions to be transferred through the emulated circuit environment without causing additional ATM Layer errors.
(R-17) The IWF shall detect Loss of Signal (LOS), AIS or Yellow conditions, loss of frame synch, and loss of multiframe synch and report these conditions via the MIB.

Figure 2-4:  Nx64 Service Interface Fault Indication
(R-18) When LOS, Out-of-Frame or AIS occur, the IWF shall apply Trunk Conditioning in the downstream direction. Procedures for Trunk Conditioning are described in Bellcore TR-NWT-000170 Issue 2, Section 2.5. A Remote Alarm Indication (RAI, or ‘yellow’) shall be delivered in the upstream direction. Figure 2-4 illustrates alarm handling at the Service Interface. The exact maintenance actions required to be performed depend on the application and environment being served.
(R-19) When RAI is received at the Service Interface, the IWF shall apply trunk conditioning in the downstream direction only.
As noted earlier, this revision of this CES document does not provide any specific support for CCS signalling systems. Consequently, this section does not address a reaction of a CES IWF to an incoming AIS signal when CCS signaling is used.  It should be noted that the presence of the AIS signal will disrupt any CCS data link carried over that same link.  This disruption will cause the signaling system which uses the CCS link to declare an alarm.  In this case, no further conditioning is required.  
Similarly, a second alarming condition (in CCS systems) is not addressed by this document.  The situation is if the VC which carries the CCS link is different than the VC which carries the DS0s controlled by that CCS link.  There is currently no means of conveying an alarm on that VC which carries the DS0s to the CCS system.  This is similar to failure case in TDM networking where only some of the DS0s fail.  In TDM networking, this case is sometimes handled by network management actions and other times by DS0 testing systems used just as calls are being established. But since this version of this document does not specify support for CCS signalling systems, this situation is left for further study. 
2.1.8	Signalling Bits
The Nx64 service can support signalling in one of two modes of operation: with Channel Associated Signalling (CAS) or without CAS. Nx64 Service with CAS requires direct recognition and manipulation of the signalling bits by the CES IWF. This mode is necessary to support Nx64 applications requiring DS1 Robbed Bit Signalling or E1 CAS support.
Conversely, non-CAS mode, or Basic Service, requires no direct CAS support by the CES IWF. Basic Service can be used to support Nx64 applications not requiring signalling or those that provide signalling using Common Channel Signalling (e.g., as used in N-ISDN) or provided by other means.
(R-20) All Nx64 Service IWFs shall provide Basic Service. This mode is compatible with N-ISDN applications, as well as many video codecs.
(O-3) Nx64 Service IWFs may also provide Nx64 Service with CAS. This mode is required for much existing PBX and voice telephony equipment.
2.1.9	Service Performance Characteristics
This section describes the minimal service performance characteristics required by Nx64 Service.
2.1.9.1	End-to-End Delay
End-to-end delay requirements are application-specific. End-to-end delay requirements are beyond the scope of this specification. ITU-T Recommendation G.114 provides considerable guidance on the subject of delay.
2.1.9.2	Error Ratios
Bit Error Ratio (BER) is the ratio of the number of bit errors to the total number of bits transmitted in a given time interval. There are no specific bit-error ratio requirements for Nx64 service other than those implied by the errored second and severely-errored second requirements that follow. (Source: ANSI T1.510-1994, Network Performance Parameters for Dedicated Digital Services — Specifications.)
Service performance is also measured in terms of Errored Seconds (ES) and Severely Errored Seconds (SES).  Performance objectives for Errored Seconds and Severely Errored Seconds are given in ANSI T1.510-1994 for DS1, and in G.826 for E1.
2.1.10	Electrical
(R-21) The DS1 Nx64 Service shall provide a DSX-1 electrical interface with B8ZS coding.
(O-4) The DS1 Nx64 Service may also provide AMI coding as an option.
The Service Interface may use a connector such as the RJ48C or RJ48M, as specified in T1.403.
(R-22) The E1 Nx64 Service shall provide a G.703 interface using HDB3 line coding. G.703 allows both 75 Ohm and 120 Ohm interfaces for E1.
The E1 Service Interface may use a connector such as ISO8877 for the 120 Ohm interface, and a 75 Ohm BNC connector, as described in IECSC46D, for the 75 Ohm interface.
(R-23) The J2 Nx64 Service shall provide a JT-G.703a interface with B8ZS coding.
The J2 Service Interface shall use a 50 Ohm JIS C5412-1976 compliant connector as specified in JT-G.703a.
2.2	AAL 1 Requirements 
2.2.1	Data Transfer Service Type
(R-24) The Nx64 Service shall use the Structured Data Transfer (SDT) mode as defined in I.363.1.
ANSI document T1.630 and Bellcore GR-1113-CORE also contain descriptions of AAL1 Structured Data Transfer mode.
2.2.2	Cell Utilization 
A significant source of delay in the Nx64 Service is the “cell payload assembly delay”, or the amount of time it takes to collect enough data to fill a cell. This period of time can be reduced by sending cells that are only partially full, rather than waiting for a full 46- or 47-byte payload before sending each cell. This reduces delay at the expense of a higher cell rate.  Partial cell fill is an optional feature of a CES IWF; if available, the number of bytes to be sent in each cell can be set when the virtual channel is established, either through configuration for PVCs, or by ATM UNI 3.1 signalling for SVCs.
(R-25) The Nx64 Service Interworking Function shall be capable of sending cells without dummy octets.
(O-5) The Nx64 Service may reduce cell payload assembly delay by introducing dummy octets to complete the cell payload, as outlined in ITU I.363.1, 1996.
It should be noted that the cell padding technique described in I.363.1 requires a fixed number of payload (i.e., Service Interface) octets per cell, resulting in a variable number of pad bytes per cell, depending on the presence of the AAL1 Structure Pointer.
When padding is used with Structured Data Transfer, it should be noted that I.363.1 requires that the structure pointer span both payload and pad bytes. For example, a structure pointer with the value 46 always indicates the first octet of the second cell in a pair, no matter how much padding might be present in each cell.
2.3	AAL User Entity Requirements 
2.3.1	Cell Coding 
AAL1 as specified in ITU-T document I.363.1 has the capability to delineate repetitive, fixed-size “blocks” of data, each block being an integral number of octets in size.  This capability is used in the Nx64 service to carry N DS0 timeslots, organized into blocks.
For a block size of one octet, corresponding to a single DS0 stream (i.e. N=1) with Basic Service, AAL1 provides block delineation merely by aligning each AAL user octet with an ATM cell payload octet.
For a block size greater than one octet, AAL1 uses a pointer mechanism to indicate the start of a structure block.  This AAL type 1 CS specification requires the pointer to be inserted at the first opportunity in a cell with an even sequence count value (i.e., 0, 2, 4, 6) as indicated by the CSI bit of the AAL1 header being set to “1”. The SDT pointer must be inserted in a cell payload with an even sequence count once and only once in each set of eight cell payloads corresponding to an AAL1 sequence count cycle (i.e., 0,1,2,3,4,5,6,7). If no structure block begins with an eight cell sequence, then a pointer value of 127 shall be inserted in cell number six of the cycle. For more on Structured Data Transfer pointer generation and processing, refer to ITU Recommendation I.363.1.
The layout of the Nx64 service data within the structure blocks—or cell coding—varies with the type of Nx64 Service being supported, as described below.
Logical Nx64 Service may use any of the coding approaches described below.
Note: the need for a common method to transport CAS signaling transitions for DS1, E1, J2 and voice compression is for further study.
2.3.1.1	Cell Coding for DS1, E1 and J2 Nx64 Basic Service

Figure 2-5:  Example Singleframe Structure Format for 3x64 kbit/s
To encode Nx64 into AAL1 SDT without carrying signalling bits, a block is created by collecting N octets — one from each of the N timeslots to be carried — and grouping them in sequence. See Figure 2-5 for an example which shows the block structure for Nx64 where N=3. The block size for Nx64 Basic mode is always N octets.
(R-26) DS1, E1 and J2 Nx64 Basic Service shall encode Nx64 Service data in an AAL1 Structure of size ‘N’.
2.3.1.2	Cell Coding for DS1, E1 and J2 Nx64 with CAS
Circuits which carry the ABCD signalling bits end-to-end may also be emulated with the CES IWF, if the CAS mode option is provided.
A special AAL1 structure format is used to carry emulated circuits with CAS. In this format, the AAL1 block is divided into two sections, the first of which carries the Nx64 payload, the second of which carries signalling bits that are associated with the payload.
In CAS Mode, the payload part of the structure is one multiframe in length. For Nx64 DS1 with ESF framing, this portion of the AAL1 structure is N times 24 in length. For Nx64 E1 using G.704 framing, the payload portion of the AAL1 structure, called the Payload Substructure, is N times 16 octets in length. For Nx64 J2 using JT-G.704 framing and signalling, the payload portion of the AAL1 structure is N times 8 octets in length. In each case, the first octet in the AAL1 structure is from the first of the N timeslots in the first frame of a multiframe.
The second portion of the AAL1 structure, called the Signalling Substructure, contains the signalling bits that are associated with the multiframe. For DS1 and E1, the ABCD signalling bits associated with each time slot are packed two sets to an octet and placed at the end of the AAL1 structure.  If N is odd, the last octet will contain only four signalling bits and four zero pad bits. For J2, which utilizes a single signalling bit per channel, the signalling bits associated with each timeslot are packed eight sets to an octet and placed at the end of the AAL1 structure. If N is not a multiple of 8, the last octet will contain only the remaining number of signalling bits and the rest of the octet will be padded with zero bits.
The AAL1 Structure Pointer is used to indicate the first octet of the Payload Substructure.

Figure 2-6: Example Multiframe Structure for 3x64 kbit/s DS1/E1 with CAS
An example of the AAL1 structure for DS1/E1 Nx64 circuits with CAS is shown in Figure 2-6. In this example, N is set to three, so each AAL1 block contains payload from three timeslots, plus the three sets of signalling bits present in one multiframe.

Figure 2-7: Example Multiframe Structure for 3x64 kbit/s J2 with CAS
An example of the AAL1 structure for J2 Nx64 circuits with CAS is shown in Figure 2-7. In this example, N is set to three, so each AAL1 block contains payload from three timeslots, plus the three sets of signalling bits present in one multiframe.

Figure 2-8:  Example DS1/ESF and E1 Signalling Substructure
Packing of the signalling bits for DS1 and E1 is done by using bits 8..5 of the first octet for the first set of signalling bits, bits 4..1 of the first octet for the second set of signalling bits, and so on. Bits 4..1 of the last octet of the Signalling Substructure will be unused and shall be set to zero if the VCC is configured to carry an odd number of timeslots. Figure 2-8 shows the assignment of bits to the signalling substructure.
Packing of the signalling bits for J2 is done by using the first bit (bit 8) of the first octet for the first channel’s signalling bit, the second bit (bit 7) of the first octet for the second channel’s signalling bit, and so on. Any unused bits of the last octet, when the number of channels is not an exact multiple of eight, shall be set to zero. Figure 2-9 shows the assignment of bits to the signalling substructure for J2.

Figure 2-9:  Example J2 Signalling Substructure

Figure 2-10:  Example DS1/SF Signalling Substructure
DS1 with Superframe Format (SF) can also be carried with a CES IWF.  For SF format, the AAL1 structure is made the same size as the equivalent ESF structure by sending two SF multiframes together in one AAL1 block, instead of one multiframe as is done in ESF framing.  For SF format, the signalling octets at the end of the AAL1 structure contain AB signalling bits from the two SF multiframes in the structure. Figure 2-10 shows the signalling substructure detail for an example circuit of N=3. In this example, signalling bits AB are from the first SF multiframe in the AAL1 structure, while bits A’B’ are from the second SF multiframe.

Table 2-1 gives the size of the AAL1 structure in octets for a few different values of N. The parameter N gives the number of 64 kbit/s timeslots derived from a single access line to be transmitted over one VCC. A value of N = 1 corresponds to a single 64 kbit/s circuit; N = 6 corresponds to 384 kbit/s; N =30 corresponds to the full E1 payload of 1.920 Mbit/s.
	Structure Size in Octets	
Framing	N = 1	N = 6	N = 24	N = 30	N = 96	
DS1/ESF	25	147	588	n/a	n/a	
DS1/SF	25	147	588	n/a	n/a	
E1	17	99	396	495	n/a	
J2	9	49	195	244	780	
Table 2-1: Sample AAL1 Structure Sizes for Nx64 Service with CAS
It should be noted, that in the case of DS1 with CAS, the ABCD bits may be present in the Payload Substructure in addition to being in the Signalling Substructure.  In both circumstances of both normal operation, and also alarm conditions such as trunk conditioning, valid signalling must be sent in the Signalling substructure.
(CR-5) If CAS mode operation is enabled for DS1, the Downstream IWF may only obtain ABCD signalling bits from the signalling substructure.
2.3.2	Bit Ordering

Figure 2-11: DS1/E1/J2 vs. ATM Bit Ordering
Bits from the DS1, E1 or J2 Nx64 Service Interface are packed into ATM cells using the ordering shown in Figure 2-11. Note that G.704 and T1.403 designate the most significant bit as ‘bit 1’, while ATM cells as defined in T1.627 number the least significant bit as ‘bit 1’. In both cases, however, the most significant bit is transmitted first.
2.3.3	Loss/Error Response 
The IWF will contain a function that reassembles a sequence of AAL1 cells into streams of octets for transmission by the DS1/E1/J2 Service Interface. This reassembly function must cope with a variety of errors and impairments, including lost cells, late cells and misinserted cells. 
2.3.3.1	Lost and Misinserted Cells
The reassembly unit may detect lost and misinserted cells by processing sequence numbers in the AAL1 headers.
(R-27) If cell loss is detected, dummy cells consisting of 46 or 47 octets shall be inserted when bit count integrity can be maintained. The content of the inserted octets is implementation-dependent.
Depending on implementation, there will be a point at which too many cells will have been lost to maintain bit count integrity; at this point, the AAL1 receiver may have to locate the next AAL1 Structure Pointer to re-acquire framing.
(O-6) Misinserted cells are expected to be rare. The reassembly unit may maintain bit count integrity where possible by dropping cells that the AAL1 header processor detects as misinserted.
2.3.3.2	Buffer Overflow/Underflow
The reassembly function will require a buffer in which the reassembled cell stream is stored before it is transmitted out the Service Interface. The size of this buffer will be implementation dependent, but it must be large enough to accommodate expected CDV, while small enough to not introduce excessive delay in the emulated circuit. This buffer will be subject to overflow or underflow if slight clocking differences exist between the node at which segmentation takes place, and the node at which reassembly takes place. Buffer underflow may also result from unexpectedly large CDV.
(R-28) The Nx64 Service IWF shall perform controlled frame slips if the reassembly buffer encounters an overflow or underflow (i.e., “starvation”) condition. The data inserted in case of underflow is implementation-dependent.

Figure 2-12:  Virtual Channel Fault Indication
Under some circumstances, such as a failure in the ATM network carrying the emulated Nx64 circuit, the flow of cells to the reassembly unit will stop for an extended period. This condition shall be signalled to the external equipment attached to the Service Interface by Trunk Conditioning, as illustrated in Figure 2-12.
(R-29) After an integration period, a persistent buffer starvation condition shall trigger Trunk Conditioning, as specified in Bellcore TR-NWT-000170.
The length of the integration period has not yet been specified by ITU-T, ANSI and/or ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second integration period, in a manner analogous to that used to integrate Loss of Signal to declare red alarm state.
Although not required as part of this specification, implementors may wish to consult Bellcore GR-1113-CORE and ETSI ETS 300 353 Annex D for advice on the handling of various fault conditions.
2.4	Clock Distribution Guidelines
As stated in Section 2.1.3, IWFs which support network-synchronous services must provide a means by which a timesource traceable to a Primary Reference Source (PRS) may be supplied. For DS1, E1 and J2 Nx64 Service, the IWF must provide timing at the DS1/E1/J2 Service Interface.
While the technique by which that clock is provided at the Service Interface is beyond the scope of this specification, here are some possible techniques:
1.	A PRS-traceable source is used to time the physical layers supporting ATM links between the IWF and the ATM network. Timing might be introduced to the ATM network via a Central Office Clock connection on one or more ATM switches. Each CES IWF receives timing from its ATM interface.
2.	The physical links accessing an ATM network might be synchronized to a PRS as above, but the timing might be introduced to the ATM network via a DS1/E1/J2 interface.
3.	Not all IWF access interfaces may convey timing which is PRS-traceable. If the CES IWF access interface does not convey PRS-traceable timing, then PRS-traceable timing must be externally supplied to the external equipment.
4.	In some private network applications involving circuit emulation, it may be sufficient to distribute a common clock to all CES IWF nodes, but not require that the common clock be traceable to a Stratum 1 oscillator. Note, however, that the use of synchronization timing below PRS could result in internetworking difficulties between different network domains, such as interconnection involving multiple public network providers. ANSI T1X1.3 is currently studying these types of issues.
In all cases, Service Interfaces are expected to be timed from a single, common clock, or one or more PRSs. Service Interface timing is not carried across the network via SRTS, or through the use of Adaptive clock recovery. All Nx64 emulated circuits are carried with AAL1 Synchronous mode, as described in T1.630.
Information on the distribution of network timing may be found in ANSI T1.101 and in ISO/IEC 11573.

3.	DS1/E1/J2 Unstructured Service
A large number of applications utilize DS1, E1 and J2 interfaces today, making use of the entire bandwidth. Within this section, the following conventions apply:
Unstructured Service = All modes of the unstructured DS1/E1 and J2 Unstructured Service.
DS1 Unstructured Service = Unstructured Service at a nominal bit rate of 1.544 Mb/s in which the two IWFs involved are emulating a DS1 circuit supplied via a DSX-1 interface.
E1 Unstructured Service = Unstructured Service  at a nominal bit rate of 2.048 Mb/s in which the two IWFs involved are emulating an E1 circuit supplied via a G.703 interface.
J2 Unstructured Service = Unstructured Service at a nominal bit rate of 6.312 Mb/s in which the two IWFs involved are emulating a J2 circuit supplied via a JT-G.703a interface.
DS1 Logical Unstructured Service = Unstructured Service at a nominal bit rate of 1.544 Mb/s in which the non-ATM-related functions of the two IWFs involved are left unspecified.
E1 Logical Unstructured Service = Unstructured Service at a nominal bit rate of 2.048 Mb/s in which the non-ATM-related functions of the two IWFs involved are left unspecified.
J2 Logical Unstructured Service = Unstructured Service at a nominal bit rate of 6.312 Mb/s in which the non-ATM-related functions of the two IWFs involved are left unspecified.
3.1	Service Description
DS1/E1/J2 Unstructured CBR service is intended to emulate a point-to-point DS1, E1 or J2 circuit. The service is accessed via either a 1.544 Mbit/s DSX-1 interface, a 2.048 Mbit/s G.703 interface or a 6.312 Mbit/s JT-G.703a interface. The service is defined as a “clear channel pipe”, transparently carrying any arbitrary 1.544 Mbit/ s (2.048 Mbit/s for E1 and 6.312 Mbit/s for J2) data stream. The end-user timing source for these interface signals is not necessarily traceable to a PRS.
Note that framing formats other than standard SF, ESF, G.704 or JT-G.704 formats cannot be supported by all PDH/SDH installed equipment. If CES service for such non-standard framing formats is offered by an exchange carrier, the carrier may have difficulty in maintaining the service interface due to the lack of facility support for operations and maintenance functions such as performance monitoring, facility loopbacks and so forth.
The DS1/E1/J2 Unstructured Service also provides an optional feature that allows non-intrusive performance monitoring of the link if SF, ESF, G.704 or JT-G.704 framing is used.
Figure 3-1 shows the DS1/E1/J2 Unstructured Service from a layering perspective. For this service, the CES interworking function has two physical layers, one for the CBR circuit to be emulated and one for ATM. Linking the CBR physical layer with the AAL1 layer is a “mapping function”. In Unstructured service, the mapping function simply maps every bit between the AAL1 layer and the 1.544, 2.048 or 6.312 Mbit/s Service Interface. From an ATM perspective, everything shaded in the diagram represents an “AAL User Entity,” and that is how we refer to the shaded portions in the CES-IS. For the “logical” versions of the Circuit Emulation Services, the CES-IS leaves the non-ATM portions identified in the figure (i.e., the CBR Physical layer and CBR Service Interface) unspecified.

Figure 3-1:  DS1/E1/J2 Unstructured Service Interworking Function - Layering Perspective
3.1.1	Framing
(R-30) The DS1/E1/J2 Unstructured Service carries any arbitrary 1.544 Mbit/s (2.048 Mbit/s for E1 and 6.312 Mbit/s for J2) data stream.
(O-7) Optionally, the Unstructured service may include a non-intrusive performance monitoring function that will decode but not terminate SF, ESF, G.704 or JT-G.704 framing. The functions required to support this option are: collection of performance statistics, and detection of frame-based alarms and messages. There must be a configuration option to disable the performance monitor for use with unframed signals.
3.1.2	Clocking
The DS1/E1/J2 Unstructured Service has two modes for timing user equipment attached to the Service Interface:
1.	Synchronous Mode, in which timing is supplied to attached DS1/E1/J2 equipment via the IWF Service Interface, and may be traceable to a Primary Reference Source.
2.	Asynchronous Mode, in which timing is supplied by an independent clock in the attached equipment and carried transparently through the ATM network.
When asynchronous timing is supplied by the attached equipment, the end-user timing source for this asynchronous timing may or may not be traceable to a PRS. Whether or not an interface signal is traceable to a PRS impacts the choice of clock recovery method. If asynchronous CES service is being provided to a CBR interface which does not use timing traceable to a PRS, then SRTS may not be supportable. In order to support SRTS application when the CES IWF does not use timing traceable to a PRS, the CES IWF must have available for its use a reference clock which is common to the reference clock being used by the CES IWF at the other end of the connection.
(R-31) A CES IWF must implement at least one of the two clocking modes for DS1/E1/J2 Unstructured Service, and may offer both modes. Two Interworking Functions must be configured for the same clocking mode in order to interoperate.
(CR-6) If Asynchronous Mode is used, timing shall be properly accepted from user equipment as long as that timing is within +/-130 ppm for DS1 (as specified in T1.403-1995), +/- 50 ppm for E1 (as specified in G.703) and +/- 30 ppm for J2 (as specified in JT-G.703a). Note that the 130 ppm tolerance for DS1 is intended to support older DS1 equipment. Newer equipment will be within +/- 32 ppm.
3.1.3	Jitter and Wander
Jitter and Wander may be present at the output of the emulated circuit, introduced, for example, by imperfections in clock recovery at the output of the CES IWF. For circuits using the Asynchronous timing mode, there are two techniques for recovering clock -- SRTS and Adaptive (see Section 3.4). While the two techniques can produce equal jitter performance, they may differ in the amount of wander present at the output of the IWF.
Wander requirements apply to network-synchronous signals (i.e., those traceable to a PRS) but the same requirements may be applied to an asynchronous signal if the wander is defined as relative to the clock source rather than to an absolute reference. ANSI technical sub-committee T1E1, the group responsible for T1.403 and T1.404, is studying this area with input from T1X1.3.
(R-32) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface shall meet ANSI T1.102 and G.824 for DS1 circuits with any clocking mode.
(R-33) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface shall meet G.823 for E1 circuits with any clocking mode.
(R-34) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface must meet JT-G.703a for J2 interfaces with any clocking mode.
(CR-7) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is used, wander must meet ANSI T1.403 and G.824 for DS1 circuits.
(CR-8) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is used, wander must meet G.823 for E1 circuits.
(CR-9) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is used, wander must meet JT-G.703a for J2 circuits.
ANSI T1.403-1995 5.7.5 specifies that wander shall not exceed 28 UI (18 msec) peak-to-peak in any 24-hour period. Recommendations G.823 and G.824 suggest that network wander be maintained at less than 10 msec over any 10,000 second interval (approximately 3 hours).
If the Asynchronous clocking mode is used with Adaptive clock recovery, the resulting wander will depend on the CDV characteristics of the ATM network used to interconnect Interworking Functions, and might not meet recommendations specified in T1.403, G.823 or G.824.
Note: for circuit emulation service, ITU-T Recommendation I.363.1 and ANSI T1.630 specify the SRTS method of timing recovery to guarantee/meet performance requirements (jitter and wander) of G.823 and G.824. If either IWF connects to DS1, E1 or J2 equipment in the public network, the Public Network Operator may require that SRTS be used.
3.1.4	Facility Data Link
The Unstructured Circuit Emulation Service will carry any signal that meets the bit rate requirement specified in Section 3.1.2, without regard to framing.  In the particular case of DS1 circuits using ESF framing, a Facility Data Link (FDL) may be present in the signal.  If this is the case, the CES IWF is allowed to monitor the FDL, but must not change messages carried by the FDL, or insert new FDL messages.
(R-35) The Facility Data Link associated with the Service Interface, if present, shall not be modified by  the Unstructured Service Interface.
(CR-10) If the optional performance monitoring feature is enabled, the Interworking Function shall monitor Performance Report Messages as described in T1.403. The collected statistics shall be stored in the MIB, as described in Section 8.
3.1.5	Alarms
(R-36) For DS1, E1 or J2 Unstructured Service, all alarms received at the input of the Service Interface are carried through to the output Service Interface without modification.
(R-37) The IWF shall detect Loss of Signal at the IWF Service Interface. Upon detection of LOS, the segmenting IWF shall send cells containing all-ones, effectively propagating an unframed AIS signal. This situation is illustrated in Figure 3-2.

Figure 3-2:  Unstructured DS1/E1/J2 Service Interface Fault Indication
(CR-11) If the optional performance monitoring feature is provided for the DS1, E1 or J2 Unstructured Service, the CES Interworking Function shall monitor the alarm status of the Service Interface. Alarm status shall be reflected in the MIB.
3.1.6	Service Performance Characteristics
This section describes the minimal service performance characteristics required by the Unstructured Service.
3.1.6.1	End-to-End Delay
End-to-end delay requirements are application-specific. End-to-end delay requirements are beyond the scope of this specification.
3.1.6.2	Error Ratios
BER is the ratio of the number of bit errors to the total number of bits transmitted in a given time interval. There are no specific bit-error ratio requirements for DS1/E1/J2 CBR service other than those implied by the errored second and severely-errored second requirements that follow. (Source: ANSI T1.510-1994, Network Performance Parameters for Dedicated Digital Services — Specifications.)
Service performance is also measured in terms of Errored Seconds (ES) and Severely Errored Seconds (SES).  Performance objectives for Errored Seconds and Severely Errored Seconds are given in ANSI T1.510-1994.
3.1.7	Electrical
(R-38) For the DS1 Unstructured Service, the Service Interface will provide a DSX-1 electrical interface with B8ZS coding.
(O-8) For the DS1 Unstructured Service, AMI coding may be provided as an option.
The Service Interface may use a connector such as the RJ48C or RJ48M, as specified in T1.403.
(R-39) For the E1 Unstructured Service, the Service Interface will provide a G.703 interface using HDB3 line coding. G.703 allows both 75 Ohm and 120 Ohm interfaces for E1.
The E1 Service Interface may use a connector such as ISO8877 for the 120 Ohm interface, and a 75 Ohm BNC connector, as described in IECSC46D, for the 75 Ohm interface.
(R-40) For the J2 Unstructured Service, the Service Interface will provide a JT-G.703a interface using B8ZS coding.
The J2 Service Interface shall use a 50 Ohm JIS C5412-1976 compliant connector as specified in JT-G.703a.
3.2	AAL 1 Requirements
3.2.1	Data Transfer Service Type
(R-41) The Unstructured service shall use the Unstructured Data Transfer (UDT) mode as defined in T1.630 and I.363.1.
3.2.2	Cell Utilization
(R-42) In accordance with ANSI T1.630, the IWF shall fill the entire 47-octet cell payload with DS1/E1/J2 data.
3.3	AAL User Entity Requirements 
3.3.1	Cell Coding 
Unstructured Data Transfer does not rely on any particular data format. Bits received from the service interface are packed into cells without regard to framing. Note that no particular alignment between octets in DS1, E1 and J2 frames and octets in an ATM cell can be assumed with Unstructured Data Transfer.
However, correct bit ordering must be used.  Considering the 376 contiguous bits that will be packed into the SDU, the first bit received on the DS1/E1/J2 line is placed in the MSB of the first octet of the SDU, and placement proceeds in order until the last bit is placed in the LSB of the 47th octet of the SDU.
3.3.2	Loss/Error Response 
The IWF should attempt to maintain “bit count integrity”; i.e., the number of DS1/E1/J2 bits coming into the segmenting IWF providing the Unstructured service should equal the number of DS1/E1 bits leaving the reassembling IWF whenever possible. Failure to maintain bit count integrity will probably cause end-user equipment to suffer a reframe event.
3.3.2.1	Lost and Misinserted Cells
The reassembly unit may detect lost and misinserted cells by processing sequence numbers in the AAL1 headers. 
(R-43) If lost cells are detected, dummy cells consisting of 47 octets of all ones shall be inserted when bit count integrity can be maintained. In order to also maintain bit sequence integrity, these data bits from the dummy payloads must be positioned in place of the bits lost in the missing cell payloads. Depending on implementation, there will be a point at which too many cells will have been lost to maintain bit count integrity.
(O-9) The reassembly unit may maintain bit count integrity where possible by dropping cells that the AAL1 header processor detects as misinserted.
3.3.2.2	Buffer Overflow/Underflow
The reassembly function will require a buffer in which the reassembled cell stream is stored before it is transmitted out the Service Interface. The size of this buffer will be implementation dependent, but it must be large enough to accommodate expected CDV, while small enough to not introduce excessive delay in the emulated circuit. This buffer will be subject to overflow or underflow if slight clocking differences exist between the node at which segmentation takes place, and the node at which reassembly takes place. Buffer underflow may also result from unexpectedly large CDV.
(R-44) The IWF shall insert an all-ones pattern if the reassembly buffer encounters an underflow (i.e., “starvation”) condition. This condition may result in a reframe event for DS1/E1 or J2 equipment using the Unstructured service.
Under some circumstances, such as a failure in the ATM network carrying the emulated circuit, the flow of cells to the reassembly unit will stop for an extended period. The Loss-of-Cells condition should be signalled to the downstream external equipment attached to the Service Interface by sending the all-ones AIS pattern, as illustrated in Figure 3-3.

Figure 3-3:  Virtual Channel Fault Indication
(R-45) After an integration period, a persistent buffer starvation condition shall trigger a Loss-of-Cells fault indication, resulting in downstream AIS.
The length of the integration period has not yet been specified by ITU-T, ANSI and/or ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second integration period, in a manner analogous to that used to integrate Loss of Signal to declare red alarm state.
The reassembly buffer can also suffer an overflow condition due to a clocking error. In this case, the IWF shall drop a number of bits from the reassembled stream. The number of bits dropped at each buffer overflow event is implementation dependent. A buffer overflow is likely to result in a reframe event for DS1/E1 or J2 equipment using the Unstructured service.
(R-46) The IWF shall drop an implementation-dependent number of bits in case of a buffer overflow.
Although not required as part of this specification, implementors may wish to consult Bellcore GR-1113-CORE and ETSI ETS 300 353 Annex D for advice on the handling of various fault conditions.
3.4	Clock Recovery
The Unstructured service may carry network-synchronous (i.e., traceable to a PRS) or asynchronous DS1, E1 or J2 circuits. In an asynchronous situation, the input Service clock frequency must be recovered at the output IWF. There are two techniques for recovering this clock, Synchronous Residual Time Stamp (SRTS) and Adaptive. Either technique may be used, although SRTS may give better control over wander introduced into the emulated circuit, depending on the wander generation mechanisms.
For circuit emulation of both network-synchronous and asynchronous signals, the SRTS clock recovery technique requires a network reference clock (i.e., traceable to a PRS); - information on the distribution of network timing may be found in ANSI document T1.101 and in ISO/IEC 11573.
3.4.1	SRTS
The SRTS technique measures the Service Clock input frequency against a network-wide synchronization signal that must be present in the IWF, and sends difference signals, called Residual Time Stamps, in the AAL1 header to the reassembly IWF. At the output IWF, the differences can be combined with the network-wide synchronization signal, to re-create the input Service clock. Note that this network-wide synchronization signal must be traceable to a PRS.
(CR-12) If SRTS is provided, it shall be used as specified in T1.630 and I.363.1.
(CR-13) The network derived clock frequency (fox) used in the SRTS algorithm shall be 2.43 MHz for both DS1 and E1 circuit emulation.
(CR-14) The network derived clock frequency (fox) used in the SRTS algorithm shall be 9.72 MHz for J2 circuit emulation.
3.4.2	Adaptive
The adaptive technique does not require a network-wide synchronization signal to regenerate the input Service clock at the output IWF.
A variety of techniques could be used to implement Adaptive clock recovery. For example, the depth of the reassembly buffer in the output IWF could be monitored:
1.	When the buffer depth is too great or tends to increase with time, the frequency of the Service clock could be increased to cause the buffer to drain more quickly.
2.	When the buffer contains fewer than the configured number of bits, the Service clock could be slowed to cause the buffer to drain less quickly.
Wander may be introduced by the Adaptive clock recovery technique if there is a low-frequency component to the Cell Delay Variation inserted by the ATM network carrying cells from the input to output IWF.

4.	Unstructured DS3/E3 Service
Applications may utilize DS3/E3 interfaces today, either utilizing the entire bandwidth, or through the use of multiplexing performed in end systems. Within this section, the following conventions apply:
Unstructured DS3/E3 Service = All modes of the Unstructured DS3/E3 Service.
Unstructured DS3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 44.736 Mbit/s in which the two IWFs involved are emulating a DS3 circuit supplied via a DSX-3 interface.
Unstructured E3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 34.368 Mbit/s in which the two IWFs involved are emulating an E3 circuit supplied via a G.703 interface.
Logical Unstructured DS3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 44.736 Mbit/s in which the non-ATM-related functions of the two IWFs involved are left unspecified.
Logical Unstructured E3 Service = Unstructured DS3/E3 Service at a nominal bit rate of 34.368 Mbit/s in which the non-ATM-related functions of the two IWFs involved are left unspecified.
4.1	Service Description
Unstructured DS3/E3 Service is intended to emulate a point-to-point DS3 or E3 circuit. The service is accessed via either a 44.736 Mbit/s DSX-3 interface or a 34.368 Mbit/s G.703 interface. The service is defined as a “clear channel pipe”, transparently carrying any arbitrary 44.736/34.368 Mbit/s data stream. The end-user timing source for these interface signals is not necessarily traceable to a PRS.
Note that framing formats other than standard DS3 or E3 formats cannot be supported by all PDH/SDH installed equipment. If CES service for such non-standard framing formats is offered by an exchange carrier, the carrier may have difficulty in maintaining the service interface due to the lack of facility support for operations and maintenance functions such as performance monitoring, facility loopbacks and so forth.

Figure 4-1: Unstructured DS3/E3 Service Interworking Function --
Layering Perspective
Figure 4-1 shows the Unstructured DS3/E3 Service from a layering perspective. For this service, the CES interworking function has two physical layers, one for the CBR circuit to be emulated and one for ATM. Linking the CBR physical layer with the AAL1 layer is a “mapping function”. In Unstructured DS3/E3 Service, the mapping function simply maps every bit between the AAL1 layer and the 44.736 or 34.368 Mbit/s Service Interface. From an ATM perspective, everything shaded in the diagram represents an “AAL User Entity,” and that is how we refer to the shaded portions in the CES-IS. For the “logical” versions of the Circuit Emulation Service, the CES-IS leaves the non-ATM portions identified in the figure (i.e., the CBR Physical layer and CBR Service Interface) unspecified.
4.1.1	Framing
(R-47) The Unstructured DS3/E3 Service shall carry any arbitrary 44.736/34.368 Mbit/s data stream.
4.1.2	Clocking
The Unstructured DS3/E3 Service has two modes for timing user equipment attached to the Service Interface:
1)	Synchronous Mode, in which timing is supplied to attached DS3/E3 equipment via the IWF Service Interface, and may be traceable to a Primary Reference Source.
2)	Asynchronous Mode, in which timing is supplied by attached equipment and carried through the ATM network.
When asynchronous timing is supplied by the attached equipment, the end-user timing source for this asynchronous timing may or may not be traceable to a PRS. Whether or not an interface signal is traceable to a PRS impacts the choice of clock recovery method. If asynchronous CES service is being provided to a CBR interface which is not traceable to a PRS, then SRTS may not be supportable. In order to support SRTS application when the CES IWF does not use timing traceable to a PRS, the CES IWF must have available for its use a reference clock which is common to the reference clock being used by the CES IWF at the other end of the connection.
(R-48) A CES IWF must implement at least one of the two clocking modes for Unstructured DS3/E3 Service, and may offer both modes. Two Interworking Functions must be configured for the same clocking mode in order to interoperate.
(CR-15) If Asynchronous Mode is used, timing shall be properly accepted from  user equipment as long as that timing is within +/- 20 ppm (as specified in T1.102 for DS3 and in G.703 for E3).
4.1.3	Jitter and Wander
Jitter and Wander may be present at the output of the emulated circuit, introduced, for example, by imperfections in clock recovery at the output of the CES IWF. For circuits using the Asynchronous timing mode, there are two techniques for recovering clock -- SRTS and Adaptive (see Section 4.4). While the two techniques can produce equal jitter performance, they may differ in the amount of wander present at the output of the IWF.
Wander requirements apply to network-synchronous signals (i.e., traceable to a PRS) but the same requirements may be applied to an asynchronous signal if the wander is defined as relative to the source clock rather than to an absolute reference. ANSI technical sub-committee T1E1, the group responsible for T1.403 and T1.404, is studying this area with input from T1X1.3.
(R-49) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface shall meet ANSI T1.102 and ITU-T G.824 for DS3 circuits with any clocking mode.
(R-50) Jitter measured at the output of the IWF Service Interface and tolerated at the input of the IWF Service Interface shall meet ITU-T G.823 for E3 circuits with any clocking mode.
(CR-16) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is used, wander must meet T1.404 and G.824 for DS3 circuits.
(CR-17) If Synchronous clocking or Asynchronous clocking with SRTS clock recovery is used, wander must meet G.823 for E3 circuits.
If the Asynchronous clocking mode is used with Adaptive clock recovery, the resulting wander will depend upon the CDV characteristics of the ATM network used to interconnect Interworking Functions, and might not meet recommendations specified in G.823 or G.824.
Note: For Circuit Emulation Service, ITU-T Recommendation I.363.1 and ANSI T1.630 specify the SRTS method of timing recovery to guarantee/meet performance requirements (jitter and wander) of G.823 and G.824. If either IWF connects to DS3 or E3 equipment in the public network, the Public Network Operator may require that SRTS be used.
4.1.4	Alarms
(R-51) For Unstructured DS3/E3 Service, all alarms received at the input of the Service Interface are carried through to the output Service Interface without modification.

Figure 4-2: Unstructured DS3/E3 Service Interface Fault Indication
(R-52) The IWF shall detect Loss of Signal (LOS) at the IWF Service Interface. Upon detection of LOS, the segmenting IWF shall send cells containing an AIS pattern (all-ones for E3, framed 1010.. for DS3 as specified in ANSI T1.107) downstream. This situation is illustrated in Figure 4-2.
4.1.5	Service Performance Characteristics
This section describes the minimal service performance characteristics required by the Unstructured DS3/E3 Service.
4.1.5.1	End-to-End Delay
End-to-end delay requirements are application specific. End-to-end delay requirements are beyond the scope of this specification.
4.1.5.2	Error Ratios
Bit Error Ratio (BER) is the ratio of the number of bit errors to the total number of bits transmitted in a given time interval. There are no specific bit-error ratio requirements for Structured DS3/E3 Service other than those implied by the errored second and severely-errored second requirements identified in the following paragraph. (Source: ANSI T1.510-1994, Network Performance Parameters for Dedicated Digital Services -- Specifications.)
Service performance is also measured in terms of Errored Seconds (ES) and Severely Errored Seconds (SES). Performance objectives for Errored Seconds and Severely Errored Seconds are given in ANSI T1.510-1994 for DS3, and in G.826 for E3.
4.1.6	Electrical
(R-53) The Unstructured DS3 Service shall provide a 44.736 Mbit/s DSX-3 interface with B3ZS line coding, as specified in T1.102.
(R-54) The Unstructured E3 Service shall provide a 34.368 Mbit/s G.703 interface with HDB3 line coding.
4.2	AAL1 Requirements
4.2.1	Data Transfer Service Type
(R-55) The Unstructured DS3/E3 Service shall use the Unstructured Data Transfer (UDT) mode as defined in I.363.1 and T1.630.
4.2.2	Cell Utilization
(R-56) In accordance with ANSI T1.630, the IWF shall fill the entire 47 octet cell payload with DS3/E3 data.
4.3	AAL User Entity Requirements
4.3.1	Cell Coding
Unstructured Data Transfer does not rely on any particular data format. Bits received from the Service Interface are packed into cells without regard to framing. Note that no particular alignment between any octets in DS3 or E3 frames and octets in an ATM cell can be assumed with Unstructured Data Transfer.
However, correct bit ordering must be used. Considering the 376 contiguous bits that will be packed into the AAL1 SDU (Service Data Unit), the first bit received on the DS3/E3 line is placed in the MSB of the first octet of the SDU. Placement then proceeds in order until the last bit is placed in the LSB of the 47th octet of the SDU.
4.3.2	Loss/Error Response
The IWF should attempt to maintain “bit count integrity”; i.e., the number of DS3/E3 bits coming into the segmenting IWF providing the Unstructured DS3/E3 Service should equal the number of DS3/E3 bits leaving the reassembling IWF whenever possible. Failure to maintain bit count integrity will probably cause end-user equipment to suffer a reframe event.
4.3.2.1	Lost and Misinserted Cells
The reassembly unit may detect lost and misinserted cells by processing sequence numbers in the AAL1 headers.
(R-57) If cell loss is detected in Unstructured E3 Service, dummy cells consisting of 47 octets of all ones shall be inserted in order to maintain  bit count integrity. In order to also maintain bit sequence integrity, these data bits from the dummy payloads must be positioned in place of the bits lost in the missing cell payloads. Depending upon implementation, there will be a point at which too many cells will have been lost to be able to assure the maintenance of bit count integrity.
(R-58) If cell loss is detected in Unstructured DS3 Service, dummy cells consisting of a framed DS3 AIS shall be inserted as specified by ANSI T1.630. This framed DS3 AIS consists of a framed 1010.. bit sequence, as described in ANSI T1.404. In order to also maintain bit sequence integrity, these data bits from the dummy payloads must be positioned in place of the bits lost in the missing cell payloads. When multiple contiguous dummy cells must be inserted, the content of these cells shall form a continuous framed DS3 AIS, such that a continuous sequence of these cells would cause a continuous framed DS3 AIS to be reconstructed by the reassembly unit. The framed DS3 AIS content of these dummy cells need not be aligned with the original DS3 signal, however. Depending upon implementation, there will be a point at which too many cells will have been lost to be able to assure the maintenance of bit count integrity. However, as long as contiguous dummy cells must be inserted in order to maintain a reconstructed bit stream, the content of these inserted cells shall form the continuous framed DS3 AIS as specified by ANSI T1.630.
(O-10) Misinserted cells are expected to be rare. The reassembly unit may maintain bit count integrity where possible by dropping cells that the AAL1 header processor detects as misinserted.
4.3.2.2	Buffer Overflow/Underflow
The reassembly function will require a buffer in which the reassembled cell stream is stored before it is transmitted out the Service Interface. The size of this buffer will be implementation dependent, but it must be large enough to accommodate expected CDV, while small enough to not introduce excessive delay in the emulated circuit. This buffer will be subject to overflow or underflow if slight clocking differences exist between the node at which segmentation takes place and the node at which reassembly takes place. Buffer underflow/overflow may also result from unexpectedly large CDV.
(R-59) An Unstructured E3 Service IWF shall insert an all-ones pattern if the reassembly buffer encounters an underflow (i.e., “starvation”) condition. This condition may result in a reframe event for E3 equipment using this service.
(R-60) An Unstructured DS3 Service IWF shall insert a framed DS3 AIS pattern if the reassembly buffer encounters an underflow (i.e., “starvation”) condition. The inserted data shall form a continuous framed DS3 AIS pattern as long as contiguous data must be inserted. This pattern need not be aligned with the original DS3 signal, however. This reassembly buffer underflow condition may result in a reframe event for DS3 equipment using this service.

Figure 4-3: Unstructured DS3/E3 Virtual Channel Fault Indication
Under some circumstances, such as a failure in the ATM network carrying the emulated circuit, the flow of cells to the reassembly unit will stop for an extended period. This condition shall be signalled to the external equipment attached to the Service Interface by sending an AIS pattern (all ones for E3, framed 1010.. for DS3 as specified in ANSI T1.107) downstream, as illustrated in Figure 4-3 .
(R-61) After an integration period, a persistent buffer starvation condition for an Unstructured E3 Service shall trigger generation of an AIS pattern (all ones) downstream.
(R-62) After an integration period, a persistent buffer starvation condition for an Unstructured DS3 Service shall trigger the generation of a continuous framed DS3 AIS (framed 1010..) downstream. The framing of this DS3 AIS shall be a continuous extension of the framing of the DS3 AIS being inserted while the starvation condition was being integrated.
The length of the integration period has not yet been specified by ITU-T, ANSI and/or ETSI. Pending specification, implementors are advised to use a 2.5 +/- 0.5 second cell loss integration period.
The reassembly buffer can also suffer an overflow condition due to a clocking error. In this case, the IWF shall drop a number of bits from the reassembled stream. The number of bits dropped at each buffer overflow event is implementation dependent. A buffer overflow is likely to result in a reframe event for DS3/E3 equipment using the Unstructured DS3/E3 Service.
(R-63) The Unstructured DS3/E3 Service IWF shall drop an implementation dependent number of bits in case of a buffer overflow.
Although not required as part of this specification, implementors may wish to consult Bellcore GR-1113-CORE and ETSI ETS 300 353 Annex D for advice on the handling of various fault conditions.
4.4	Clock Recovery
The Unstructured DS3/E3 Service may carry asynchronous DS3 or E3 circuits. In this situation, the input Service Interface clock frequency must be recovered at the output IWF. There are two techniques for recovering this clock; Synchronous Residual Time Stamp (SRTS) and Adaptive. Either technique may be used, although SRTS gives better control over wander introduced into the emulated circuit.
4.4.1	SRTS
The SRTS technique measures the Service Interface input clock frequency against a network-wide synchronization signal that must be present in the IWF, and sends difference signals, called Residual Time Stamps, in the AAL1 header to the reassembly IWF. At the output IWF, the differences can be combined with the network-wide synchronization signal to re-create the input Service Interface clock.
(R-64) If SRTS is provided, it shall be used as specified in I.363.1 and T1.630.
(CR-18) The network derived clock frequency (fox) used in the SRTS algorithm shall be 77.76 MHz for DS3 and 38.88 MHz for E3 circuit emulation.
4.4.2	Adaptive
The adaptive technique does not require a network-wide synchronization signal to regenerate the input Service Interface clock at the output IWF.
For a description of a possible technique to implement Adaptive clock recovery, see Section 3.4.2.
Wander may be introduced by the Adaptive clock recovery technique if there is a low-frequency component to the Cell Delay Variation inserted by the ATM network carrying cells from the input to output IWF.

5.	ATM Virtual Channel Requirements
The subsections that follow specify traffic parameters and tolerances as defined in A.6 of the UNI 3.1 Specification.
The requirements described in this section must be met by the ATM network that provides an end-to-end ATM connection, i.e., from the input ATM Interface to the output ATM Interface in Figure 5-1.

Figure 5-1:  Reference Network Configuration

(R-65) Quality of Service Class 1 for circuit emulation from the ATM Forum UNI Specification Version 3.1 Appendix A shall be used.
5.1	Traffic Parameters and Tolerances
Traffic policing may be performed on cells generated by the CES Interworking Function and transported by the ATM network.
The CDV Tolerance parameter of the UPC should take into account any cell delay variation caused by the introduction of OAM cells. The CDV Tolerance should also account for any CDV that occurs in the intervening multiplexing and switching devices between the Interworking Function and the UPC device.
In the context of this specification, CDV Tolerance is considered a network option, and is currently not subject to standardization.
The following sections give the Peak Cell Rate (PCR) for various versions of the CES Interworking Function.
In all cases, if the OAM traffic is to be included in the PCR per UNI 3.1 section 3.6.3.2.3.7, then the OAM traffic parameter cells needs to be added to the above or specified separately.
5.1.1	Unstructured DS1 Cell Rate
(R-66) The PCR on CLP=0+1 required for AAL1 transport of 1544 kbit/s user data is 4107 cells per second.
The calculation of the PCR is based on the following formula:
4107 cells/second > (1.544 x 106 bits/s +130 ppm) / (47 AAL1 octets/cell x 8 bits/octet)
5.1.2	Unstructured E1 Cell Rate
(R-67) The PCR on CLP=0+1 required for AAL1 transport of 2048 kbit/s user data is 5447 cells per second.
The calculation of the PCR is based on the following formula:
5447 cells/second > (2.048 x 106 bits/s + 50 ppm) / (47 AAL1 octets/cell x 8 bits/octet)
5.1.3	Structured Nx64 Service Cell Rate
5.1.3.1	Basic Service
(R-68) If partial cell fill is not used and N is greater than one, the PCR on CLP=0+1 required for AAL1 transport of Nx64 Basic Service is (8000 x N)/46.875 cells per second (where x means “smallest integer greater than or equal to x”). If partial cell fill is used, the PCR is (8000 x N)/K, where K is the number of AAL-user octets filled per cell.
(R-69) If partial cell fill is not used for 64 kbps Basic Service (i.e., when N is equal to one), the PCR on CLP=0+1 required for AAL1 transport is 8000/47 cells per second (where x means “smallest integer greater than or equal to x”). If partial cell fill is used, the PCR is 8000/K, where K is the number of AAL-user octets filled per cell.
Both of these are derived by dividing the required user octet-rate by the number of user octets carried per cell.
5.1.3.2	DS1/E1/J2 Service w/CAS
(R-70) The PCR on CLP=0+1 required for AAL1 transport of E1 Nx64 Service w/CAS is:
1.	No partial cell fill, N even:

8000 x [ Nx33/32 ] / 46.875

2.	No partial cell fill, N odd: 

8000 x [ (1 + Nx33) / 32 ] / 46.875
	
3.	Partial cell fill, N even, K the number of AAL1-user octets filled:

8000 x [ Nx33/32 ] / K

4.	Partial cell fill, N odd, K the number of AAL1-user octets filled:

8000 x [ ( 1 + Nx33 ) / 32 ] / K

(R-71) The PCR on CLP=0+1 required for AAL1 transport of DS1 Nx64 Service w/CAS is:
1.	No partial cell fill, N even:

8000 x [ Nx49/48 ] / 46.875

2.	No partial cell fill, N odd:

8000 x [ (1 + Nx49) / 48 ] / 46.875

3.	Partial cell fill, N even, K the number of AAL1-user octets filled:

8000 x [ Nx49/48 ] / K

4.	Partial cell fill, N odd, K the number of AAL1-user octets filled:

8000 x [ (1 + Nx49) / 48 ] / K

(R-72) The PCR on CLP=0+1 required for AAL1 transport of J2 Nx64 Service w/CAS is:
1.	No partial cell fill, N an exact multiple of 8:

8000 x [ Nx65/64 ] / 46.875

2.	No partial cell fill, N not an exact multiple of 8:

8000 x [ ((8 - (N Modulo 8)) + Nx65) / 64 ] / 46.875

3.	Partial cell fill, N an exact multiple of 8, K the number of AAL1-user octets filled:

8000 x [ Nx65/64 ] / K

4.	Partial cell fill, N not an exact multiple of 8, K the number of AAL1-user octets filled:

8000 x [ ((8 - (N Modulo 8)) + Nx65) / 64 ] / K

These rates are derived by dividing the effective user octet-rate (including block overhead) by the number of user octets carried per cell.
Because all of the signalling bits are grouped together at the end of the AAL1 structure, virtual channels supporting DS1, E1 and J2 Nx64 Service with CAS will suffer some jitter in cell emission time. For example, an IWF carrying an Nx64 E1 circuit with N=30 and CAS enabled will, on average, emit about 10.5 cells spaced by 191.8 msec, followed by a cell carrying CAS bits after a gap of only 130 msec. This jitter in cell emission time must be accommodated by peak-rate traffic policers.
5.1.4	Unstructured DS3 Cell Rate
(R-73) The PCR on CLP=0+1 required for AAL1 transport of 44.736 Mbit/s + 20 ppm user data is 118,982 cells per second.
The calculation of the PCR is based on the following formula:
118,982 cells/second > (44.736 x 106 bit/s + 20 ppm) / (47 AAL1 octets/cell x 8 bits/octet)
5.1.5	Unstructured E3 Cell Rate
(R-74) The PCR on CLP=0+1 required for AAL1 transport of 34.368 Mbit/s + 20 ppm user data is 91,407 cells per second.
The calculation of the PCR is based on the following formula:
91,407 cells/second > (34.368 x 106 bits/s + 20 ppm) / (47 AAL1 octets/cell x 8 bits/octet)
5.1.6	Unstructured J2 Cell Rate
(R-75) The PCR on CLP=0+1 required for AAL1 transport of 6312 kbit/s +/- 30 ppm user data is 16,788 cells per second.
The calculation of the PCR is based on the following formula:
16,788 cells/second > (6.312 x 106 bits/s +30 ppm) / (47 AAL1 octets/cell x 8 bits/octet)
5.2	ATM Virtual Channel Payload Type and CLP
Sections 3.3 and 3.4 of the UNI 3.1 document specify that, in addition to Virtual Circuit and Virtual Path fields, the ATM cell header contains the Cell Loss Priority bit and the three-bit Payload Type Identifier field.
5.2.1	Cell Loss Priority (CLP)
(R-76) At the sender, this bit shall be set to “0”.  At the receiver, this bit shall be ignored.
5.2.2	Payload Type Identifier
(R-77) All cells carrying emulated circuit data shall be sent with the Payload Type Identifier field set to 000, indicating “User Data cell, congestion not experienced, SDU-type=0”.
(R-78) All four User Data cell Payload Type Identifier values (000, 001, 010 and 011) shall be accepted by the receiver.
5.3	Impairments
Sections 2.1 and 3.1 specify performance characteristics of the CBR Service Interface. The ATM performance impairments should be commensurate with these. An initial mapping of service performance requirements to ATM performance requirements is provided in Annex A.
5.3.1	Cell Transfer Delay
Overall delay is often critical for Circuit Emulation applications, particularly those involving voice. Delay introduced by the ATM network interconnecting CES IWFs is composed of two components:
Maximum Delay gives the largest expected cell delay between entrance and exit of the ATM network. 
Cell Delay Variation (CDV) gives the uncertainty in the delay that might be experienced by any particular cell.
Circuit Emulation equipment must have reassembly buffers large enough to accommodate the largest CDV present on a virtual channel to prevent underflow or overflow, with resulting reframe or slip events. At the same time, it should be noted that reassembly buffers larger than required to accommodate CDV will result in excessive overall delay.
The number of intervening switches, and their queue management, and line speeds have a significant impact on the distribution of CDV that must be handled by the reassembly buffer in the destination IWF. There are currently no standards that define a bound on CDV; however some information on CDV and reassembly buffer sizes can be found in GR-1110-CORE and TA-TSV-001409. The BICI 1.1 specification, Section 5.1.2 gives an approximation of how CDV accumulates across multiple nodes. Implementors are advised to design the reassembly buffer in excess of these values, possibly making the size of the reassembly buffer configurable to optimize the jitter versus absolute delay trade-off in various configurations.
The amount of CDV that the reassembly process can accommodate is configured with the MIB entry atmfCESCdvRxT.  This entry allows the network provider to configure the maximum cell arrival jitter that the reassembly process will tolerate in the cell stream without producing errors on the CBR Service Interface.  This parameter may be set to a small value if the connection will produce minimal CDV and a large value if the connection will produce large CDV.
An informative example of the implementation of a receiver which uses the atmfCESCdvRxT parameter is as follows:  The receiver will place the contents of the first cell to arrive after an underrun into the receive buffer in a position such that it will be played out at least one CDVT (atmfCESCdvRxT) later.

6.	Signalling
This section specifies ATM UNI 3.1 signalling between the IWFs that support CES. There is no mapping specified between signalling that pertains to traditional DS1, E1, J2 ,and Nx64 Services and ATM UNI 3.1 signalling.
The call/connection control procedures of UNI 3.1 apply. The following section details the content of the setup message. CES signalling places no explicit constraints on other signalling messages.
Note that UNI 3.1 SVC support is optional for the CES IWF. The following sections are applicable only when such SVC support is provided.
6.1	Addresses and Identifiers for CES Switched Virtual Channels (SVCs)
All CES SVCs are point-to-point. As with all SVCs, the endpoints must be identified during call setup with an ATM address; these may be of any of the three formats identified in section 5.1.3 of the UNI 3.1 Specification. Additional identifiers in the Broadband Low Layer Information (B-LLI) information element (IE) distinguish the particular type of CES SVC being set up.
6.2	SETUP Message Contents
Section 5.3.1.7 in the UNI 3.1 Specification lists the mandatory and optional information elements in the SETUP message. This CES specification places constraints on the values of certain fields in the following mandatory information elements:
1.	ATM Traffic Descriptor
2.	Broadband bearer capability
3.	QoS Parameter
The following sections describe those constraints.
The following information elements (which in general are optional) are required for CES signalling:
1.	The AAL Parameters Information Element
2.	The Broadband Low Layer Information Element
The required contents of these information elements are discussed in the following sections.
The other information elements identified in UNI 3.1 Section 5.3.1.7 as optional remain optional for CES SVCs; this CES specification places no constraints on the values of the fields in these optional information elements.
Note that in the following sections we have omitted the fixed information element header fields and field identifiers from this specification; these should be inserted in the appropriate place in the information element.
6.2.1	ATM Traffic Descriptor 
For CES SVCs, the following two fields in this information element must be specified:
1.	Forward peak cell rate CLP=0+1
2.	Backward peak cell rate CLP=0+1
The values for these fields should be calculated as specified in Section 5.1.
The Best Effort Indicator and the Traffic Management Options Identifier must be omitted. We recommend that the other fields be omitted as well.
6.2.2	Broadband Bearer Capability 
The following table specifies the values for the fields in this information element.

Field	Value	
Bearer Class	‘1000 0’ BCOB-X	
Traffic Type	‘001’ Constant bit rate	
Timing Requirements	‘01’ End-to-end timing required	
Susceptibility to clipping	‘00’ Not susceptible to clipping	
User Plane Connection Configuration	‘00’ Point-to-point	
Table 6-1:  Broadband Bearer Capability IE Field Values for CES SVCs
6.2.3	Quality of Service Parameter 
The following table specifies the values for the fields in this information element.

Field	Value	
QoS Class Forward	‘0000 0001’ QoS Class 1	
QoS Class Backward	‘0000 0001’ QoS Class 1	
Table 6-2: QoS Parameter IE Field Values for CES SVCs
The Coding Standard field in this Information Element shall be coded as “11” when operating over ATM Forum compliant networks.  However, when interfacing to an ITU conformant network that is not ATM Forum compliant, the Coding Standard shall be coded “00” and the QoS Class Forward and QoS Class Backward are each coded “0000 0000”, meaning QoS Class 0 — Unspecified QoS Class.
6.2.4	ATM Adaptation Layer Parameters 
The values in this information element vary with the particular choice of CES. The following six tables specify the field values for Nx64 Service, DS1 (+ Logical) Unstructured Service, E1 (+ Logical) Unstructured Service, J2 (+ Logical) Unstructured Service, DS3 (+ Logical) Unstructured Service, and E3 (+ Logical) Unstructured Service respectively. If the called party does not accept these parameters, it should release the call with cause 93 (AAL Parameters not Supported).

Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0000 0001’ 64 kbit/s
‘0100 0000’ Nx64 kbit/s, N>1	
Multiplier	The value ‘N’ for Nx64 kbit/s.  Omit field for 64 kbit/s case.	
Structured Data Transfer Blocksize	Size in octets, as defined in Section 2.3.1	
Partially filled cells method	K, the number of AAL-user octets filled per cell; see Section 2.2.2. Omit field if partial cell fill is not used	
Table 6-3:  AAL Parameters IE Field Values for Nx64 Service SVCs

Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0000 0100’ 1544 kbit/s (DS1)	
Source Clock Frequency Recovery Method	‘0000 0000’ Null (synchronous circuit transport)	
	‘0000 0001’ SRTS method (asynchronous circuit transport)	
	‘0000 0010’ Adaptive method (asynchronous circuit transport)	
Table 6-4:  AAL Parameters IE Field Values for DS1 Unstructured Service and DS1 Logical Unstructured Service SVCs

Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0001 0000’ 2048 kbit/s (E1)	
Source Clock Frequency Recovery Method	‘0000 0000’ Null (synchronous circuit transport)	
	‘0000 0001’ SRTS method (asynchronous circuit transport)	
	‘0000 0010’ Adaptive method (asynchronous circuit transport)	
Table 6-5:  AAL Parameters IE Field Values for E1 Unstructured Service and E1 Logical Unstructured Service SVCs

Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0000 0101’ 6312 kbit/s	
Source Clock Frequency Recovery Method	‘0000 0000’ Null (synchronous circuit transport)	
	‘0000 0001’ SRTS method (asynchronous circuit transport)	
	‘0000 0010’ Adaptive method (asynchronous circuit transport)	
Table 6-6:  AAL Parameters IE Field Values for J2 Unstructured Service and J2 Logical Unstructured Service SVCs

Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0000 0111’ 44736 kbit/s (DS3)	
Source Clock Frequency Recovery Method	‘0000 0000’ Null (synchronous circuit transport)	
	‘0000 0001’ SRTS method (asynchronous circuit transport)	
	‘0000 0010’ Adaptive method (asynchronous circuit transport)	
Table 6-7: AAL Parameters IE Field Values for DS3 Unstructured Service and DS3 Logical Unstructured Service SVCs
Field	Value	
AAL Type	‘0000 0001’ AAL Type 1	
Subtype	‘0000 0010’ Circuit Transport	
CBR rate	‘0001 0010’ 34368 kbit/s (E3)	
Source Clock Frequency Recovery Method	‘0000 0000’ Null (synchronous circuit transport)	
	‘0000 0001’ SRTS method (asynchronous circuit transport)	
	‘0000 0010’ Adaptive method (asynchronous circuit transport)	
Table 6-8: AAL Parameters IE Field Values for E3 Unstructured Service and E3 Logical Unstructured Service SVCs
6.2.5	Broadband Low Layer Information
This information element identifies that the signaling entities are ATM Forum CES AAL User Entities as specified in this CES-IS. It also identifies the specific service and coding approach for Nx64 Service.

Field	Value	
User Information Layer 3 Protocol
(octet 7)	‘01011’ ISO/IEC TR 9577	
ISO/IEC TR 9577 Initial Protocol Identifier (IPI)
(octet 7a, 7b)	IPI is coded ‘1000 0000’ to indicate IEEE 802.1 SNAP identifier.  Hence, octets 7a and 7b are coded as ‘0100 0000’ and ‘0000 0000’, respectively.	
Organizational Unit Identifier (OUI)
(octets 8.1-8.3)	x’00 A0 3E’ ATM Forum OUI	
Protocol Identifier (PID)
(octets 8.4-8.5)	x’00 00’ Ignored for Unstructured Service	
	x’00 06’ DS1/E1/J2 Nx64 Basic Service	
	x’00 07’ E1 Nx64 Service w/CAS	
	x’00 08’ DS1 SF Nx64 Service w/CAS	
	x’00 09’ DS1 ESF Nx64 Service w/CAS	
	x’00 0B’ J2 Nx64 Service w/CAS	
Table 6-9:  Broadband Low Layer Information IE Field Values for CES SVCs

7.	Call Initiation Procedures
This chapter specifies optional procedures for the automatic initiation of an SVC between two CES entities. The purpose of specifying these procedures is to give meaning to the MIB variables they reference. Within this chapter, must and should apply only if the optional procedures are supported.
7.1	Overview of SVC Procedures
These procedures support automatic setup of an SVC between two circuit emulation processes. Using these procedures, the connection endpoints are provisioned via management action, identifying each endpoint by assigning them unique ATM addresses. Once provisioned, these procedures allow the endpoints to establish the connection, without further network management or user intervention.
A process supporting SVCs may be provisioned to support 2 modes:
•	passive, in which it only awaits incoming calls and does not initiate outgoing calls, and
•	active, in which it makes call attempts periodically whenever a call is not in progress. In this mode, it is also possible to configure the process to cease call attempts after a configured number of failed attempts.
This specification gives the flexibility to the operator through setting of the MIB variables to either have both ends retry calls until successful, or have calls initiated only by a single end.
Note that since the parameters of this type of connection are established administratively, separate from the processes that establish the connection itself, negotiation of end to end parameters is not possible. For example, traffic parameters will not be negotiable. If any of the configured parameters cannot be supported by the switching network, the call establishment will fail.
7.2	MIB Variables
The CES Active SVC Table (atmfCESActiveSvcTable) contains the information necessary for control and management of the automatic SVC initiation procedures. For more information on the creation and deletion of rows in this table, refer to section 8. Twelve variables are defined in the atmfCESActiveSvcEntry for use by active and passive SVC processes. For information on these variables, refer to the atmfCESActiveSvcTable section of the CES Version 2 MIB in section 8.4.2.
Note that atmfCESLocalAddr is the ATM address of the local circuit emulation process. For a device supporting only a single circuit emulation process, this could be the only ATM address assigned to that device on the ATM network. However, it is presumed that many implementations will include many circuit emulation processes, so that multiple ATM addresses are assigned to the device. It is possible that these ATM addresses differ only in the value of the selector byte, but that is not required by this specification. This specification does require that each distinct CES entity have a different ATM address.
Note also that atmfCESConnType specifies whether the local circuit emulation process is supposed to initiate calls. If the value is “pvc”, the process does whatever internal procedures it needs to be connected to a PVC on a particular VPI VCI. If the value is “activeSvc”, the process follows the procedures described in “Active SVC Procedures” below. If the value is “passiveSvc”, the process does whatever internal procedures it needs to be able to receive ATM calls directed to “atmfCESLocalAddr”.

7.3	Active SVC Procedures
In order to configure a circuit emulation process to initiate ATM calls, the following steps are taken:
1.	The atmfCESConfEntry for the local circuit emulation process must first be configured with a local address (in atmfCESLocalAddr) and a connection type of ‘activeSvc’ (in atmfCESConnType). When the atmfCESConnType is set to ‘activeSvc’, a corresponding entry in the atmfCESActiveSvcTable is created by the agent.
2.	The atmfCESActiveSvcEntry must then be configured with the address of the remote circuit emulation process - i.e., the “other” end of the logical facility being emulated. In addition, other parameters used to specify the retry behavior used when call attempts fail or the call is cleared may be configured. Once the atmfCESRemoteAddr has been configured, call attempts are initiated.
A circuit emulation process which has atmfCESConnType set to ‘activeSVC’ should initiate calls to the specified remote address whenever the atmfCESRemoteAddr has been configured and the ATM link is available, but there is no call active. No call attempts are made when no remote address has been specified. If the value of the remote address changes while an SVC call is established, the established call must be cleared.
Unsuccessful calls should be retried at a rate governed by atmfCESFirstRetryInterval, as long as the atmfCESRetryFailures count has not reached the value specified in atmfCESRetryLimit (if non-zero).
Once the number of such failures reaches the configured limit value, no further call attempts will be made. Call establishment procedures can then be started again only by network management action to set the value of atmfCESConnectionRestart to ‘restart’, at which time the atmfCESRetryFailures count will be cleared and the call establishment process restarted.
7.4	Call Collision
If a circuit emulation process receives a valid incoming call while it has an outgoing call in progress, it should compare the value of the source and destination ATM addresses in the incoming call. If the source address is smaller than the destination address, the incoming call should be accepted, and the outgoing call cleared. Otherwise, the incoming call should be cleared.
7.5	Call Retry
Note that strict adherence to precisely the retry interval indicated by atmfCESFirstRetryInterval is to be avoided. Rather, the implementation should apply some random differential from this value on each retry. In addition, it may be desirable to increase the retry interval on each retry in order to implement a backoff scheme when successive retries continue to fail.

8.	Management
In general, the CES IWF will be implemented in equipment that supports one or more ATM ports and one or more CBR interfaces (typically DS1 and/or E1 ports). Thus, the equipment that incorporates one or more IWFs will have an “ATM side”, a “CBR side” (corresponding to the Service Interface), and a set of entities that cause the two to interwork. The ATM Forum’s Network Management Working Group is specifying the management of the ATM equipment (the “ATM side”). In addition, the ATM Forum’s Network Management Working Group is also addressing the AAL and CES management protocol independent requirements, plus CMIP MIBs. However, the Network Management Working Group will not address the SNMP MIBs for the management aspects pertaining to the Service Interface and interworking entities:
1.	The DS1, E1, J2, DS3 or E3 Service Interfaces
2.	DS0 or DS0 Bundle Entities
3.	The CES Mapping Functions
4.	The AAL1 entities
This section  describes the management of CES IWF via SNMP or SNMPv2. If SNMP is implemented in a device this section specifies the implementation. It is outside the scope of this document to specify a MIB for CMIP.  The relationships between different logical and  physical interfaces is described in accordance with IETF RFC1573.  This MIB is written in compliance with SMIv2 RFC1442.
One of the basic functions of  this section is to define cross-connections between Constant Bit Rate Service interfaces and ATM interfaces. The example shown in Figure 8-1 below depicts how a single device can have multiple CES IWF entities mapping CBR interfaces to ATM interfaces. The number in "()" represents a unique number identifying each interface called the instance number or ifIndex as described in RFC 1573.  For each ifIndex listed in Figure 8-1, there is one ifTable entry as defined in RFC 1573.  RFC 1573 also describes the layering of one interface above and below another interface. This section defines the interfaces per RFC1573, the layering of the interfaces per RFC 1573, the DS0 channel to CES IWF mapping per RFC TBD (the new IETF DS0 MIB), and finally the CES SMIv2 MIB.

Figure 8-1:  CES IWF Instances Mapping CBR Instances to ATM Instances

Management information for the CES IWF is organized into four tables in the CES Version 2 MIB: the CES Configuration Table, the CES Mapping Table, the CES Statistics Table, and the CES Active SVC Table.
Basic configuration information for a CES IWF is managed via the CES Configuration Table (atmfCESConfTable). An instance of the management information for a CES IWF is created in this table by a management entity via the creation of a row of objects. This creation is an action by a managing system because there is typically not a fixed or predetermined relationship between the CES IWF and the physical interfaces for which it provides circuit emulation service, or even between the CES IWF and the management entities for the physical interfaces (e.g., the DS1 MIB entities) or the logical interfaces (e.g., DS0 MIB or DS0Bundle MIB entities) for which it provides circuit emulation service. Consequently this relationship is established by the creation of the entry in the atmfCESConfTable. This creation process is controlled by the atmfCESConfRowStatus object, as described by the SNMPv2 SMI. Similarly, deletion of an instance of management information for a CES IWF is accomplished by the deletion of the corresponding row in the CES Configuration Table (atmfCESConfTable).
Performance information is maintained for the CES IWF in the CES Statistics Table (atmfCESStatsTable). Creation of the row in the atmfCESConfTable automatically causes the creation of a corresponding row of objects in the atmfCESStatsTable. Likewise, deletion of a row in the atmfCESConfTable will cause the deletion of the corresponding row in the atmfCESStatsTable. Thus there will always be a one-to-one relationship between rows in these two tables.
The ability to identify the CES IWF which is associated with a known ATM interface, VPI and VCI is provided by the CES Mapping Table (atmfCESMappingTable). An entry in this table is automatically created for every atmfCESConfTable entry with a non-zero atmfCESAtmIndex. Likewise, an entry in this table is deleted from this table when the atmfCESAtmIndex in the corresponding atmfCESConfTable entry is either set to zero or when that corresponding atmfCESConfTable entry is deleted.
Note that the ability to identify the CES IWF which is associated with a known CBR interface (or related logical interface), if any, is provided by the CES Configuration Table itself. Entries in this table are indexed by atmfCESCbrIndex, which is defined to be equal to MIB II’s ifIndex value for that CBR physical or logical interface. And since both the ATM interface index (atmfCESAtmIndex) and the CBR interface index (atmfCESCbrIndex) are also included in the CES Configuration Table, it is then possible to trace a connection from the CES IWF to both its ATM and CBR interfaces as well as from either the ATM or CBR interface to the corresponding CES IWF. Thus the full connection can be traced once any object in this connection is known.
The ability to support automatic establishment of a virtual channel connection over the ATM network for a CES IWF is provided by the CES Active SVC Table (atmfCESActiveSvcTable). An entry in this table is automatically created for each active row in the CES Configuration Table (atmfCESConfTable) with a connection type (atmfCESConnType) equal to ‘activeSVC’. This CES Active SVC Table entry can then be configured with the information necessary to control and manage the automatic establishment of the needed SVC. For further information on this process, refer to Section 7.
8.1	
CES IWF Interfaces (per RFC 1573)
Each interface (e.g. ATM and CBR) shall have a single entry in the ifTable as defined by RFC 1573. This ensures all instance numbers are unique and allows the CES IWF to define which variables in the CES MIB may cause CES IWF linkup and linkdown traps to be generated. The CES MIB then provides a mechanism to relate to the CBR interface for which it provides service and to the ATM interface over which this service is provided. The following tables are sample ifTable entries.

RFC 1573 ObjectId	Value	Description	
ifIndex	9	Unique number to identify an interface.	
IfDescr	"CBR mapped to CES #3 and CES #4"	This is a string of up to 255 characters used to describe the interface. In this case it is useful to describe that this CBR (9)  interface is mapped to CES #3 and CES #4.	
IfType	ds1 (18)	A CBR interface defined by RFC TBD (the new IETF DS1 MIB) which defines interfaces of ifType equal to ds1 (18).	
IfSpeed	1,544,000	Bits per second speed of interface.	
IfAdminStatus	up (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
IfOperStatus	up (1)	This object is set to the value down (2)  if the object dsx1LineStatus has any value other than dsx1NoAlarm(1) or ifAdminStatus is down (2).	
IfLastChange	0	Time when operational state last changed.	
IfLinkUpDownTrapEnable	enabled (1)	Enable/Disable the sending of LinkUp and LinkDown traps. If enabled, LinkUp or LinkDown traps will be sent based on the value of ifOperStatus.	
IfName	"CBR_9"	A string representing the interface. This allows other devices to use the same name and perform functions like "ping" without knowledge of cryptic numbers.	
Table 8-1:  Sample CBR (9) ifTable entry of ifType ds1(18)

RFC 1573 ObjectId	Value	Description	
ifIndex	10	Unique number to identify an interface.	
IfDescr	"DS3"	This is a string of up to 255 characters used to describe the interface.  	
IfType	ds3 (30)	DS3  interfaces are defined by RFC TBD (the new IETF DS3 MIB)  which defines interfaces of ifType equal to ds3 (30).	
IfSpeed	44,736,000	Bits per second speed of interface.	
IfAdminStatus	up  (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
IfOperStatus	up (1)	This object is set to the value down (2)  if the object dsx3LineStatus has any value other than dsx3NoAlarm(1) or ifAdminStatus is down (2).	
IfLastChange	0	Time when operational state last changed.	
IfLinkUpDownTrapEnable	enabled (1)	Enable/Disable the sending of LinkUp and LinkDown traps. If enabled, LinkUp or LinkDown traps will be sent based on the value of ifOperStatus.	
ifName	"ATM_1 - DS3_10"	A string representing the interface.	
Table 8-2:  Sample DS3 (10) ifTable entry of ifType ds3 (30)

RFC 1573 ObjectId	Value	Description	
ifIndex	1	Unique number to identify an interface.	
IfDescr	"ATM mapped to CES #1, CES #2, and CES #3. "	This is a string of up to 255 characters used to describe the interface. In this case it is useful to describe that this ATM (1) interface  is mapped to CES #1, CES #2, and CES #3. 	
IfType	atm (37)	ATM  interfaces are defined by RFC 1695.	
IfSpeed	44,736,000	Bits per second speed of interface.	
IfAdminStatus	up  (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
IfOperStatus	up (1)	Assumes the value down(2) if the ATM cell layer or any layer below that layer is down.	
IfLastChange	0	Time when operational state last changed.	
IfLinkUpDownTrapEnable	enabled (1)	Enable/Disable the sending of LinkUp and LinkDown traps. If enabled, LinkUp or LinkDown traps will be sent based on the value of ifOperStatus.	
ifName	"ATM_1"	A string representing the interface. This allows other devices to use the same name and perform functions like "ping" without knowledge of cryptic numbers.	
Table 8-3:  Sample ATM (1) ifTable entry of ifType atm (37)

RFC 1573 ObjectId	Value	Description	
ifIndex	7	Unique number to identify an interface.	
ifDescr	"Maps CES #1 to Logical (7)"	This is a string of up to 255 characters used to describe the interface.	
ifType	other  (1)	There is no IANAifType defined for logical; therefore, other must be used.	
ifSpeed	0	Value depends on the meaning of logical interface.	
ifAdminStatus	up  (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
ifOperStatus	up (1)	Interface dependent.	
ifLastChange	0	Time when operational state last changed.	
ifLinkUpDownTrapEnable	enabled (1)	Enable/Disable the sending of LinkUp and LinkDown traps. If enabled, LinkUp or LinkDown traps will be sent based on the value of ifOperStatus.	
ifName	"Logical_7"	A string representing the interface. This allows other devices to use the same name and perform functions like "ping" without knowledge of cryptic numbers.	
Table 8-4:  Sample Logical (7) ifTable entry of ifType other (1)

8.2	CES IWF Layers (per RFC 1573)
Figure 8-2 shows the layers required and which MIBs are used to manage each layer.

Figure 8-2:  CES Layers from CBR Interface to ATM Interface
8.3	CES IWF to DS0 Mapping (per RFC TBD [the new IETF DS0 MIB])
It is possible to map DS0 channels from one CBR interface to multiple CES IWFs. This is NOT accomplished in the CES MIB. This is accomplished in the RFC TBD DS0 MIB by means of the ds0Bundle object. The ds0Bundle allows a group of timeslots (ds0’s) to be mapped to a CES IWF. Each timeslot may be mapped to a unique instance number, or an instance number sharing one or all other timeslots. Figure 8-3, which is based on Figure 8-1, shows a ds0Bundle (20) instantiated to bundle timeslots 1 through 4 together for one CES IWF and another ds0Bundle (21) instantiated to bundle timeslots 5 through 8 together for a different CES IWF.  The ifIndex values (12 through 19) for the ds0 instances are also illustrated in the figure.

Figure 8-3:  ATM, CES and CBR Mappings

The following tables illustrate sample ifTable entries for the ds0Bundle (20) and ds0 (12) of the above example.

RFC 1573 ObjectId	Value	Description	
ifIndex	20	Unique number to identify an interface.	
IfDescr	"ds0 ifIndexes 12-15 mapped to CES #3"	This is a string of up to 255 characters used to describe the interface. In this case it is useful to describe that the ds0 interfaces (ifIndexes 12-15) are mapped to CES #3.	
IfType	ds0Bundle (82)	ds0Bundles are defined by RFC TBD (the new IETF DS0 MIB) with ifType equal to ds0Bundle (82).	
IfSpeed	256,000	Bits per second speed of interface. Nx64000 for ds0Bundles.	
			
ifAdminStatus	up (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
ifOperStatus	up (1)	This object is set to the value down (2)  if ifAdminStatus is down (2).	
ifLastChange	0	Time when operational state last changed.	
ifName	"DS0B_20"	A string representing the interface. This allows other devices to use the same name and perform functions like "ping" without knowledge of cryptic numbers.	
ifLinkUpDownTrapEnable	disabled (2)	Must be set to disabled (2).	
ifHighSpeed	(0)	Must be set to (0)	
ifConnectorPresent	false (2)	Must be set to false (2)	
Table 8-5:  Sample ds0Bundle (20) ifTable entry of ifType ds0Bundle (82)

RFC 1573 ObjectId	Value	Description	
ifIndex	12	Unique number to identify an interface.	
ifDescr	"ds0 timeslot 1"	This is a string of up to 255 characters used to describe the interface. In this case it is useful to describe the DS0 timeslot.	
ifType	ds0 (81)	ds0s are defined by RFC TBD (the new IETF DS0 MIB) with ifType equal to ds0 (81).	
ifSpeed	64000	Bits per second speed of interface.	
			
ifAdminStatus	up (1)	Value is up (1) or down (2) depending on whether the interface has been administratively configured.	
ifOperStatus	up (1)	This object is set to the value down (2) if ifAdminStatus is down (2).	
ifLastChange	0	Time when operational state last changed.	
ifName	"timeslot_1"	A string representing the interface. This allows other devices to use the same name and perform functions like "ping" without knowledge of cryptic numbers.	
ifLinkUpDownTrapEnable	disabled (2)	Must be set to disabled (2).	
ifHighSpeed	(0)	Must be set to (0)	
ifConnectorPresent	false (2)	Must be set to false (2)	
Table 8-6:  Sample ds0 (12) ifTable entry of ifType ds0 (81)

The objects managing the CBR interface and DS0 channels are linked together via the ifStackTable, as defined in RFC 1573. Table 8-7 below displays all ifStackTable entries for the mappings shown in Figure 8-3. 

ifStackTable Entries	
HigherLayer	LowerLayer	
0	20	
0	21	
20	12	
20	13	
20	14	
20	15	
21	16	
21	17	
21	18	
21	19	
12	9	
13	9	
14	9	
15	9	
16	9	
17	9	
18	9	
19	9	
9	0	
Table 8-7:  Example ifStackTable Entries
8.4	
CES MIB
8.4.1	CES Version 1 MIB
The CES Version 1 MIB from af-saa-0032.000 (reproduced below) has been deprecated and totally replaced by the CES Version 2 MIB. This following CES Version 1 MIB should not be used for new designs.
The entire CES Version 1 MIB is mandatory.

ATMF-CES-MIB DEFINITIONS ::= BEGIN

IMPORTS
    enterprises                                 FROM RFC1155-SMI
    OBJECT-TYPE, MODULE-IDENTITY, Counter32     FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                          FROM SNMPv2-TC
    ifIndex                                     FROM IF-MIB;

atmForum                   OBJECT IDENTIFIER ::= { enterprises  353 }
atmForumNetworkManagement  OBJECT IDENTIFIER ::= { atmForum 5 }
atmfCESmib         OBJECT IDENTIFIER ::= { atmForumNetworkManagement 2 }

atmfDS1E1CESmib MODULE-IDENTITY
    LAST-UPDATED "9502030000Z"
    ORGANIZATION "ATM Forum Circuit Emulation Working Group"
    CONTACT-INFO "fedorkow@cisco.com, myron@kentrox.com"
    DESCRIPTION  "This MIB module is deprecated, and is being replaced
                  by the atmfCES module as a more generic Circuit
                  emulation MIB.
                  
                  The MIB module to describe the DS1/E1
                  Circuit Emulation Interworking Function (Version 1.0)"
::= { atmfCESmib 1 } 

-- an OBJECT IDENTIFIER for all ATM Forum circuit emulation MIBs
-- has been assigned as a branch from the Forum Network Management
-- tree.  The DS1/E1 Circuit Emulation specification is attached
-- as the first branch from the overall atmfCESmib object.  Future
-- branches may be added in the future for further CES work, for
-- example, DS3/E3 circuit emulation.

--  this is the MIB module for the ATM Forum DS1/E1 Circuit Emulation
--  Interworking Function objects

-- the following TEXTUAL-CONVENTIONS are used to link the CES
-- interworking function to ATM interface port, plus the
-- associated VPI and VCI.

VpiInteger ::= TEXTUAL-CONVENTION
    STATUS     deprecated
    DESCRIPTION
          "An integer large enough to hold a VPI"
    SYNTAX     INTEGER (0..4095)

VciInteger ::= TEXTUAL-CONVENTION
    STATUS     deprecated
    DESCRIPTION
          "An integer large enough to hold a VCI"
    SYNTAX     INTEGER (0..65535)

CESConnectionPort ::= TEXTUAL-CONVENTION
    STATUS deprecated
    DESCRIPTION 
          "Indicates the port associated with a Circuit Emulation
          connection.
          Objects of this type are always define as part of a set
          that includes
             fooPort       CESConnectionPort
             fooVPI        VpiInteger
             fooVCI        VciInteger
          The interpretation of these objects is as follows:
          1. If no connection exists, ‘fooPort' has a value of 0.
             Because Interfaces table entries always have ‘ifIndex'
             values greater than 0, ‘fooPort' reliably serves as a
             ‘connection exists' flag.
             If no connection exists, ‘fooVPI' and ‘fooVCI' are 
             meaningless and have a value of 0.
          2. If a PVC or SVC exists, fooPort is defined to have the
             value of the MIB-II/RFC1573 ‘ifIndex' of the ATM 
             interface associated with the VCC.  ‘fooVPI' and ‘fooVCI'
             will contain its VPI/VCI."
             
    SYNTAX     INTEGER (0..2147483647)

atmfDS1E1CESmibObjects  OBJECT IDENTIFIER ::= {atmfDS1E1CESmib 1}

atmfDS1E1CESConfTable    OBJECT-TYPE
    SYNTAX  SEQUENCE OF AtmfDS1E1CESConfEntry
    MAX-ACCESS  not-accessible
    STATUS  deprecated
    DESCRIPTION
        "The CES configuration table. This includes mapping channels from
         ATM Port to CBR interfaces. There is one AtmfDS1E1CESConfEntry
         per CES Entity"
    ::= { atmfDS1E1CESmibObjects  1 }

atmfDS1E1CESConfEntry    OBJECT-TYPE
    SYNTAX  AtmfDS1E1CESConfEntry
    MAX-ACCESS  not-accessible
    STATUS  deprecated
    DESCRIPTION
      "An entry in the CES table. For each entry there is a corresponding
         entry in the stack table"
    INDEX   { ifIndex }
    ::= { atmfDS1E1CESConfTable 1 }

AtmfDS1E1CESConfEntry ::= SEQUENCE  {
    atmfDS1E1CESMapATMIndex                CESConnectionPort,
    atmfDS1E1CESMapVPI                     VpiInteger,
    atmfDS1E1CESMapVCI                     VciInteger,
    atmfDS1E1CESCBRService                 INTEGER,
    atmfDS1E1CESCBRClockMode               INTEGER,
    atmfDS1E1CESCas                        INTEGER,
    atmfDS1E1CESPartialFill                INTEGER,
    atmfDS1E1CESBufMaxSize                 INTEGER,
    atmfDS1E1CESCDVRxT                     INTEGER,
    atmfDS1E1CESCellLossIntegrationPeriod  INTEGER
}

atmfDS1E1CESMapATMIndex     OBJECT-TYPE
    SYNTAX      CESConnectionPort
    MAX-ACCESS  read-only
    STATUS      deprecated
    DESCRIPTION
         "The value of this object is equal to MIB II's
           ifIndex value of the ATM Port interface mapped 
           through this CES to a CBR interface."
    ::= { atmfDS1E1CESConfEntry 1 }

atmfDS1E1CESMapVPI           OBJECT-TYPE
    SYNTAX      VpiInteger
    MAX-ACCESS  read-only
    STATUS      deprecated
    DESCRIPTION
         "The value of this object is equal to the VPI used
          for the emulated circuit represented by this entry
          in the ifTable.  If there is no connection, this
          object is meaningless and will have the value zero."
    ::= { atmfDS1E1CESConfEntry 2 }

atmfDS1E1CESMapVCI           OBJECT-TYPE
    SYNTAX      VciInteger
    MAX-ACCESS  read-only
    STATUS      deprecated
    DESCRIPTION
         "The value of this object is equal to the VCI used
          for the emulated circuit represented by this entry
          in the ifTable.  If there is no connection, this
          object is meaningless and will have the value zero"
    ::= { atmfDS1E1CESConfEntry 3 }

atmfDS1E1CESCBRService          OBJECT-TYPE
    SYNTAX INTEGER {
                   unstructured(1),
                   structured(2)
                   }
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
         "Define if DS1/E1 service as structured or not. A
          structured(2) interface is some nx64Kbps. An unstructured
          (1) interface is 1.544Mbps or 2.048Mbps. Unstructured(1) 
          passes all bits through the ATM network. 
          strucutured(2) passes data bits through the ATM network, and 
          may also pass signalling bits"
    ::= { atmfDS1E1CESConfEntry 4 }

atmfDS1E1CESCBRClockMode    OBJECT-TYPE
    SYNTAX INTEGER {
                   synchronous(1),
                   srts(2),
                   adaptive(3)
                   }
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
         "Define if DS1/E1 service clocking mode. This maps into
          transmit clock source of CBR interface."
    DEFVAL { synchronous } 
    ::= { atmfDS1E1CESConfEntry 5 }

atmfDS1E1CESCas      OBJECT-TYPE
    SYNTAX INTEGER {
                   basic(1),
                   e1Cas(2),
                   ds1SfCas(3),
                   ds1EsfCas(4)
                   }
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
      "This parameter selects which AAL1 Format should be used:
       Basic does not carry CAS bits, and uses a single 125 usec frame.
       e1Cas, ds1SfCas and dS1EsfCas carry CAS bits in a multiframe
       structure for E1, DS1 SF and DS1 ESF respectively.
       This applies to structured interfaces only. Default is basic (1)."
    DEFVAL { basic } 
    ::= { atmfDS1E1CESConfEntry 6 }

atmfDS1E1CESPartialFill     OBJECT-TYPE
    SYNTAX INTEGER (0 .. 47)
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
         "If partial cell fill is used, the number of user octets per
         cell must be set with this parameter.  Setting this parameter
         to zero disables partial cell fill, and causes all cells to
         be completely filled before they are sent."
    DEFVAL { 0 } -- Partial Cell Fill not used
    ::= { atmfDS1E1CESConfEntry 7 }

atmfDS1E1CESBufMaxSize      OBJECT-TYPE
    SYNTAX       INTEGER  (1..65536)
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
         "Define maximum size in octets of the reassembly buffer.
          Some implementations may want allow the maximum buffer size to 
          programmed to a size less than the physical limit to reduce 
          the maximum delay through a circuit."
    DEFVAL { 256 } 
    ::= { atmfDS1E1CESConfEntry 8 }

atmfDS1E1CESCDVRxT         OBJECT-TYPE
    SYNTAX       INTEGER  (1..65535)
    UNITS "10 usec"
    MAX-ACCESS    read-write
    STATUS        deprecated
    DESCRIPTION
         “The maximum cell arrival jitter in 10 usec increments that 
         the reassembly process will tolerate in the cell stream without
         producing errors on the CBR service interface. ”
    DEFVAL { 100 } 
    ::= { atmfDS1E1CESConfEntry 9 }

atmfDS1E1CESCellLossIntegrationPeriod   OBJECT-TYPE
    SYNTAX INTEGER  (1000 .. 65535)
    UNITS "msec"
    MAX-ACCESS read-write
    STATUS     deprecated
    DESCRIPTION
         "The time in milliseconds for the cell loss integration period. 
          If a cells are lost for this period of time.
          atmfDS1E1CESCellLossStatus is set to loss (2).The current
          definition is 2500."
    DEFVAL { 2500 } 
    ::= { atmfDS1E1CESConfEntry 10 }

atmfDS1E1CESStatsTable    OBJECT-TYPE
    SYNTAX  SEQUENCE OF AtmfDS1E1CESStatsEntry
    MAX-ACCESS  not-accessible
    STATUS  deprecated
    DESCRIPTION
          "The CES AAL1 statistical data table."
    ::= { atmfDS1E1CESmibObjects  2 }

atmfDS1E1CESStatsEntry    OBJECT-TYPE
    SYNTAX  AtmfDS1E1CESStatsEntry
    MAX-ACCESS  not-accessible
    STATUS  deprecated
    DESCRIPTION
          "An entry in the CES AAL1 Stats table."
    INDEX   { ifIndex }
    ::= { atmfDS1E1CESStatsTable 1 }

AtmfDS1E1CESStatsEntry ::= SEQUENCE  {
    atmfDS1E1CESReassCells         Counter32,
    atmfDS1E1CESHdrErrors          Counter32,
    atmfDS1E1CESPointerReframes    Counter32,
    atmfDS1E1CESLostCells          Counter32,
    atmfDS1E1CESBufUnderflows      Counter32,
    atmfDS1E1CESBufOverflows       Counter32,
    atmfDS1E1CESCellLossStatus     INTEGER
    }

atmfDS1E1CESReassCells         OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "This count gives the number of cells played out to the DS1/E1
         Service Interface. It excludes cells that were discarded for
         any reason, including cells that were not used due to being
         declared misinserted, or discarded while the reassembler was
         waiting to achieve synchronization."
    ::= { atmfDS1E1CESStatsEntry 1 }

atmfDS1E1CESHdrErrors         OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "The count of the number of AAL1 header errors detected and
         possibly corrected.  Header errors include correctable and
         uncorrectable CRC, plus bad parity."
    ::= { atmfDS1E1CESStatsEntry 2 }

atmfDS1E1CESPointerReframes    OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "This records the count of the number of events in which the
         AAL1 reassembler found that an SDT pointer is not where it is
         expected, and the pointer must be reacquired."
    ::= { atmfDS1E1CESStatsEntry 3 }

atmfDS1E1CESLostCells   OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "Number of lost cells."
    ::= { atmfDS1E1CESStatsEntry 4 }

atmfDS1E1CESBufUnderflows      OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "Number of buffer underflows."
    ::= { atmfDS1E1CESStatsEntry 5 }

atmfDS1E1CESBufOverflows      OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "Number of buffer overflows."
    ::= { atmfDS1E1CESStatsEntry 6 }

atmfDS1E1CESCellLossStatus      OBJECT-TYPE
    SYNTAX INTEGER {
                   noLoss(1),
                   loss(2)
                   }
    MAX-ACCESS    read-only
    STATUS        deprecated
    DESCRIPTION
         "When cells are lost for the number of milliseconds specified
          by atmfDS1E1CESCellLossIntegrationPeriod, the value is set to
          loss (2). When cells are no longer lost, the value is set 
          to noLoss (1)."
    ::= { atmfDS1E1CESStatsEntry 7 }
END

8.4.2	CES Version 2 MIB
The following CES Version 2 MIB provides the SNMPv2 Network Management interface to the CES Version 2 Interworking Function (IWF).

ATMF-CES DEFINITIONS ::= BEGIN

IMPORTS
    enterprises                                 FROM RFC1155-SMI
    OBJECT-TYPE, MODULE-IDENTITY, Counter32,
    Gauge32                                     FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, RowStatus               FROM SNMPv2-TC
    InterfaceIndex                              FROM IF-MIB
    MODULE-COMPLIANCE, OBJECT-GROUP             FROM SNMPv2-CONF;

atmfCES MODULE-IDENTITY
    LAST-UPDATED "9611050000Z"
    ORGANIZATION "ATM Forum Circuit Emulation Working Group"
    CONTACT-INFO "The ATM Forum
                  2570 West El Camino Real, Suite 304
                  Mountain View, CA 94040-1313 USA
                  Phone: +1 415-949-6700
                  Fax:   +1 415-949-6705
                  info@atmforum.com"
    DESCRIPTION  "The MIB module used to describe the
                  Circuit Emulation Interworking Function
                  (Version 2.0)"
    REVISION     "9502030000Z"
    DESCRIPTION  "The MIB Module to describe the DS1/E1Circuit
                  Emulation Interworking Function (Version 1.0)
                  Note: The new Version 2 CES MIB replaces this earlier
                  Version 1 CES MIB which exists as the (deprecated)
                  first branch from the overall atmfCESmib object."
::= { atmfCESmib 2 } 

atmForum                    OBJECT IDENTIFIER ::= { enterprises 353 }
atmForumNetworkManagement   OBJECT IDENTIFIER ::= {atmForum 5 }
atmfCESmib      OBJECT IDENTIFIER ::= { atmForumNetworkManagement 2 }

-- An OBJECT IDENTIFIER for all ATM Forum circuit emulation MIBs
-- has been assigned as a branch from the ATM Forum Network
-- Management tree.  This MIB for the version 2 ATM Forum Circuit
-- Emulation specification is attached as the second branch from the
-- overall atmfCESmib object.

-- The following TEXTUAL-CONVENTIONS are used to link the CES
-- interworking function to ATM interface port, plus the
-- associated VPI and VCI.

VpiInteger ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "An integer large enough to hold a VPI"
    SYNTAX     INTEGER (0..4095)

VciInteger ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION
        "An integer large enough to hold a VCI"
    SYNTAX     INTEGER (0..65535)

CESConnectionPort ::= TEXTUAL-CONVENTION
    STATUS     current
    DESCRIPTION 
        "Indicates the port associated with a Circuit Emulation
         connection.  Objects of this type are always defined as
         part of a set that includes
            fooPort       CESConnectionPort
            fooVpi        VpiInteger
            fooVci        VciInteger
         The interpretation of these objects is as follows:
         1. If no connection exists, 'fooPort' has a value of 0.
            Because Interface table entries always have 'ifIndex'
            values greater than 0, 'fooPort' reliably serves as a
            'connection exists' flag.
            If no connection exists, 'fooVpi' and 'fooVci' are 
            not relevant and have a value of 0.
         2. If a PVC or SVC exists, 'fooPort' is defined to have
            the value of the MIB-II/RFC1573 'ifIndex' of the ATM
            interface associated with the VCC.  The ifType
            associated with such an ifIndex value is either
            atm(37) or atmLogical(80). 'fooVpi' and 'fooVci'
            will contain its VPI/VCI."
    SYNTAX     INTEGER (0..2147483647)

AtmAddr ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1x"
    STATUS  current
    DESCRIPTION
        "The ATM address used by the network entity.  The address
         types are: no address (0 octets), E.164 (8 octets), and
         NSAP-encoded ATM Endsystem Address (20 octets).
         Note: The E.164 address is encoded in BCD format."
    SYNTAX  OCTET STRING (SIZE(0|8|20))

-- This is the MIB module for the ATM Forum Circuit Emulation
-- Service Interoperability Specification Version 2.0.
-- 
-- This MIB contains four tables:
--    CES Configuration Table
--    CES Mapping Table
--    CES Statistics Table
--    CES Active SVC Table

-- CES Configuration Table

atmfCESObjects  OBJECT IDENTIFIER ::= {atmfCES 1}

atmfCESConfTable    OBJECT-TYPE
    SYNTAX  SEQUENCE OF AtmfCESConfEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
        "The CES configuration table used to manage interworking
         between CBR interfaces or channels and ATM Virtual Channel
         Links (VCLs).  The reverse mapping is shown in the
         atmfCESMappingTable."
    ::= { atmfCESObjects  1 }

atmfCESConfEntry    OBJECT-TYPE
    SYNTAX  AtmfCESConfEntry
    MAX-ACCESS  not-accessible
    STATUS  current
    DESCRIPTION
        "An entry in the CES configuration table.  There is one
         entry in the table per CES entity, mapping one CBR
         interface, channel, or bundle to an ATM VCL.

         Creation of a row in this table with a non-zero
         atmfCESAtmIndex causes a corresponding entry in the
         atmVclTable of the ATM-MIB (RFC1695) to be created."
    INDEX   { atmfCESCbrIndex }
    ::= { atmfCESConfTable 1 }

AtmfCESConfEntry ::= SEQUENCE  {
    atmfCESCbrIndex                   InterfaceIndex,
    atmfCESAtmIndex                   CESConnectionPort,
    atmfCESAtmVpi                     VpiInteger,
    atmfCESAtmVci                     VciInteger,
    atmfCESCbrService                 INTEGER,
    atmfCESCbrClockMode               INTEGER,
    atmfCESCas                        INTEGER,
    atmfCESPartialFill                INTEGER,
    atmfCESBufMaxSize                 INTEGER,
    atmfCESCdvRxT                     INTEGER,
    atmfCESCellLossIntegrationPeriod  INTEGER,
    atmfCESConnType                   INTEGER,
    atmfCESLocalAddr                  AtmAddr,
    atmfCESAdminStatus                INTEGER,
    atmfCESOperStatus                 INTEGER,
    atmfCESConfRowStatus              RowStatus
    }

atmfCESCbrIndex         OBJECT-TYPE
    SYNTAX        InterfaceIndex
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "The value of this object is equal to MIB II's ifIndex value
         of the CBR interface, channel, or bundle that is being
         cross-connected to an ATM VCL."
    ::= { atmfCESConfEntry 1 }

atmfCESAtmIndex         OBJECT-TYPE
    SYNTAX        CESConnectionPort
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The value of this object is equal to MIB II's
         ifIndex value of the ATM Port interface mapped 
         through this CES IWF to a CBR interface.  This value
         is overwritten whenever an active or passive SVC is
         established.

         The distinguished value zero indicates that no ATM
         interface has been specified."
    ::= { atmfCESConfEntry 2 }

atmfCESAtmVpi           OBJECT-TYPE
    SYNTAX        VpiInteger
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The value of this object is equal to the VPI used
         by the ATM VCL mapped through this CES IWF to a CBR
         interface.  This value is overwritten whenever an
         active or passive SVC is established.

         The value is not relevant if no ATM interface has been
         specified (i.e., atmfCESAtmIndex is set to zero)."
    ::= { atmfCESConfEntry 3 }

atmfCESAtmVci           OBJECT-TYPE
    SYNTAX        VciInteger
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The value of this object is equal to the VCI used
         by the ATM VCL mapped through this CES IWF to a CBR
         interface.  This value is overwritten whenever an
         active or passive SVC is established.

         The distinguished value zero indicates that no ATM
         VCL has been specified."
    ::= { atmfCESConfEntry 4 }

atmfCESCbrService       OBJECT-TYPE
    SYNTAX        INTEGER {
                      unstructured(1),
                      structured(2)
                      }
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Define if DSx/Ex service isas structured or unstructurednot. A
         structured(2) interface is some nx64kbKbps. An unstructured
         (1) interface is 1.544Mbps, 2.048Mbps, 6.312Mbps, 44.736 Mbps,
         or 34.368 Mbps. unstructured(1) passes all bits through the
         ATM network.  strucutured(2) passes data bits through the
         ATM network, and may also pass signalling bits
         
         At this time, only unstructured mode is defined for the
         44.736 Mbps and 34.368 Mbps services."
    ::= { atmfCESConfEntry 5 }

atmfCESCbrClockMode     OBJECT-TYPE
    SYNTAX        INTEGER {
                      synchronous(1),
                      srts(2),
                      adaptive(3)
                      }
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "Define if DSx/Ex service clocking mode. This maps into
         transmit clock source of CBR interface.

         For structured modes this value, if present, must be set to
         synchronous(1)."
    DEFVAL { synchronous } 
    ::= { atmfCESConfEntry 6 }

atmfCESCas      OBJECT-TYPE
    SYNTAX        INTEGER {
                      basic(1),
                      e1Cas(2),
                      ds1SfCas(3),
                      ds1EsfCas(4),
                      j2Cas(5)
                      }
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "This parameter selects which AAL1 Format should be used:
         Basic does not carry CAS bits, and uses a single 125 usec frame.
         e1Cas, ds1SfCas, dS1EsfCas and j2Cas carry CAS bits in a
         multiframe structure for E1, DS1 SF, DS1 ESF and J2 
         respectively.
         This applies to structured interfaces only. Default is
         basic (1). For unstructured interfaces this value, if present,
         must be set to the default of basic (1)."
    DEFVAL { basic } 
    ::= { atmfCESConfEntry 7 }

atmfCESPartialFill     OBJECT-TYPE
    SYNTAX        INTEGER (0 .. 47)
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "If partial cell fill is used, the number of user octets per
         cell must be set with this parameter.  Setting this parameter
         to zero disables partial cell fill, and causes all cells to
         be completely filled before they are sent."
    DEFVAL { 0 } -- Partial Cell Fill not used
    ::= { atmfCESConfEntry 8 }

atmfCESBufMaxSize      OBJECT-TYPE
    SYNTAX        INTEGER  (1..65536)
    UNITS         "10 usec"
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
         "Define maximum size in 10 microsecond increments of the
          reassembly buffer. Some implementations may want allow the
          maximum buffer size to be programmed to a size less than the
          physical limit to reduce the maximum delay through a circuit."
    DEFVAL { 128 } 
    ::= { atmfCESConfEntry 9 }

atmfCESCdvRxT         OBJECT-TYPE
    SYNTAX        INTEGER  (1..65535)
    UNITS         "10 usec"
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The maximum cell arrival jitter in 10 usec increments that 
         the reassembly process will tolerate in the cell stream
         without producing errors on the CBR service interface."
    DEFVAL { 100 } 
    ::= { atmfCESConfEntry 10 }

atmfCESCellLossIntegrationPeriod   OBJECT-TYPE
    SYNTAX        INTEGER  (1000 .. 65535)
    UNITS         "msec"
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The time in milliseconds for the cell loss integration period. 
         If a cells are continuously lost for this period of time,
         atmfCESCellLossStatus is set to loss (2). The
         default definition is 2500."
    DEFVAL { 2500 } 
    ::= { atmfCESConfEntry 11 }

atmfCESConnType              OBJECT-TYPE
    SYNTAX        INTEGER {
                      other(1),
                      pvc(2),
                      activeSvc(3),
                      passiveSvc(4)
                      }
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The type of ATM connectivity between associated CES IWF's.
         Valid values are:
            other      - none of the types specified below
            pvc        - supporting connectivity is a permanent
                         virtual connection
            activeSvc  - attempt calls whenever none established
            passiveSvc - accept calls"
    ::= { atmfCESConfEntry 12 }

atmfCESLocalAddr              OBJECT-TYPE
    SYNTAX        AtmAddr
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The ATM address of the local CES IWF process. This address
         may be used by the automatic SVC establishment procedures to
         identify the intended recipient CES IWF of an incoming automatic
         SVC call request. Optionally, the MAX-ACCESS of this object
         may be read-only, for those implementations where it is
         not desired to manually configure this address."
    ::= { atmfCESConfEntry 13 }

atmfCESAdminStatus           OBJECT-TYPE
    SYNTAX        INTEGER {
                      up(1),
                      down(2)
                      }
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "The desired administrative status of the CES interworking
         function.  The up and down states indicate that the traffic
         flow is enabled or disabled respectively across the CES
         interworking function."
    ::= { atmfCESConfEntry 14 }

atmfCESOperStatus            OBJECT-TYPE
    SYNTAX        INTEGER {
                      up(1),
                      down(2),
                      unknown(3)
                      }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "The operational status of the CES interworking function.
         The up and down states indicate that the traffic flow is
         enabled or disabled respectively across the CES interworking
         function.  The unknown state indicates that the state of the
         CES interworking function cannot be determined.  The state
         will be down or unknown if the supporting CBR or ATM
         interfaces are down or unknown, respectively."
    ::= { atmfCESConfEntry 15 }

atmfCESConfRowStatus         OBJECT-TYPE
    SYNTAX        RowStatus
    MAX-ACCESS    read-create
    STATUS        current
    DESCRIPTION
        "This object is used to create new rows in this table, modify
         existing rows, and to delete existing rows."
    ::= { atmfCESConfEntry 16 }

-- CES Mapping Table

atmfCESMappingTable    OBJECT-TYPE
    SYNTAX        SEQUENCE OF AtmfCESMappingEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "The CES mapping table used to show the mapping from ATM
         VCLs to CBR interfaces or channels.  The mapping and
         interworking functions are configured in the
         atmfCESConfTable."
    ::= { atmfCESObjects 2 }

atmfCESMappingEntry    OBJECT-TYPE
    SYNTAX        AtmfCESMappingEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "An entry in the CES mapping table.  There is one entry
         in the table corresponding to each active row in the
         atmfCESConfTable for which there is a non-zero
         atmfCESAtmIndex."
    INDEX   { atmfCESAtmIndex,
              atmfCESAtmVpi,
              atmfCESAtmVci }
    ::= { atmfCESMappingTable 1 }

AtmfCESMappingEntry ::= SEQUENCE  {
    atmfCESMappingCbrIndex               InterfaceIndex
    }

atmfCESMappingCbrIndex     OBJECT-TYPE
    SYNTAX        InterfaceIndex
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "The value of this object is equal to MIB II's ifIndex value
         of the CBR interface, channel, or bundle that is being
         cross-connected to an ATM VCL.  Examples of the ifType
         value for the CBR entity are ds1(18), ds3(30), ds0(81), or
         ds0bundle(82)."
    ::= { atmfCESMappingEntry 1 }

-- CES Statistics Table

atmfCESStatsTable    OBJECT-TYPE
    SYNTAX        SEQUENCE OF AtmfCESStatsEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "The CES AAL1 statistical data table."
    ::= { atmfCESObjects 3 }

atmfCESStatsEntry    OBJECT-TYPE
    SYNTAX        AtmfCESStatsEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "An entry in the CES AAL1 Stats table.  There is one
         entry in this table corresponding to each entry in the
         atmfCESConfTable."
    AUGMENTS  { atmfCESConfEntry }
    ::= { atmfCESStatsTable 1 }

AtmfCESStatsEntry ::= SEQUENCE  {
    atmfCESReassCells           Counter32,
    atmfCESHdrErrors            Counter32,
    atmfCESPointerReframes      Counter32,
    atmfCESPointerParityErrors  Counter32,
    atmfCESAal1SeqErrors        Counter32,
    atmfCESLostCells            Counter32,
    atmfCESMisinsertedCells     Counter32,
    atmfCESBufUnderflows        Counter32,
    atmfCESBufOverflows         Counter32,
    atmfCESCellLossStatus       INTEGER
    }

atmfCESReassCells         OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This count gives the number of cells played out to the
         CES Service Interface. It excludes cells that were
         discarded for any reason, including cells that were not used
         due to being declared misinserted, or discarded while the
         reassembler was waiting to achieve synchronization."
    ::= { atmfCESStatsEntry 1 }

atmfCESHdrErrors         OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "The count of the number of AAL1 header errors detected,
         including those corrected.  Header errors include correctable
         and uncorrectable CRC, plus bad parity."
    ::= { atmfCESStatsEntry 2 }

atmfCESPointerReframes    OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This records the count of the number of events in which the
         AAL1 reassembler found that an SDT pointer is not where it is
         expected, and the pointer must be reacquired. This count is
         only meaningful for structured CES modes, as unstructured CES
         modes do not use pointers. For unstructured CES modes, this
         count, if present, should indicate zero."
    ::= { atmfCESStatsEntry 3 }

atmfCESPointerParityErrors    OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "This records the count of the number of events in which the
         AAL1 reassembler detects a parity check failure at the point
         where a structured data pointer is expected. This count is only
         meaningful for structured CES modes, as unstructured CES modes
         do not use pointers. For unstructured CES modes, this count, if
         present, should indicate zero."
    ::= { atmfCESStatsEntry 4 }

atmfCESAal1SeqErrors      OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Number of times that the sequence number of an incoming AAL1
         Type 1 SAR-PDU causes a transition from the 'sync' state to
         the 'out of sequence' state, as defined by ITU-T I.363.1."
    ::= { atmfCESStatsEntry 5 }

atmfCESLostCells   OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Number of lost cells, as detected by the AAL1 sequence number
         processing, for example. This records the count of the number
         of cells detected as lost in the network prior to the
         destination CES IWF AAL1 layer processing."
    ::= { atmfCESStatsEntry 6 }

atmfCESMisinsertedCells   OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Number of AAL1 sequence violations which the AAL Convergence
         sublayer interprets as a misinserted cell, as defined by
         ITU-T I.363.1."
    ::= { atmfCESStatsEntry 7 }

atmfCESBufUnderflows      OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Number of buffer underflows. This records the count of the
         number of times the CES reassembly buffer underflows. In the
         case of a continuous underflow caused by a loss of ATM cell
         flow, a single buffer underflow should be counted. If the CES
         IWF is implemented with multiple buffers (such as a cell level
         buffer and a bit level buffer), then either buffer underflow
         will cause this count to be incremented."
    ::= { atmfCESStatsEntry 8 }

atmfCESBufOverflows      OBJECT-TYPE
    SYNTAX        Counter32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Number of buffer overflows. This records the count of the
         number of times the CES reassembly buffer overflows. If the CES
         IWF is implemented with multiple buffers (such as a cell level
         buffer and a bit level buffer, then either buffer overflow will
         cause this count to be incremented "
    ::= { atmfCESStatsEntry 9 }

atmfCESCellLossStatus      OBJECT-TYPE
    SYNTAX        INTEGER {
                     noLoss(1),
                     loss(2)
                     }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "When cells are continuously lost for the number of milliseconds
         specified by atmfCESCellLossIntegrationPeriod, the value is set
         to loss (2). When cells are no longer lost, the value is set 
         to noLoss (1)."
    ::= { atmfCESStatsEntry 10 }

-- CES Active SVC Table

atmfCESActiveSvcTable    OBJECT-TYPE
    SYNTAX        SEQUENCE OF AtmfCESActiveSvcEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "The table used to manage active SVCs established across ATM
         networks between CES entities."
    ::= { atmfCESObjects 4 }

atmfCESActiveSvcEntry    OBJECT-TYPE
    SYNTAX        AtmfCESActiveSvcEntry
    MAX-ACCESS    not-accessible
    STATUS        current
    DESCRIPTION
        "An entry in the CES active SVC table.  There is one
         entry in the table corresponding to each active row in
         the atmfCESConfTable for which the atmfCESConnType takes
         the value 'activeSvc'."
    INDEX   { atmfCESCbrIndex }
    ::= { atmfCESActiveSvcTable 1 }

AtmfCESActiveSvcEntry ::= SEQUENCE  {
    atmfCESRemoteAddr                       AtmAddr,
    atmfCESFirstRetryInterval               INTEGER,
    atmfCESRetryTimer                       INTEGER,
    atmfCESRetryLimit                       INTEGER,
    atmfCESRetryFailures                    Gauge32,
    atmfCESActiveSvcRestart                 INTEGER,
    atmfCESActiveSvcOperStatus              INTEGER,
    atmfCESLastReleaseCause                 INTEGER,
    atmfCESLastReleaseDiagnostics           OCTET STRING
    }

atmfCESRemoteAddr              OBJECT-TYPE
    SYNTAX        AtmAddr
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
        "The ATM address supporting the corresponding far end
         CES IWF process.  If no address is supplied, no attempts
         to establish the active SVC are initiated."
    ::= { atmfCESActiveSvcEntry 1 }

atmfCESFirstRetryInterval       OBJECT-TYPE
    SYNTAX        INTEGER (1..3600)
    UNITS         "seconds"
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
        "The time to wait before attempting to establish the SVC
         after the first failed call attempt.  The time to wait
         between subsequent call attempts may differ to implement
         a backoff scheme.  Zero represents an infinite interval
         indicating no retries."
    DEFVAL { 10 }
    ::= { atmfCESActiveSvcEntry 2 }

atmfCESRetryTimer              OBJECT-TYPE
    SYNTAX        INTEGER (0..86400)
    UNITS         "seconds"
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Indicates the current value of the retry timer for
         this connection.  When the value reaches zero an attempt
         will be made to establish the active SVC.  When the timer
         is not running, the value zero shall be returned."
    ::= { atmfCESActiveSvcEntry 3 }

atmfCESRetryLimit              OBJECT-TYPE
    SYNTAX        INTEGER (0..65535)
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
        "Sets a maximum limit on how many consecutive unsuccessful
         call setup attempts can be made before stopping the attempt
         to set up the connection.  If this limit is reached then
         management action will be required (e.g. setting
         atmfCESActiveSvcRestart to 'restart') to initiate a new
         attempt to establish the connection.  A value of zero
         indicates no limit - the attempts will continue until
         successful. If this object is not present, no limit on call
         attempts is assumed."
    DEFVAL { 0 }
    ::= { atmfCESActiveSvcEntry 4 }

atmfCESRetryFailures           OBJECT-TYPE
    SYNTAX        Gauge32
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Indicates how many attempts to establish the connection
         have failed.  This count is reset whenever a connection
         is successfully established or the active SVC is restarted."
    ::= { atmfCESActiveSvcEntry 5 }

atmfCESActiveSvcRestart        OBJECT-TYPE
    SYNTAX        INTEGER {
                      restart(1),
                      noop(2)
                      }
    MAX-ACCESS    read-write
    STATUS        current
    DESCRIPTION
        "When the value is set to 'restart' the active SVC
         is released if necessary and a new setup procedure
         is begun.  As a result of this action, the
         atmfCESActiveSvcOperStatus object transitions to
         'establishmentInProgress' (if not already in this state)
         and the atmfCESRetryFailures object is cleared.

         When the value is set to 'noop' no operation is
         performed.  When read, the value 'noop' is returned."
    ::= { atmfCESActiveSvcEntry 6 }

atmfCESActiveSvcOperStatus     OBJECT-TYPE
    SYNTAX        INTEGER {
                      other(1),
                      establishmentInProgress(2),
                      connected(3),
                      retriesExhausted(4),
                      noAddressSupplied(5),
                      lowerLayerDown(6)
                      }
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Describes the status of the active SVC.  Valid values are:
            other              - none of the types specified below
            establishmentInProgress - connection is not operational,
                                      but call attempts are ongoing
            connected          - connection is currently operational
            retriesExhausted   - retry limit has been reached and call
                                 attempts have ceased
            noAddressSupplied  - no remote address has been configured,
                                 so no call attempts are initiated
            lowerLayerDown     - underlying CES IWF is not operational

         When the row is not 'active', the value of this object is
         'other'."
    ::= { atmfCESActiveSvcEntry 7 }

atmfCESLastReleaseCause        OBJECT-TYPE
    SYNTAX        INTEGER(1..127)
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Value of the Cause field of the Cause information element
         in the last RELEASE signalling message received for this
         active SVC.  Indicates the reason for the release."
    ::= { atmfCESActiveSvcEntry 8 }

atmfCESLastReleaseDiagnostics  OBJECT-TYPE
    SYNTAX        OCTET STRING (SIZE(0..8))
    MAX-ACCESS    read-only
    STATUS        current
    DESCRIPTION
        "Value of the first 8 bytes of diagnostic information
         from the Cause field of the Cause information element
         in the last RELEASE signalling message received for this
         active SVC."
    ::= { atmfCESActiveSvcEntry 9 }

-- Conformance Information

atmfCESConformance    OBJECT IDENTIFIER ::= { atmfCES 2 }

atmfCESGroups         OBJECT IDENTIFIER ::= { atmfCESConformance 1 }
atmfCESCompliances    OBJECT IDENTIFIER ::= { atmfCESConformance 2 }

-- Compliance Statements

atmfCESCompliance     MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
        "The compliance statement for SNMP entities which support
         the ATM Forum Circuit Emulation Services."

MODULE  -- this module
MANDATORY-GROUPS {
                 atmfCESBasicConfigGroup,
                 atmfCESBasicStatsGroup
                 }

GROUP            atmfCESStructConfigGroup
DESCRIPTION      "This group is mandatory only for IWFs that
                  support Structured DS1, E1 or J2 Nx64 kbit/s
                  Service."

GROUP            atmfCESStructStatsGroup
DESCRIPTION      "This group is mandatory only for IWFs that
                  support Structured DS1, E1 or J2 Nx64 kbit/s
                  Service."

GROUP            atmfCESSvcConfigGroup
DESCRIPTION      "This group is mandatory only when support for
                  automatic SVC initiation procedures is provided."

        OBJECT           atmfCESLocalAddr
        MIN-ACCESS       read-only
        DESCRIPTION      "Support for manual configuration of the local
                          CES interworking function address is not
                          required."

    ::= { atmfCESCompliances 1 }

-- Units of Conformance

atmfCESBasicConfigGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESAtmIndex,
            atmfCESAtmVpi,
            atmfCESAtmVci,
            atmfCESCbrService,
            atmfCESCbrClockMode,
            atmfCESBufMaxSize,
            atmfCESCdvRxT,
            atmfCESCellLossIntegrationPeriod,
            atmfCESConnType,
            atmfCESConfRowStatus
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing configuration information
         for generic Circuit Emulation Service IWFs."
    ::= { atmfCESGroups 1 }

atmfCESOptionalConfigGroup     OBJECT-GROUP
    OBJECTS {
            atmfCESAdminStatus,
            atmfCESOperStatus
            }
    STATUS  current
    DESCRIPTION
        "A collection of optional objects providing configuration
         information for generic Circuit Emulation Service IWFs."
    ::= { atmfCESGroups 2}

atmfCESBasicStatsGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESReassCells,
            atmfCESHdrErrors,
            atmfCESBufUnderflows,
            atmfCESBufOverflows,
            atmfCESCellLossStatus
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing statistics information
         for generic Circuit Emulation Service IWFs."
    ::= { atmfCESGroups 3 }

atmfCESOptionalStatsGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESAal1SeqErrors,
            atmfCESLostCells,
            atmfCESMisinsertedCells
            }
    STATUS  current
    DESCRIPTION
        "A collection of optional objects providing statistics
         information for generic Circuit Emulation Service IWFs."
    ::= { atmfCESGroups 4 }

atmfCESStructConfigGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESCas,
            atmfCESPartialFill
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing configuration information
         for Structured DS1, E1 or J2 Nx64 kbit/s Service IWFs."
    ::= { atmfCESGroups 5 }

atmfCESStructStatsGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESPointerReframes
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing statistics information
         for Structured DS1, E1 or J2 Nx64 kbit/s Service IWFs."
    ::= { atmfCESGroups 6 }

atmfCESOptionalStructStatsGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESPointerParityErrors
            }
    STATUS  current
    DESCRIPTION
        "A collection of optional objects providing statistics
         information for Structured DS1, E1 or J2 Nx64 kbit/s Service
         IWFs."
    ::= { atmfCESGroups 7 }

atmfCESMappingGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESMappingCbrIndex
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing information about the
         mapping from ATM VCLs to CBR interfaces or channels."
    ::= { atmfCESGroups 8 }

atmfCESSvcConfigGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESLocalAddr,
            atmfCESRemoteAddr,
            atmfCESFirstRetryInterval,
            atmfCESRetryTimer,
            atmfCESRetryFailures,
            atmfCESActiveSvcRestart,
            atmfCESActiveSvcOperStatus
            }
    STATUS  current
    DESCRIPTION
        "A collection of objects providing SVC connection
         establishment support configuration information for CES
         IWFs."
    ::= { atmfCESGroups 9 }

atmfCESOptionalSvcConfigGroup    OBJECT-GROUP
    OBJECTS {
            atmfCESRetryLimit,
            atmfCESLastReleaseCause,
            atmfCESLastReleaseDiagnostics
            }
    STATUS  current
    DESCRIPTION
        "A collection of optional objects providing SVC connection
         establishment support configuration information for CES
         IWFs."
    ::= { atmfCESGroups 10 }

END

Annex A:  Impairment Analysis
This annex addresses the mapping into Circuit Emulation Service impairments—errored seconds (ES) and severely errored seconds (SES)—from the cell loss ratio (CLR) and the cell error rate (CER) impairments of the underlying ATM transport. It complements the broader, more qualitative discussion in the (informative) Annex B, “Relationship between ATM Layer Network Performance and the Network Performance of AAL Type 1 for CBR Services”, of T1.511-1994, “B-ISDN ATM Layer Cell Transfer - Performance Parameters”
It is difficult to set requirements on these impairments and other impairments such as cell transfer delay (CTD) and cell delay variation (CDV), since they are application specific; and in some cases, particularly CDV, still being studied. Furthermore, the requirements could be equipment dependent. For example, the addition of error control to equipment would decrease requirements on the ATM transport facility.
For DS1 and fractional DS1, there are some requirements in ANSI T1.510 for SES and ES. When voice was the predominate application, one could, assuming no error control, derive some reasonable requirements for BER since an end-to-end PCM-encoded voice signal would tolerate a 10-6 BER in the TDM circuit.(Source: SR-TSV-00275, Iss. 1, March 1991).
The following discussion of ES and SES assumes an absence of error control on the cell information field and that lost cells are replaced with a random bit pattern.
A.1  Errored Second
An ES is a one-second interval with one or more bit errors. Each Nx64 kbit/s and 1.544 Mbit/ s channel requires that, over 30 or more consecutive days, fewer than 0.20% and 0.50%, respectively, of the seconds are errored seconds. (Source: ANSI T1.510‑1994)
Since 64 kbit/s and even 1.544 Mbit/s channels are likely a small proportion of the underlying ATM transport capacity, then the burstiness of ATM‑related binary errors and cell loss should be dispersed in time at both the 64 kbit/s and the 1.544 Mbit/s channel levels. Therefore, the worst case approach of random errors and cell loss may be reasonable. If so, then, ignoring the small (2-376) probability that a cell loss will cause no binary errors:
For a 64 kbit/s channel (which utilizes 170.21 cell/s), an ES less than 0.20% (or 1 in 500) of the seconds implies that CER + CLR < 1.175 x 10-5;
For an Nx64 kbit/s channel (which utilizes Nx170.21 cell/s, 2 £ N £ 24), an ES less than 0.20% (or 1 in 500) of the seconds implies that CER + CLR < 1.175 x 10-5 /N;
For a 2.048 Mbit/s channel (which utilizes 5,447 cell/s) an ES less than 0.50% (or 1 in 200) of the seconds implies that CER + CLR < 9.18 x 10-7.
These ATM performance parameters map into DS1 Bit Error Rate (BER), Errored Second (ES) and Severely Errored Second (SES) values:
Cell Error Ratio (CER) - an errored bit in a cell payload is likely to result in an error in the emulated circuit, causing an Errored Second.
Cell Loss Ratio (CLR) - a lost cell will result in an average of 188 errored bits in the emulated circuit. A single lost cell will result in a Severely Errored Second for Nx64 services where N is one or two.
Cell Misinsertion Rate (CMR) - undetected, misinserted cells will also cause Severely Errored Seconds for Nx64 circuits where N is one or two.
We summarize the mapping outlined above in Table A-1.

Service	Performance
Target	ATM
Objective	
unstructured DS1	ES < 0.5%	CLR+CER < 1.22x10-6	
unstructured E1	ES < 0.5%	CLR+CER < 9.18x10-7	
64 kbit/s	ES < 0.2%	CLR+CER < 1.175x10-5	
Table A-1:  ATM VC Mapping

Annex B  Abbreviations
Acronyms and abbreviations in CES baseline document:

AAL - ATM Adaptation Layer
AAL1 - ATM Adaptation Layer Type 1
AIS - Alarm Indication Signal
AMI - Alternate Mark Inversion
ANSI - American National Standards Institute
ATM - Asynchronous Transfer Mode
AUU - ATM-Layer-User to ATM-Layer-User
B-HLI - Broadband High Layer Information
B-LLI - Broadband Low Layer Information
B-ICI - Broadband Intercarrier Interface
B-ISDN - Broadband Integrated Services Digital Network
B8ZS - Bipolar with 8 Zero Substitution
BER - Bit Error Ratio
BITS - Building Integrated Timing System
CAS - Channel Associated Signalling
CBR - Constant Bit Rate
CDV - Cell Delay Variation
CE - Congestion Experienced
CER - Cell Error Ratio
CES - Circuit Emulation Service
CES-IS - Circuit Emulation Service Interoperability Specification
CLP - Cell Loss Priority
CLR - Cell Loss Ratio
CMR - Cell Misinsertion Ratio
CO - Central Office
CRC - Cyclic Redundancy Check
CTD - Cell Transfer Delay
DS0 - Digital Signal level 0 (64 kbit/s)
DS1 - Digital Signal level 1 (1544 kbit/s)
DS3 - Digital Signal level 3 (44736 kbit/s)
DSX1 - Digital Signal Cross(X)connect level 1
E1 - special digital trunk, European (2048 kbit/s)
E3 - Special Digital Trunk, European (34.368 Mbit/s)
ES - Errored Second
ESF - Extended Super Frame
FDL - Facility Data Link
HDB3 - High-Density Binary Three
IE - Information Element
IEC - International Electrotechnical Commission
IETF - Internet Engineering Task Force
ILMI - Interim Local Management Interface
ISDN - Integrated Services Digital Network
ISO - International Organization for Standardization
IWF - Inter-Working Function
J2 - Japanese standard for 6.312 Mbit/s electrical PDH transmission (Note: this J2 acronym is used by the ATM Forum for this service. The Japanese TTC does not use the J2 acronym.)
kbit/s - thousand bits per second
LOS - Loss of Signal
Mbit/s - million bits per second
MIB - Management Information Base
ms - milliseconds
msec - microsecond
N-ISDN - Narrowband Integrated Services Digital Network
NNI - Network to Network Interface
OAM - Operations And Maintenance
OC3 - Optical Carrier level 3 (155.52 Mbit/s)
OUI - Organizational Unit Identifier
PBX - Private Branch eXchange
PCM - Pulse Code Modulation
PCR - Peak Cell Rate
PDH - Plesiochronous Digital Hierarchy
PLCP - Physical Layer Convergence Protocol
POTS - Plain Old Telephone Service
ppm - parts per million
PRS - Primary Reference Source
QoS - Quality of Service
RAI - Remote Alarm Indication
RFC - Request for Comment
SAA - Service Aspects and Applications
SDH - Synchronous Digital Hierarchy
SDT - Structured Data Transfer
SDU - Service Data Unit
SES - Severely Errored Second
SF - Super Frame
SNAP - Sub-Network Access Protocol
SNMP - Simple Network Management Protocol
SONET - Synchronous Optical NETwork
SRTS - Synchronous Residual Time Stamp
SVC - Switched virtual circuit
TDM - Time Division Multiplex
UDT - Unstructured Data Transfer
UI - Unit Interval
UNI - User to Network Interface
UPC - Usage Parameter Control
VC - Virtual Channel
VCC - Virtual Channel Connection