Technical Committee

Frame based User-to-Network Interface (FUNI) Specifications

af-saa-0031.000

September, 1995

(C)  1995 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 any 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:
• 	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
• 	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
• 	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 by 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.

Table of Contents
1.	Scope	1
2.	Reference Model	1
3.	Data Link Layer Protocol	3
	3.1	Mode 1a		3
	3.2	Mode 1b		7
4.	Physical Layer	11
5.	Management Interface	12
	5.1	Management Information Base (MIB)	12
	5.2	Management Frame Format	12
6.	Traffic Parameters	14
7.	References	14

Table of Figures

Figure 2.1	Reference Model for FUNI	2
Figure 2.2.a	Example of Multiplexing/Grooming of a DS-1 FUNI	2
Figure 2.2.b	Example of Multiplexing/Grooming of a Fractional DS-1 FUNI	2
Figure 3.1	Encapsulation/Decapsulation and ATM Conversion Process 	5
		for AAL5
Figure 3.2	Modes 1a (and 1b) Data Link Layer Frame Details	6
Figure 3.3	Mapping Between Frame Address (FA) and VPI/VCI Fields	7
Figure 3.4	Illustration of the AAL3/4 User SDU and FUNI_PDU 	9
		(AAL3/4_PDU)
Figure 3.5	Encapsulation/Decapsulation and ATM Conversion Process 	10
		for AAL3/4
Figure 5.1	Cell-to-Frame Mapping of Management Cells	13

1.0	Scope
This document defines a Frame based User-to-Network Interface at speeds of up to 2.048 Mbps and is based on the Asynchronous Transfer Mode Data eXchange Interface (ATM DXI).  Throughout the rest of this document the original interface will be referred to as the "ADXI" interface while this document's subject interface will be referred to as the "FUNI."
This document fully defines/specifies the FUNI.  Where this interface is the same as the original ADXI, the specification is covered by referring to the appropriate section in the ADXI document.  Where the two interfaces differ, this document contains the full specification of the FUNI.
The FUNI is capable of transparently supporting Service Specific Convergence Sublayers (SSCS) and other higher layers.  However, the use and support of SSCSs is beyond the scope of this document.  The only ATM adaptation layers supported on this interface are AAL5 and AAL3/4.
The FUNI is capable of supporting the basic ATM UNI functions (per ATM UNI 3.1) such as VPI/VCI multiplexing, signaling, network management, traffic policing, and, optionally, OAM functions.  The support of some of these functions may be limited in comparison to the full functionality of an ATM UNI.  This interface is intended to support only VBR and UBR service classes.

In the following text (R) and Shall indicate a requirement that must be implemented to meet this specification.  (0) is an Option that may be implemented.  (CR) is a Conditional Requirement which must be implemented if the particular option, to which it is related, is implemented.

2.0	Reference Model
Figure 2.1 depicts the functional reference model of the FUNI specified in this document.  The user's FUNI payload carried in the DS-1/E1 physical layer may be the full or a fraction thereof the DS-1/E1 line bandwidth.  When the payload is a fractional DS-1/E1 bandwidth, i.e., Nx64 Kbps where N is less than 24 for DS-1 and less than 31 for E1, it is still treated as a single payload.  This means that all of the Nx64 time slots will be treated as concatenated bandwidth and not separate DS-0 channels.  It should be noted that this interface enables its users to communicate with users employing the same type of interface or a native ATM interface as shown in Figure 2.1 on the right hand side of the diagram.
The connection between a user and the network may be a logical connection which is part of a higher bandwidth physical connection.  Figure 2.2 shows two examples:  example (a) represents a full DS-1 FUNI payload carried in a DS-3 physical connection; and example (b) represents a fractional DS-1 FUNI payload carried in a DS-1 physical connection.  The latter example represents a particularly useful configuration for users who wish to carry payloads other than the FUNI, e.g., voice, in the same DS-1 physical connection to the (carrier) network.  As seen from the diagrams, the FUNI is always groomed to a DS-1 interface into the ATM device supporting the interface.  Other payloads are groomed to the appropriate network element(s).  Although the multiplexing and demultiplexing/grooming methods are beyond the scope of this document, it should be noted that employing traditional TDM technology and standards is the predominant method of achieving this function.

Figure 2.1   Reference Model for the FUNI

Figure 2.2a   Example of Multiplexing/Grooming a DS-1 FUNI

Figure 2.2b   Example of Multiplexing/Grooming a Fractional DS1 FUNI
3.0	DATA LINK LAYER PROTOCOL

For the specific modes of operation which are supported by the FUNI, indicated below, the Data Link Protocol of this interface is identical to that of the corresponding original ADXI interface.  Note that in all modes of operation, for all VPI values, VCI values 0 to 31 (32 values) are reserved by ITU and must not be used for user data on this interface or the ADXI.

(R)	The FUNI Shall  support Mode 1a as specified in Section 2.3.2 of the ADXI specification document [1].  
(O)	Support of Mode 1b as specified in Section 2.3.2.2 of the ADXI specification document is optional.  
(R)	The FUNI Shall  Not  support Mode 2 specified in Section 2.3.3 of the ADXI specification document.

Following is a summary of the above stated modes.

3.1	Mode 1a
Following are the FUNI Requirements of this mode
Number of Virtual Connections per FUNI
(R)	Each FUNI Shall  support up to 15 Virtual Path Connections (16 VPI values minus the zero VPI); and up to 256 Virtual Channel Connections using  combinations of the 16 VPI values and the 32 available VCI values (32 of the total 64 values are reserved, see note in 3.0 above).  
(O)	Supporting a number of connections higher than 256 is optional.  
(CR)	When the above option is implemented, the implementer Shall  declare the number of connections supported and the user of the option Shall  notify the network operator at time of subscription.
Adaptation Layer
(R)	Shall  support AAL5 Only
User Service Data Unit (SDU) Size
(R)	Shall  support up to 4096 Octets of User SDU.  
(O)	User SDUs larger than 4096, and up to 64K Octets may be supported.  This option is consistent with the adaptation layer CPCS maximum length specified in the ITU recommendations.  
(CR)	When the above option is implemented, the implementer Shall  declare the maximum user SDU size supported by his equipment and the user of this option Shall  notify the network operator of the SDU size used at time of subscription.

CRC Size
(R)	Shall  implement 16 Bit CRC per ITU Q.921 in the FCS field (see Figure 3.2 below).  
(O)	32 bit CRC may be implemented.  
(CR)	When the above option is implemented, the implementer Shall  declare that it is supported and the user Shall  notify the network operator at time of subscription.
Note that SDUs larger than 4096 Octets may require 32 bit CRC for adequate error detection
Note the following differences from the ADXI.
The maximum required number of VCCs is 256 (less than the 1023 stated in the ADXI).  This meets the public network DS-1 UNI requirements stated in Bellcore's TA-NWT-001110, Broadband ISDN Switching System Generic Requirements, Issue 2, August, 1993.
The maximum required SDU size here is lower than the ADXI's (9232).
The following diagram, Figure 3.1, represents the encapsulation/decapsulation process of user SDU across the FUNI interface as well as the ATM conversion function performed in the ATM network interface device.

FH = FUNI Frame Header	FT = FUNI/HDLC Frame Trailer	Note HDLC Flags are not shown
CPCS = Common Part Convergence Sublayer	CH = Cell Header

Figure 3.1	Encapsulation/Decapsulation and ATM Conversion Process 	for AAL5   (Physical Layer is Not Shown in This Diagram)

The following diagram, Figure 3.2, illustrates the Frame structure across the FUNI and the specifics of Frame Header to Cell Header mapping.

RSVD	Reserved for interface management.  These bits are set to 0 unless the frame is used for management per Section 5.2 below.
FA	Frame Address:  Octet 1, bit 6 through bit 3 are mapped to the 4 LSBs of the VPI in the cell header.  The four MSBs of the VPI are not coded in the FA field, and are set to zero by the Network Equipment on send and ignored on receive.  Octet 1, bit 8 and bit 7, and Octet 2, bit 8 through bit 5, are mapped to the six LSBs of the VCI in the cell header.  The ten MSBs of the VCI are not coded in the FA field, and are set to zero by the Network Equipment on send and ignored on receive. The all 0s FA is not mapped into the corresponding VPI/VCI which must be used in the ATM conversion function according to the UNI standards.  Figure 3.3 shows the bit-to-bit mapping between the FA and VPI/VCI values.
FCS	16 bit FCS (Frame Check Sequence) is shown.  The FCS contains 16 bit CRC which meets ITU Q.921 requirements.  (Note that SDUs larger than 4096 Octets may require 32 bit CRC for adequate error detection).
CN	If PTI = 01x in the last ATM cell composing the FUNI frame, then the Network Equipment sets CN (Congestion Notification) equal to one for that FUNI frame, otherwise the Network Equipment sets CN equal to zero.  The User Equipment always sets the CN to zero.
CLP	The Network Equipment copies the CLP Bit sent from the User Equipment into the CLP bit of all ATM cell headers constituting the FUNI frame.  The CLP bit from the Network Equipment to the User Equipment is always set to zero.
Bit/Octet Order:	The left most bit of the octet (i.e.,  bit 8) is the Most Significant Bit (MSB).  In diagrams 	with multiple octets the left most bit in the top-most octet is the MSB.  These bits are 	transmitted right to left, top to bottom.
Figure 3.2  Modes 1a (and 1b) Data Link Frame Details
The following diagram, Figure 3.3, depicts the bit location mapping between a Frame Address and the corresponding VPI/VCI value in the cell headers corresponding to that frame.

Figure 3.3   Mapping Between the Frame Address (FA) and VPI/VCI Fields

For further text details, see Section 2.3.2 of the ADXI document.

3.2	Mode 1b
The implementation of this mode is Optional .  When implemented, it supports AAL5, as in Mode 1a, plus AAL3/4.  AAL5 is supported as explained in the last section (Section 3.1).  AAL3/4 is supported as explained below.

Number of Virtual Connections per FUNI
(CR)	Each FUNI Shall  support up to 15 Virtual Path Connections (16 VPI values minus the zero VPI); and up to 256 Virtual Channel Connections using  combinations of the 16 VPI values and the 32 available VCI values (32 of the total 64 values are reserved, see note in 3.0 above).  
(O)	Supporting a number of connections higher than 256 is optional.  
(CR)	When the above option is implemented, the implementer Shall  declare the number of connections supported and the user of the option Shall  notify the network operator at time of subscription.
Adaptation Layer
(CR)	Each virtual connection Shall  support either AAL5 or AAL3/4 on a per connection basis.
User SDU Size
(CR)	Shall  support up to 4096 Octets of User SDU.  
•	For AAL5 connections, this entire field (user SDU) is available for user information payload.
•	For AAL3/4 connections, 8 Octets of this field are dedicated to the AAL3/4 CPCS Header and Trailer and the remaining User SDU Octets are available for user information payload (see Figure 3.4 below)
Note that the term user information payload refers to all user information including upper layer encapsulations, it only excludes encapsulation related to AAL3/4 CPCS which is a part of the user SDU as shown in Figure 3.4.  In this diagram, the user SDU is equal to the AAL3/4 CPCS_PDU as defined in ITU recommendation I.364.

(O)	User SDUs larger than 4096, and up to 64K Octets may be supported.  This option is consistent with the adaptation layer CPCS maximum length specified in the ITU recommendations.  
(CR)	When the above option is implemented, the implementer Shall  declare the maximum user SDU size supported by his equipment and the user of this option Shall  notify the network operator of the SDU size used at time of subscription.
CRC Size
(CR)	Shall  implement 16 Bit CRC per ITU Q.921 in the FCS field.
(O)	32 bit CRC may be implemented.  
(CR)	When the above option is implemented, the implementer Shall  declare that it is supported and the user Shall  notify the network operator at time of subscription.
Note that SDUs larger than 4096 Octets may require 32 bit CRC for adequate error detection

Figure 3.4	Illustration of the AAL3/4 User SDU and FUNI PDU (AAL3/4 CPCS_PDU)

Mapping of Frames-to-Cells in this mode (Mode 1b) is identical to that shown in Figures 3.2 and 3.3 above, regardless of the AAL type.  The only difference between this mode and Mode 1a is in the fact that some VPCs/VCCs are associated with an AAL5 SAR process while others are associated with AAL3/4 SAR process.  The procedure of associating a particular virtual connection with a particular AAL is implementation specific and is beyond the scope of this specification.  The following diagram, Figure 3.5, illustrates the process of encapsulation/decapsulation of user SDU and ATM conversion function for AAL3/4.  The process for AAL5 is identical to Mode 1a illustrated in Figure 3.1 above.

FH = FUNI Frame Header	FT = FUNI/HDLC Frame Trailer	Note HDLC Flags are not shown
AH = AAL3/4 CPCS Header	AT = AAL3/4 CPCS Trailer
SH = SAR Header	ST = SAR Trailer
CH = Cell Header

Figure 3.5	Encapsulation/Decapsulation and ATM Conversion Process for AAL3/4

4.0	PHYSICAL LAYER
There are two physical layers that may be used in supporting this interface:  DS-1 or E1.
When the DS-1 physical layer is used it must meet the following requirement.
(R)	The DS-1 Physical Layer Shall  meet all applicable requirements in the ANSI T1-403 and ANSI T1-408 specifications[2], [3] as stated in Sections 2.7.1 (Physical Medium Dependent Characteristic) and 2.7.2 (Transport Signal Format) of the ATM Forum DS-1 Physical Layer Specifications, Version 1.0[4], with the exception of Section 2.7.1.2 (ATM Transfer Rate).
When the E1 physical layer is used, it has two potential framing modes: Structured and Unstructured.  The Structured mode meets ITU's recommendation G.704 framing requirements and G.703 electrical interface requirements.  The Unstructured mode meets only G.703 electrical interface requirements and does not  meet G.704 framing requirements, i.e., it is just a stream of serial bits.  Following are the requirements of the E1 physical layer.
(R)	The E1 Structured Physical Layer Shall  be implemented and Shall  meet all applicable requirements in the following ITU documents:
	G.703-1991	Physical/Electrical Characteristics of Hierarchical Digital 	Interfaces
	G.704-1991	Synchronous Frame Structures Used at Primary and 	Secondary Hierarchical Levels
	G.709-1993	Synchronous Multiplexing Structure
(O)	In addition to the structured E1 physical layer, the Unstructured E1 Physical layer May  be implemented.
(CR)	When Unstructured E1 physical layer is implemented, it Shall  meet G.703 electrical interface requirements and the implementer Shall  declare that his equipment supports this mode.  
(CR)	Subscribers using the Unstructured E1 mode Shall  notify network operator at time of subscription.

It should be emphasized that an Nx64 Kbps payload is carried as a single concatenated payload of N time slots in the DS-1 or E1 frame.  The time slots need not be contiguous.  Supporting more than one Nx64 Kbps FUNI, or multiplexing with other types of interfaces, on one physical DS-1/E1 interface is an optional implementation (represented in Figure 2.2b above) and is beyond the scope of this document.

5.0	MANAGEMENT INTERFACE

5.1	Management Information Base (MIB)

(R)	MIBs in devices implementing this interface Shall  utilize SNMP standards.
(R)	The Management entities on both the interface sides (network and user) Shall  support the physical layer management requirements by implementing IETF RFC 1406-1993:  "Definitions of the Managed Objects for the DS1 and E1 Interface Types."[5]
It should be noted that the DS-1 FDL may be terminated at a point which is different than that of the FUNI termination.  An example of this case is the fractional DS-1 example illustrated in Figure 2.2b above, where the FDL is terminated at the (left hand side) DeMux while the actual FUNI continues through the DeMux to the network element processing the FUNI.  It should, also, be understood that the FUNI is a single instance of RFC 1406 implementation with a single DS-1 (or E1) or a single fractional DS-1/E1 table (multiple fractional tables are not allowed in a single 1406 instance).  This is consistent with the fact that the FUNI is a single channel connection as stated in the reference model in Section 2 above.  
(R)	The Management entities on both the interface sides (network and user) Shall  support the "System Group" as defined in RFC 1213 and the ATMF UNI 3.0[6] Section 4.5.
(R)	The management entity in the network device performing the ATM conversion function (shown in Figure 2.1) Shall  support the "Address Registration Group" of the ILMI MIB in ATMF UNI 3.1[7] specifications, section 5.8.  ILMI Protocol, as specified in ATMF UNI 3.1, Shall  be used to support this requirement.
(O)	The remaining groups of the ILMI are optional to support.
(O)	Supporting the ATM MIB specified in the IETF RFC 1695[8] is optional.

5.2	Management Frame Format

(O)	Supporting the transfer of OAM cells (in frame format) across this interface is Optional.  
(CR)	If the above option is implemented, enabling and disabling it Shall  be configurable per Virtual Connection.  When this option is implemented, the interface Shall support OAM cells for fault management and connection verification per ATM Forum UNI 3.1.  Support of OAM cells for performance management is not required.
(CR)	When the option of OAM cell transfer across the FUNI is exercised the following rules apply; and the following code points Shall be used to support conversion of OAM cells to frames, and vice versa, across this interface.  
	The reserved bits, i.e., bit 2 of octet 1 and bit 3 of octet 2, in the Frame Header (Figure 3.2 above) are used to identify the type of information contained in the Frame as follows.

	Bit 2 of Octet 1	Bit 3 of Octet 2	Type of Frame
	0	0	User Information (Data)
	0	1	Reserved
	1	0	OAM
	1	1	Reserved

	Mapping between management cells and frames Shall Not  include the AAL5 CPCS, it Shall  be performed by mapping the cell payload into a frame payload (and vice versa) plus mapping the cell header to frame header (and vice versa) using the same header mapping procedures explained in Section 3.1 and Figure 3.2 above.  Figure 5.1 below illustrates the mapping process intended for management cell-to-frame exchange in this section.  

Figure 5.1   Cell-to-Frame Mapping of Management Cells

It should be noted that this process is only applicable to mapping ATM management cells to frames.  Communicating SNMP packets across this interface (encapsulated in some upper layer protocol such as IP) follows the same process and procedures as user data.  The difference is that the virtual connections carrying SNMP information may be different than the virtual connections carrying user data.  The specific means by which the two types of information are actually distinguished is implementation specific and beyond the scope of this document.

6.0	TRAFFIC parameters

(R)	Although the FUNI is a frame based interface, Traffic Parameters that apply to the FUNI (e.g., PCR, SCR and BT) Shall  be expressed in the same units, using the same syntax, as in ATM Forum UNI 3.1[7] specifications.

7.0	REFERENCES
[1]	ATM Forum, ATM Data eXchange Interface (DXI) Specification, Version 1.0, August , 1993.
[2]	ANSI T1.403-1989, Carrier-to-Customer DS-1 Installation Metallic Interface.
[3]	ANSI T1.408-1990, ISDN Primary Rate - Customer Installation Metallic Interfaces Layer 1 Specifications.
[4]	ATM Forum DS-1 Physical Layer Specifications, Version 1.0, 1994
[5]	IETF RFC 1406, Definitions of the Managed Objects for the DS1 and E1 Interface Types, 1993
[6]	ATM Forum User-Network Interface Specifications, Version 3.0, 1994
[7]	ATM Forum User-Network Interface Specifications, Version 3.1, 1994
[8]	IETF RFC 1695, Definition of Managed Objects for ATM Management Using SMPv2, Version 8.0, August, 1994.

END of FUNI Document