Technical Committee


Network Call Correlation Identifier v1.0

AF-CS-0140.000

March, 2000
(c) 2000 by The ATM Forum.  This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution.  Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution.  All other rights reserved.  Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum.
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.
NOTE:  The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require 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, Suite 304
Mountain View, CA 94040-1313
Tel:	+1-650-949-6700
Fax:	+1-650-949-6705

Acknowledgments
The Control and Signaling working group was chaired by Malcolm Wiles and his successor Gert Oster. Laurent FrelŽchoux was the editor for the Network Call Correlation Identifier v1.0 addendum to PNNI v1.0 and AINI specification. Tricci So was the editor for the Addendum to UNI Signalling 4.0 for Network Call Correlation Identifier specification. The minutes at related working group meetings were recorded by Gert Oster and his successor Thomas CornŽly.
The following people made significant technical contributions to the Network Call Correlation Identifier v1.0 specification:
Thomas CornŽly
Robert Dianda
Laurent FrelŽchoux
Shawn McAllister
Gert Oster
Tricci So
Mickey Spiegel
Malcolm Wiles









Table of contents
1.	GENERAL INFORMATION	7
1.1	SCOPE	7
1.2	OVERVIEW	9
1.2.1	Network view	9
1.2.2	Nodal view	9
1.2.3	Modeling Considerations	9
2.	NETWORK CALL CORRELATION IDENTIFIER INFORMATION ELEMENT CODING	11
3.	NCCI FEATURE FOR PNNI	13
3.1	ADDITIONS TO PNNI SIGNALING MESSAGES	13
3.1.1	SETUP	13
3.1.2	ADD PARTY	13
3.1.3	CO-BI SETUP	13
3.2	NCCI PROCEDURES FOR PNNI	14
3.2.1	Procedures for Point-to-Point calls	14
3.2.2	Procedures for Point-to-Multipoint calls	14
3.2.3	NCCI information element content validation	15
3.2.4	Storing the NCCI	15
4.	NCCI FEATURE FOR AINI	15
4.1	ADDITIONS TO AINI SIGNALING MESSAGES	15
4.1.1	CONNECT	15
4.1.2	CO-BI SETUP	15
4.2	NCCI PROCEDURES FOR AINI	15
4.2.1	Procedures for Point-to-Point calls	15
4.2.2	Procedures for Point-to-Multipoint calls	16
4.2.3	Storing the NCCI	17
4.2.4	Interworking between AINI and B-ISUP	17
5.	NCCI FEATURE FOR UNI	18
5.1	ADDITIONS TO UNI SIGNALING MESSAGES	18
5.1.1	SETUP	19
5.1.2	ADD PARTY	19
5.1.3	CONNECT	19
5.2	NCCI PROCEDURES FOR UNI	19
5.2.1	Procedures for Point-to-point calls	19
5.2.2	Procedures for Point-to-Multipoint calls	20
5.2.3	Storing the NCCI	21
6.	INTERACTION WITH EXISTING FEATURES	21
6.1	INTERACTION WITH SOFT PVCS.	21
7.	COMPATIBILITY WITH NODES NOT SUPPORTING THIS FEATURE	21
8.	REFERENCES	21
ANNNEX A.	NCCI SNMP MIB	22
ANNNEX B.		NCCI PICS PROFORMA FOR PNNI V1.0	35
B.1	INTRODUCTION	35
B.1.1	Scope	35
B.1.2	Normative References	35
B.1.3	Definitions	35
B.1.4	Acronyms	35
B.1.5	Conformance	36
B.2	IDENTIFICATION OF THE IMPLEMENTATION	37
B.3	PICS PROFORMA	39
B.3.1	Global statement of conformance	39
B.3.2	Instructions for Completing the PICS Proforma	39
B.4	ROLES	40
B.5	NCCI ENCODING	40
B.6	NCCI CAPABILITIES FOR POINT-TO-POINT CALLS	44
B.7	NCCI PROCEDURES FOR POINT-TO-POINT CALLS	44
B.8	NCCI CAPABILITIES FOR POINT-TO-MULTIPOINT CALLS	46
B.9	NCCI PROCEDURES FOR POINT-TO-MULTIPOINT CALLS	46
ANNNEX C.	NCCI PICS PROFORMA FOR AINI V1.0	48
C.1	INTRODUCTION	48
C.1.1	Scope	48
C.1.2	Normative References	48
C.1.3	Definitions	48
C.1.4	Acronyms	48
C.1.5	Conformance	49
C.2	IDENTIFICATION OF THE IMPLEMENTATION	50
C.3	PICS PROFORMA	52
C.3.1	Global statement of conformance	52
C.3.2	Instructions for Completing the PICS Proforma	52
C.4	ROLES	53
C.5	NCCI ENCODING	53
C.6	NCCI CAPABILITIES FOR POINT-TO-POINT CALLS	57
C.7	NCCI PROCEDURES FOR POINT-TO-POINT CALLS	61
C.8	NCCI CAPABILITIES FOR POINT-TO-MULTIPOINT CALLS	62
C.9	NCCI PROCEDURES FOR POINT-TO-MULTIPOINT CALLS	62
ANNNEX D.	NCCI PICS PROFORMA FOR UNI V4.0	62
D.1	INTRODUCTION	62
D.1.1	Scope	62
D.1.2	Normative References	62
D.1.3	Definitions	62
D.1.4	Acronyms	62
D.1.5	Conformance	62
D.2	IDENTIFICATION OF THE IMPLEMENTATION	62
D.3	PICS PROFORMA	62
D.3.1	Global statement of conformance	62
D.3.2	Instructions for Completing the PICS Proforma	62
D.4	ROLES	62
D.5	NCCI ENCODING	62
D.6	NCCI CAPABILITIES FOR POINT-TO-POINT CALLS AT THE USER SIDE	62
D.7	NCCI PROCEDURES FOR POINT-TO-POINT CALLS AT THE USER SIDE	62
D.8	NCCI CAPABILITIES FOR POINT-TO-MULTIPOINT CALLS AT THE USER SIDE	62
D.9	NCCI PROCEDURES FOR POINT-TO-MULTIPOINT CALLS AT THE USER SIDE	62
D.10	NCCI CAPABILITIES FOR POINT-TO-POINT CALLS AT THE NETWORK SIDE	62
D.11	NCCI PROCEDURES FOR POINT-TO-POINT CALLS AT THE NETWORK SIDE	62
D.12	NCCI CAPABILITIES FOR POINT-TO-MULTIPOINT CALLS AT THE NETWORK SIDE	62
D.13	NCCI PROCEDURES FOR POINT-TO-MULTIPOINT CALLS AT THE NETWORK SIDE	62
APPENDIX A.	B-ISUP NCCI FORMAT	62
APPENDIX B.	EXAMPLE OF NCCIS CORRELATION BETWEEN PRIVATE AND ATM SERVICE PROVIDER NETWORKS	62
Table of figures/tables
Figure 1-1 Primitives used in the NCCI procedures	10
Figure 2-1 Network call correlation identifier information element	11
Figure 2-2 Format of a AESA-based Network Call Correlation Identifier (28 octets)	12
Table 3-1 Additional information element used in PNNI	13
Figure 3-1 Additional SETUP message content	13
Figure 3-2 Additional ADD PARTY message content	13
Figure 3-3 Additional CO-BI SETUP message content	14
Figure 4-1 Additional CONNECT message content	15
Table 4-1 Additional SETUP to IAM mapping	17
Table 4-2 Additional IAM to SETUP mapping	18
Table 4-3 Additional ADD PARTY to IAM mapping	18
Table 4-4 Additional IAM to ADD PARTY mapping	18
Table 4-5 Additional CONNECT to ANM mapping	18
Table 5-1: Additional Information Element for UNI Signalling 4.0	19
Table 5-2: Additional Information Element for UNI SETUP message	19
Table 5-3: Additional Information Element for UNI ADD PARTY message	19
Table 5-4: Additional Information Element for UNI CONNECT message	19
Figure A-1 Format of a B-ISUP Network Call Correlation Identifier (9 octets)	62
Figure B-1 Example of the networks interconnection when transporting NCCIs	62

This Addendum to ATM Forum PNNI v1.0 "Private Network-Network Interface Specification Version 1.0" [1], to ATM Forum "PNNI v1.0 Errata and PICS" [2], to ATM Forum "ATM Inter-Network Interface (AINI) Specifications" [3], and to ATM Forum "ATM User-Network Interface (UNI) Signalling Specification Version 4.0" [4] contains the description and specification of the network call correlation identifier for PNNI, AINI and UNI interfaces.
Section one contains information about the purpose of this addendum and its scope. Section two specifies the NCCI encoding and formats. Section three specifies the NCCI for PNNI interfaces, section four specifies the NCCI for AINI interfaces, while section five specifies the NCCI for UNI interfaces. Section six discusses the interactions with existing features, section seven the compatibility with nodes that do not support this feature and section eight contains the references to other documents. Annex A contains the NCCI SNMP MIB. Annex B contains the NCCI PICS Proforma for PNNI, Annex C contains the NCCI PICS Proforma for AINI and Annex D contains the NCCI PICS Proforma for UNI. Appendix A contains an informative description of the B-ISUP NCCI. Appendix B contains an informative example of NCCIs correlation between private and ATM Service Provider networks.
1. General information
The purpose of the Network call correlation identifier (NCCI) is to uniquely identify a call within a network. Currently only one connection can exist per call, therefore the NCCI can also be used to identify the connection associated with a call. Once a NCCI has been associated with a call it can be used by network management applications that need to refer to a specific call or to correlate different management records generated for the call. A NCCI can be associated with a virtual channel connection (SVCC, soft PVCC) or a virtual path connection (SVPC, soft PVPC). A NCCI can be associated with a point-to-point call or a point-to-multipoint call. 
It is possible that a unique NCCI could appear to be non-unique for point-to-multipoint calls. It is possible for a point-to-multipoint call to enter a network node on multiple branches. Thus it would appear to be multiple calls to this node with the same NCCI. This also applies on a network basis if a network reuses the NCCI assigned by a previous network for point-to-multipoint calls. E.g. Branches of a point-to-multipoint call may enter a network at multiple interfaces.
1.1 Scope
[Normative]
The scope of this document is to specify signaling for the support of NCCI across PNNI interfaces, across AINI interfaces, and across private and public UNI interfaces.
Signaling as specified in this addendum provides for the association of a NCCI with a call. The decision of whether to assign a NCCI to a call, the process by which applications become aware of the NCCIs associated with calls, or in general the way NCCIs are used by applications are outside the scope of this document.
NCCI is an optional feature of PNNI v1.0 [1,2], of AINI v1.0 [3] and of UNI v4.0 [4].
This document does not address the NCCI procedures at an inter-network PNNI nor the interactions of the NCCI with Leaf Initiated Join at UNI v4.0.
A switch supporting the NCCI feature shall implement both the procedures for Point-to-Point calls and the procedures for Point-to-Multipoint calls. A switch shall support the association of a NCCI with calls for a virtual channel connection (SVCC, soft PVCC) and calls for a virtual path connection (SVPC, soft PVPC).
A device supporting PNNI, UNI or AINI shall be capable of forwarding a NCCI. A device supporting UNI or AINI shall also be capable of assigning a new NCCI, of discarding a NCCI and of returning a NCCI in a CONNECT message.
1.2 Overview
[Informative]
1.2.1 Network view
The NCCI capability allows a network to have an identifier for a call that can be used to correlate information gathered by any of the nodes in the path of the call. When the call enters a network (i.e. either at a UNI or at an AINI interface), the network may:
* If there is a NCCI included in the incoming call, forward the incoming NCCI, discard the incoming NCCI, or assign its own NCCI for the call.
* If there is no NCCI included in the incoming call, assign its own NCCI for the call.
* If a NCCI was assigned by this network, the NCCI may be included when a CONNECT message is sent in response to the originating user or the preceding network.
When the call exits a network (i.e. either at a UNI or at an AINI interface), the network may include a NCCI if one was assigned. If no NCCI was assigned, the network may assign one.
1.2.2 Nodal view
When a call enters a node over either a UNI or an AINI interface, the node may:
* If there is a NCCI included in the incoming call, forward the incoming NCCI, discard the incoming NCCI, or assign its own NCCI for the call.
* If there is no NCCI included in the incoming call, assign its own NCCI for the call.
* If a NCCI was assigned by this node the NCCI may be included when a CONNECT message is sent in response to the originating user or the preceding network.
When the call exits a node over either a UNI or an AINI interface, the node may include a NCCI if one was assigned. If none was assigned, it may assign one.
At an intra-network interface, a node will transport the NCCI, if present, without modification.
1.2.3 Modeling Considerations
This specification uses the same model as the procedures in the PNNI v1.0 and AINI specifications. This model is described in section 6.1 of the PNNIv1.0 specification and defines the "preceding" and "succeeding" sides of an interface.
In addition, this specification introduces the use of "primitives" exchanged between a Call Control entity and a Protocol Control entity. Figure 1-1 illustrates their use. 
* The reception of a signaling message over an interface triggers the sending of a corresponding "indication" primitive to the Call Control entity. 
* The reception of a "request" primitive from the Call Control entity triggers the sending of the corresponding signaling message over the interface.
The NCCI procedures deal with the assignment, forwarding or discarding of an NCCI. While these operations are logically associated with a "node", the model used in PNNI and AINI does not allow it. For modeling purposes, it is considered in the procedures sections that assignment of an NCCI typically occurs at the succeeding side of an interface. 
The model used in this document, while necessary for the NCCI procedures specification, should not be considered as an additional constraint on possible implementations of the NCCI feature.

Figure 1-1 Primitives used in the NCCI procedures
2. 
Network call correlation identifier information element coding
The purpose of the Network call correlation identifier information element is to uniquely identify a call.


Bits








8
7
6
5
4
3
2
1
Octet
Network call correlation identifier information element







 
1
1
1
0
1
1
1
1
1
1
Coding
IE Instruction Field
2
Ext
standard


Length of Network call correlation identifier information element contents







3
Length of Network call correlation identifier information contents (continued)







4
Identifier type







5
Identifier Length







5.1








5.2
Identifier Value







To








5.n
Figure 2-1 Network call correlation identifier information element
Coding standard (octet 2)

Bits
Meaning
8
7
6
5

4
3
2
1


1
1






ATM Forum specific 

Identifier Type (octet 5) & Identifier Length (octet 5.1)
The identifier type identifies the format of NCCI that is contained in the information element.
The following identifier types are defined:
Bits
Meaning
8
7
6
5

4
3
2
1

0
0
0
0

0
0
0
1
AESA-based NCCI
Note 1
0
0
0
0

0
0
1
0
B-ISUP NCCI
Note 2

Note 1 - 	The AESA-based NCCI is encoded according to the format shown in Figure 2-2. The identifier length shall be set to the value of 28 octets.
Note 2 - 	The B-ISUP NCCI is encoded according to the format specified in 3.2.3.1 of ITU-T Recommendation Q.2726.3 [5]. The identifier length shall be set to the value of 9 octets.
Network call correlation identifier value (octets 5.2-5.n)
To support interworking between B-ISUP and PNNI networks, two formats of NCCI are defined:
a) AESA-based NCCI format
As shown in Figure 2-2 the AESA-based NCCI format consists of a string of 28 octets divided in two parts:
NCCI Root	The NCCI root (20 octets) consists of the full ATM End System Address (AESA) associated with the entity (e.g. node, interface) at which the NCCI is assigned to the call.
NCCI Index	The NCCI index (8 octets) is locally unique within the context of the NCCI root. The semantics of this field are determined by the assigning entity. The values chosen shall be such as to guarantee a unique NCCI over a sufficiently long period of time. The assigning entity should sequence through a broad range of NCCI index values before reusing an index value. The assigning entity shall not immediately reuse a NCCI index value for another call.

NCCI Root (AESA, 20 octets)
NCCI Index (8 octets)
Figure 2-2 Format of a AESA-based Network Call Correlation Identifier (28 octets)

b) B-ISUP NCCI Format
The B-ISUP NCCI format is specified in 3.2.3.1 of ITU-T Recommendation Q.2726.3 [5]. Appendix A contains an informative description of the B-ISUP NCCI. 
3. 
NCCI feature for PNNI
3.1 Additions to PNNI signaling messages
To provide the NCCI extension, the following information element is added to table 6-5 in 6.4.5.1/PNNI v1.0:
Table 3-1 Additional information element used in PNNI
Bits
8 7 6 5    4 3 2 1








Information Element
Max Length
Max no. of Occurrences
1 1 1 0    1 1 1 1








Network call correlation identifier
38
1

3.1.1 SETUP
The following information element is added to figure 6-8 in 6.3.1.6/PNNI v1.0:

Information Element
Reference
Type
Length
Network Call Correlation Identifier
2
O
15-38
Figure 3-1 Additional SETUP message content
3.1.2 ADD PARTY
The following information element is added to figure 6-19 in 6.3.4.1/PNNI v1.0:

Information Element
Reference
Type
Length
Network Call Correlation Identifier
2
O
15-38
Figure 3-2 Additional ADD PARTY message content
3.1.3 CO-BI SETUP
The following information element is added to table 26-2 in 26.8.1.2.3/GSS v1.0:

Information Element
Reference
Type
Length
Network Call Correlation Identifier
2
O
15-38
Figure 3-3 Additional CO-BI SETUP message content
3.2 NCCI Procedures for PNNI
In this section, the term SETUP message refers to both the CO-BI SETUP message defined in GSS v1.0 and the SETUP message defined in PNNI v1.0.
3.2.1 Procedures for Point-to-Point calls
The following text is added to section 6.5.2.1/PNNI v1.0:
When the preceding side of a PNNI receives a setup request, which does contain a NCCI, the node shall forward the NCCI information element. When the preceding side receives a setup request, which does not contain a NCCI, the node shall not assign a NCCI.
If the succeeding side of a PNNI receives a SETUP message containing a NCCI information element, the node shall forward the NCCI to the next interface. When the succeeding side receives a SETUP message, which does not contain a NCCI, the node shall not assign a NCCI.
3.2.2 Procedures for Point-to-Multipoint calls
3.2.2.1 Setup of the initial party
The procedures for the setup of the initial party of a Point-to-Multipoint call are specified in section 6.6.1/PNNI v1.0. These procedures build upon the procedures in section 6.5/PNNI v1.0 as modified by section 3.2.1 which includes the NCCI specific procedures.
Additional procedures at the preceding side of the PNNI:
If an add party request contains an NCCI and is to be converted into a SETUP message, the procedures in section 3.2.1 shall apply, as if the NCCI was contained in a received setup request.
3.2.2.2 Adding a party
The following text is added to section 6.6.2/PNNI v1.0:
At the preceding side of the PNNI:
If a received add party request contains a NCCI, the node shall forward the NCCI as it received it. If a received add party request does not contain a NCCI, the node shall not assign a NCCI
At the succeeding side of the PNNI:
If a received ADD PARTY message contains a NCCI information element, the node shall forward the NCCI as it received it to the preceding side of the next interface. If a received ADD PARTY message does not contain a NCCI information element, the node shall not assign a NCCI.
3.2.3 NCCI information element content validation
If a NCCI information element is received in a valid message, no content validation shall be performed on the NCCI information element, other than verifying the maximum information element length. If the call is progressed, the received NCCI information element shall be forwarded without modification, provided that the next interface is a PNNI interface. This allows support for other NCCI types in the future.
3.2.4 Storing the NCCI
A node may store the NCCI associated with a call (e.g. for recording call related information).
4. NCCI feature for AINI
4.1 Additions to AINI signaling messages
Section 3.1 of this document applies to AINI unless explicitly described in this section.
4.1.1 CONNECT
The following information element is added to figure 6-5 in 6.3.1.3/PNNI v1.0:

Information Element
Reference
Type
Length
Network Call Correlation Identifier
2
O
15-38
Figure 4-1 Additional CONNECT message content
4.1.2 CO-BI SETUP
Section 3.1.3 is not supported.
4.2 NCCI Procedures for AINI
4.2.1 Procedures for Point-to-Point calls
The following text is added to section 6.5.2.1/PNNI v1.0
When the preceding side of the AINI receives a setup request containing a NCCI, the node may forward the NCCI, may discard the NCCI, but shall not assign a NCCI. 
If the preceding side of the AINI receives a setup request not containing a NCCI, the node may assign a NCCI to the call.
When the succeeding side of the AINI receives a SETUP message containing a NCCI information element, the node may forward the NCCI, may discard the NCCI, or may assign a new NCCI to the call.
If the succeeding side of the AINI receives a SETUP message not containing a NCCI information element, the node may assign a NCCI to the call.
When a NCCI is assigned, the following shall apply:
* The NCCI shall be coded in a NCCI information element, as described in section 2.
* The NCCI information element shall be added to the SETUP message/setup indication.
The node shall guarantee a unique NCCI value for all calls that are assigned a NCCI at that location over a sufficiently long period of time.
The following procedures apply at the succeeding side of the AINI:
* If a NCCI was assigned during the setup phase, the node may insert the NCCI in the CONNECT message prior to progressing the message towards the preceding side. 
* A NCCI included in the CONNECT message must be the one assigned by this node. 
* If the node at the succeeding side of the AINI did not assign a NCCI, no NCCI shall be returned in the CONNECT message. 
When a NCCI is returned in a CONNECT message, the following shall apply:
* The NCCI shall be coded in a NCCI information element, as described in section 2.
* The IE instruction field shall be coded with the pass along request bit set to 0.
When a NCCI information element is received in a CONNECT message, the NCCI may be stored and the NCCI information element is discarded before the message is forwarded towards the calling party.
4.2.2 Procedures for Point-to-Multipoint calls
4.2.2.1 Setup of the initial party
The procedures for the setup of the initial party of a Point-to-Multipoint call are specified in section 6.6.1/PNNI v1.0. These procedures build upon the procedures in section 6.5/PNNI v1.0 as modified by section 4.2.1 which includes the NCCI specific procedures.
Additional procedures at the preceding side of the AINI:
If an add party request is to be converted into a SETUP message, the procedures in section 4.2.1 shall apply, as if a setup request was received.
4.2.2.2 Adding a party
The following text is added to section 6.6.2/AINI v1.0:
At the preceding side of the AINI:
If a NCCI value was assigned to a point-to-multipoint call at the preceding side by the node, all ADD PARTY messages sent for this call over this interface shall contain the same NCCI information element.
If a received add party request contains a NCCI , and if the initial setup request contained a NCCI  which has been forwarded, the node shall forward the NCCI information element as it received it. 
If the initial SETUP message did not contain a NCCI information element, the node shall not include any NCCI information element in subsequent ADD PARTY messages.
At the succeeding side of the AINI:
If a NCCI value was assigned to a point-to-multipoint call at the succeeding side by this node, all add party indications sent for this call shall contain the same NCCI. 
If a received ADD PARTY message contains a NCCI information element, and if the initial SETUP message contained a NCCI information element which has been forwarded to the preceding side of the next interface, the node shall forward the NCCI as it received it. 
If the initial setup indication did not contain a NCCI, the node shall not include any NCCI in subsequent add party indications.
4.2.3 Storing the NCCI
A node shall store the NCCI associated with a call when the call is a Point-to-Multipoint connection and the node has assigned the NCCI. Otherwise, a node may store the NCCI (e.g. for recording call related information).
4.2.4 Interworking between AINI and B-ISUP
The following row is added to the table of AINI/4.1.1.2.1.1:
AINI   to   B-ISUP
SETUP
IAM
Network Call Correlation Identifier
Network Call Correlation Identifier (Note 1)
Note 1 - 	Interworking with B-ISUP is only possible if the Network Call Correlation Identifier has a B-ISUP format. If the NCCI in the NCCI information element has any other format, the information element shall be dropped. Networks with BISUP interfaces should only use the BISUP format of NCCI and thus avoid an interworking problem between AINI and BISUP.
Table 4-1 Additional SETUP to IAM mapping
The following row is added to the table of AINI/4.1.1.2.1.2:
B-ISUP   to   AINI
IAM
SETUP
Network Call Correlation Identifier
Network Call Correlation Identifier
Table 4-2 Additional IAM to SETUP mapping
The following row is added to the table of AINI/4.1.4.2.1.2:
AINI   to   B-ISUP
ADD PARTY
IAM
Network Call Correlation Identifier
Network Call Correlation Identifier (Note 1)
Note 1 - 	Interworking with B-ISUP is only possible if the Network Call Correlation Identifier has a B-ISUP format. If the NCCI in the NCCI information element has any other format, the information element shall be dropped. Networks with BISUP interfaces should only use the BISUP format of NCCI and thus avoid an interworking problem between AINI and BISUP.
Table 4-3 Additional ADD PARTY to IAM mapping
The following row is added to the table of AINI/4.1.4.3.1.2:
B-ISUP   to   AINI
IAM
ADD PARTY
Network Call Correlation Identifier
Network Call Correlation Identifier
Table 4-4 Additional IAM to ADD PARTY mapping
The following row is added to the table of AINI/4.1.1.2.4.1:
AINI   to   B-ISUP
CONNECT
ANM
Network Call Correlation Identifier
Not carried
Table 4-5 Additional CONNECT to ANM mapping
5. NCCI feature for UNI
5.1 Additions to UNI signaling messages
To support a NCCI at the UNI, the following information element is added to Table2-1 of UNI Signalling Specification V4.0: 

Bits
8 7 6 5 4 3 2 1 

Information Element
Max. 
Length 
Max. no. of Occurences
1 1 1 0 1 1 1 1
Network Call Correlation Identifier 
38
1
Table 5-1: Additional Information Element for UNI Signalling 4.0
5.1.1 SETUP
The following information element is added to Table 3-8/Q.2931: 

Information Element
Reference
Direction
Type
Length
Network Call Correlation Identifier
2
both
O
15 - 38
Table 5-2: Additional Information Element for UNI SETUP message
5.1.2 ADD PARTY 
The following information element is added to Table 8-8/Q.2971: 

Information Element 
Reference
Direction
Type
Length
Network Call Correlation Identifier
2
both
O
15 - 38
Table 5-3: Additional Information Element for UNI ADD PARTY message
5.1.3 CONNECT
The following information element is added to Table 3-4/Q.2931: 

Information Element
Reference
Direction
Type
Length
Network Call Correlation Identifier
2
both
O
15 - 38
Table 5-4: Additional Information Element for UNI CONNECT message
5.2 NCCI Procedures for UNI
The following procedures apply to all types of UNI interfaces.
5.2.1 Procedures for Point-to-point calls
5.2.1.1 Call establishment at the originating interface
The procedures of section 4.2.1 are added to section 5.1/Q.2931 with the following changes: 
Any occurrence of 'preceding' (respectively 'succeeding') is replaced by 'user' (respectively 'network'). Any occurrence of 'AINI' is replaced by 'UNI'. In the procedures for the user side, any occurrence of 'node' is replaced by 'user'.
The coding of the pass along request bit in the IE instruction field of the NCCI information element does not apply.
5.2.1.2 Call establishment at the destination interface
The procedures of section 4.2.1 are added to section 5.2/Q.2931 with the following modifications: 
Any occurrence of 'preceding' (respectively 'succeeding') is replaced by 'network' (respectively 'user'). Any occurrence of 'AINI' is replaced by 'UNI'. In the procedures for the user side, any occurrence of 'node' is replaced by 'user'.
The coding of the pass along request bit in the IE instruction field of the NCCI information element does not apply.
5.2.2 Procedures for Point-to-Multipoint calls
5.2.2.1 Adding a party at the originating interface
5.2.2.1.1 Setup of the first party
The procedures in section 5.0/UNI v4.0 as modified by section 5.2.1.1 shall apply, augmented by the following :
If an add party request is to be converted into a SETUP message, the procedures in section 5.2.1.1 shall apply, as if a setup request was received.
5.2.2.1.2 Adding a PARTY
The procedures of section 4.2.2.2 are added to section 5.0/ UNI v4.0. with the following changes: 
Any occurrence of 'preceding' (respectively 'succeeding') is replaced by 'user' (respectively 'network'). Any occurrence of 'AINI' is replaced by 'UNI'. In the procedures for the user side, any occurrence of 'node' is replaced by 'user'.
The coding of the pass along request bit in the IE instruction field of the NCCI information element does not apply.
5.2.2.2 Adding a party at the destination interface
5.2.2.2.1 Setup of the first party
The procedures in section 5.0/UNI v4.0 as modified by section 5.2.1.2 shall apply, augmented by the following :
If an add party request is to be converted into a SETUP message, the procedures in section 5.2.1.2 shall apply, as if a setup request was received.
5.2.2.2.2 Adding a PARTY
The procedures of section 4.2.2.2 are added to section 5.0/ UNI v4.0. with the following modifications: 
Any occurrence of 'preceding' (respectively 'succeeding') is replaced by 'network' (respectively 'user'). Any occurrence of 'AINI' is replaced by 'UNI'. In the procedures for the user side, any occurrence of 'node' is replaced by 'user'.
The coding of the pass along request bit in the IE instruction field of the NCCI information element does not apply.
5.2.3 Storing the NCCI 
Section 4.2.3 applies. 
6. Interaction with existing features
6.1 Interaction with Soft PVCs.
When reestablishing a Soft PVCC or a Soft PVPC the same NCCI that was initially assigned shall be used.
7. Compatibility with nodes not supporting this feature
To handle consistently NCCIs according to the procedures described in section 3, when coding the NCCI IE at a PNNI, the IE instruction field of the NCCI IE should be coded with the "pass along request" bit set to 1. Both the IE instruction field flag (bit 5) and the pass along request bit (bit 4) should be set to "1". 
When coding the NCCI IE at a AINI, the IE instruction field of the NCCI IE should be coded with the IE instruction field flag (bit 5) set to "1" and the IE action indicator (bits 3-1) set to "Discard information element and proceed". The pass along request bit (bit 4) should be set to "0".
When coding the NCCI IE at a UNI, the IE instruction field of the NCCI IE should be coded with the IE instruction field flag (bit 5) set to "1" and the IE action indicator (bits 3-1) set to "Discard information element and proceed".
8. References
[1]	Private Network-Network Interface Specification Version 1.0, ATM Forum af-pnni-0055.000, March 1996
[2]	PNNI v1.0 Errata and PICS, ATM Forum af-pnni-0081.000, May 1997
[3]	ATM Inter-Network Interface (AINI) Specifications, ATM Forum af-cs-0125.000, April 1999
[4]	ATM User-Network Interface (UNI) Signalling Specification Version 4.0, af-sig-0061.00, July 1996
[5]	B-ISDN user part - Network generated session identifier, ITU-T Recommendation Q.2726.3, June 1996
[6]	PNNI 1.0 Addendum 1 - B-QSIG Interworking and Generic Support for Supplementary Services, ATM Forum af-cs-0102.000, October 1998

Annnex A. 
NCCI SNMP MIB
NCCI-MIB DEFINITIONS ::= BEGIN

        IMPORTS
                MODULE-IDENTITY, OBJECT-TYPE, enterprises
                        FROM SNMPv2-SMI
                TEXTUAL-CONVENTION, RowStatus, TruthValue
                        FROM SNMPv2-TC
                ifIndex
                        FROM IF-MIB
                atmVclEntry, atmVplEntry
                        FROM ATM-MIB
                MODULE-COMPLIANCE, OBJECT-GROUP
                        FROM SNMPv2-CONF;

atmfNcciMIB MODULE-IDENTITY
        LAST-UPDATED    "0002290000Z"
        ORGANIZATION    "The ATM Forum"
        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 for managing the ATM Forum 
             Network Call Correlation Identifier (NCCI) v1.0"
        REVISION "0002290000Z"
        DESCRIPTION
          "Initial version of the MIB module for managing the ATM Forum
           Network Call Correlation Identifier v1.0."
       ::= { atmfNcci 1 }

-- The object identifier subtree for the ATM Forum NCCI MIBs

atmForum        OBJECT IDENTIFIER ::= { enterprises 353 }
atmForumNetworkManagement       OBJECT IDENTIFIER ::= { atmForum 5 }
atmfSignalling        OBJECT IDENTIFIER ::= { atmForumNetworkManagement 9 }
atmfNcci        OBJECT IDENTIFIER ::= { atmfSignalling 1 }

ncciMIBObjects OBJECT IDENTIFIER ::= { atmfNcciMIB 1 }

-- ========================================
-- atmNCCIType
-- ========================================

    AtmNcciType ::= TEXTUAL-CONVENTION
        STATUS        current
        DESCRIPTION
            "The network call correlation identifier (NCCI) is used to 
             uniquely identify a call over ATM networks.

             The associated call can be either a point-to-point or 
             point-to-multipoint call. Both VCCs and VPCs can be
             associated with a network call correlation identifier.
             A network call correlation identifier (NCCI) can be coded
             under two formats : The AESA-based format or the B-ISUP format

             The AESA-based NCCI has a length of 28 bytes and is composed 
             as follows :
             
                - The NCCI root (20 octets) contains the AESA associated 
                  with the entity (node, interface) at which the NCCI is 
                  first assigned to that call.

                - The NCCI index (8 octets) is used in combination with the 
                  AESA to provide a NCCI that is unique over a sufficiently 
                  long period of time.

                -------------------------------------------------
                |        NCCI Root (AESA)          | NCCI Index |
                -------------------------------------------------

             The B-ISUP NCCI has a length of 9 bytes and is composed 
             as follows (defined in ITU Recommendation Q.2726.3) :
             
                - The network identifier (2 octets of 4 BCD digits) 
                  consists of a 0 followed by an E.164 country code 
                  followed by a sufficient number of 0s to make 4 digits.

                - The point code (3 octets) contains the SS7 point code
                  of the node where the NCCI is assigned.

                - The Call identifier (4 octets) is used in combination with 
                  the Point Code and the Net ID to provide a NCCI that is 
                  unique over a long period of time.

                -----------------------------------------
                | Net ID | Point Code | Call Identifier |
                -----------------------------------------
            "
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        SYNTAX        INTEGER { 
                                none (0),
                                aesaBased(1), 
                                bisup(2) 
                              }

-- ========================================
-- atmNCCI
-- ========================================

    AtmNcci ::= TEXTUAL-CONVENTION
        STATUS        current
        DESCRIPTION
            "Describes the value of a NCCI

             Two types of NCCI are defined: the AESA-based and the 
             B-ISUP formats. These formats are explained in the 
             AtmNcciType definition.

             When the AtmNcciType is equal to none, it means that no 
             NCCI is contained in the variable. The length of AtmNcci
             is equal to zero byte."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        SYNTAX        OCTET STRING (SIZE (0|9|28))


-- ========================================
-- atmNCCIRoot
-- ========================================

    AtmNcciRoot ::= TEXTUAL-CONVENTION
        STATUS        current
        DESCRIPTION
            "The root portion of a NCCI.

             Two types of NCCI are defined: the AESA-based and the 
             B-ISUP formats. These formats are explained in the atmNcciType
             definition.

             For a NCCI in a AESA-based format, the root portion is equivalent
             to the NCCI Root as described in the atmNcciType definition 
             (20 bytes).

             For a NCCI in a B-ISUP format, the root portion is equivalent
             to the NCCI Network ID + Point Code as described in the 
             atmNcciType definition (5 bytes).

             When the AtmNcciType is equal to none, it means that no 
             NCCI is contained in the variable. The length of AtmNcciRoot
             is equal to zero byte."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        SYNTAX        OCTET STRING (SIZE (0|5|20))



-- ========================================
-- Per Interface NCCI Configuration
-- ========================================

ncciIfTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF NcciIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "The table used to manage the assignment of NCCIs on 
             a per interface basis. One row of this 
             table can be created  by the managed system for each row in 
             the ifTable of atm(37).

             An entry in this table configures the management of NCCIs for
             SVCs, SVPs, soft PVCs, and soft PVPs. The configuration can 
             be applied to point-to-point calls, point-to-multipoint calls 
             or both.

             When no entry in this table has been configured for a given 
             interface and direction, the action is to forward the received
             NCCI if present, and not to assign any NCCI even when no NCCI is
             received."
         REFERENCE
            "ATM Forum NCCI v1.0"
        ::= { ncciMIBObjects 1 }

ncciIfEntry OBJECT-TYPE
        SYNTAX        NcciIfEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "Each entry in this table is used to configure the NCCI     
             operations for SETUP messages of svcs and svps. 

             The entry is also be used to configure the assignment of NCCIs to
             soft pvcs or soft pvps whose terminating legs are located on the 
             interface indexed by ifIndex.

             The actions configured in this entry are subject to the procedures
             described in sections 3,4 and 5 of the ATM Forum NCCI v1.0.

             The ifIndex is used as the instance ID to uniquely identify 
             the interface on the local switching system. This index has 
             the same value as the ifIndex object defined in RFC 1573 for 
             the same interface, since this table correlates with the ifTable 
             in RFC 1573."
        INDEX { ifIndex, ncciIfDirection }
        ::= { ncciIfTable 1 }

NcciIfEntry ::=
        SEQUENCE {
                  ncciIfDirection       INTEGER,
                  ncciIfAction          INTEGER,
                  ncciIfSave            BITS,
                  ncciIfinConnect       TruthValue,
                  ncciIfType            AtmNcciType,
                  ncciIfRoot            AtmNcciRoot,
                  ncciIfCastType        INTEGER,
                  ncciIfVpType          INTEGER,
                  ncciIfVcType          INTEGER,
                  ncciIfRowStatus       RowStatus
                 }

ncciIfDirection OBJECT-TYPE 
        SYNTAX       INTEGER { incoming (1), 
                               outgoing (2) 
                             } 
        MAX-ACCESS   not-accessible 
        STATUS       current 
        DESCRIPTION 
            "Indicates if the configuration applies to incoming setup 
             indications or to outgoing setup requests."
        ::= { ncciIfEntry 1}

ncciIfAction OBJECT-TYPE 
        SYNTAX       INTEGER { 
                               discardNcci (1), 
                               assignNcci (2), 
                               forwardNcci (3) 
                             } 
        MAX-ACCESS   read-create 
        STATUS       current 
        DESCRIPTION 
            "Indicates what action to perform when a setup indication
             is received on this interface. 

             'discardNcci' means that if an incoming setup indication 
             is received, if a NCCI is present in the setup, it is discarded
             and no NCCI is assigned to the call. The values contained 
             in ncciIfType and ncciIfRoot are ignored. 

             'assignNcci' means that if an incoming setup indication is
             received, a new locally generated NCCI is assigned to the call.
             'assignNcci' implies that the ncciIfType is set to a value
             different than 'none'. 

             'forwardNcci' means that if an incoming setup indication 
             is received, if a NCCI is present in the setup, it is forwarded
             to the next interface. 
             If no NCCI is present: 
             - a locally generated NCCI is assigned to the call if 
               the ncciIfType is set to a value different than 'none'. 
             - no locally generated NCCI is assigned to the call if 
               the ncciIfType is set to the value 'none'."

         REFERENCE
            "ATM Forum NCCI v1.0 sections 3, 4, and 5"
         DEFVAL { forwardNcci }
        ::= { ncciIfEntry 2}

ncciIfSave OBJECT-TYPE 
        SYNTAX       BITS { localNcci (0), 
                            remoteNcci (1) 
                          } 

        MAX-ACCESS   read-create 
        STATUS       current 
        DESCRIPTION 
            "Indicates whether NCCIs are saved for calls on this 
             interface

             'localNcci' indicates that the value of 
              - a newly assigned NCCI, or 
              - a received NCCI if it has been forwarded, or
               - a received NCCI if it has been discarded and either 
                 the atmVclConnKind or the atmVplConnKind is 'svcOutgoing', or
               - a received NCCI if the atmVclConnKind or atmVplConnKind 
                 is 'spvcTarget'
              is stored.


             'remoteNcci' indicates that the value of
              - a NCCI received in the SETUP message if either 
                 the atmVclConnKind or the atmVplConnKind is 'svcIncoming', or
              - a NCCI received in the CONNECT message if either 
                 the atmVclConnKind or the atmVplConnKind is 'svcOutgoing'
               is stored."

        ::= { ncciIfEntry 3}


ncciIfinConnect OBJECT-TYPE 
        SYNTAX       TruthValue
        MAX-ACCESS   read-create 
        STATUS       current 
        DESCRIPTION 
            "Indicates whether a locally generated NCCI assigned to an
             incoming call on this interface is returned in the 
             CONNECT message. 

             'true' means that the NCCI is returned in the CONNECT message.

             This object is only applicable on AINI or UNI interfaces 
             and when ncciIfDirection has the value 'incoming'."
        DEFVAL { true }
        ::= { ncciIfEntry 4}

ncciIfType OBJECT-TYPE
        SYNTAX        AtmNcciType
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "Indicates the format of the NCCI to be assigned on the 
             specified interface."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        DEFVAL { none }
        ::= { ncciIfEntry 5 }

ncciIfRoot OBJECT-TYPE
        SYNTAX        AtmNcciRoot
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "Contains the NCCI Root or the NCCI Network ID + Point Code
             to be used by the switching system when generating a NCCI 
             on the specified interface.

             If the ncciIfRoot value is not supplied prior to creating the
             row, the switching system is in charge of deriving the 
             ncciIfRoot value from one of the switch addresses. 
             The value of the NCCI root assigned by the switch can be read 
             from this variable when the entry in the table has been activated.

             The length of the NCCI must match the length of the 
             specified NCCI format."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciIfEntry 6 }

ncciIfCastType OBJECT-TYPE
        SYNTAX       INTEGER { 
                               p2p (1), 
                               p2mp (2),
                               p2pANDp2mp (3) 
                             }
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Indicates if the NCCI configuration for this interface 
             applies to point-to-point calls only, to 
             point-to-multipoint calls only, or to both"
        ::= { ncciIfEntry 7}

ncciIfVpType OBJECT-TYPE
        SYNTAX       INTEGER { 
                               none (1),
                               svp (2), 
                               spvpInitiator (3),
                               svpANDspvpInitiator (4) 
                             }
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Indicates if the NCCI configuration for this interface 
             applies to svps only, to soft pvps only, to both, or to none

             'svp' value applies to switched portions of a soft pvp as well           
             as switched vps."
        ::= { ncciIfEntry 8}

ncciIfVcType OBJECT-TYPE
        SYNTAX       INTEGER { 
                               none (1),
                               svc (2), 
                               spvcInitiator (3),
                               svcANDspvcInitiator (4) 
                             }
        MAX-ACCESS   read-create
        STATUS       current
        DESCRIPTION
            "Indicates if the NCCI configuration for this interface 
             applies to svcs only, to soft pvcs only, to both, or to none
             'svc' value applies to switched portions of a soft pvc as well           
             as switched vcs."
        ::= { ncciIfEntry 9}
ncciIfRowStatus OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-create
        STATUS        current
        DESCRIPTION
            "To create, delete, activate and de-activate a NCCI
             configuration for an interface."
        ::= { ncciIfEntry 10}

-- ========================================
-- Ncci Vpl Table 
-- ========================================

ncciVpTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF NcciVpEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "The table used to manage NCCIs and their association 
             with a point-to-point or point-to-multipoints PVPs and 
             Soft PVPs in a switching system.

             This table is an augmentation of atmVplTable."
         REFERENCE
            "ATM Forum NCCI v1.0"
        ::= { ncciMIBObjects 2 }

ncciVpEntry OBJECT-TYPE
        SYNTAX        NcciVpEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "Each entry in this table represents a NCCI associated with
             a PVP or Soft PVP connection.

             The content of this table reflects only the NCCI values 
             associated with VPCs. atmVplTable is specified in
             ATM-MIB (RFC 2515).  

             This entry serves to identify the VPL on the interface."
        AUGMENTS { atmVplEntry }
        ::= { ncciVpTable 1 }

NcciVpEntry ::=
        SEQUENCE {
                  ncciVpLocalType         AtmNcciType,
                  ncciVpLocalValue        AtmNcci,
                  ncciVpRemoteType        AtmNcciType,
                  ncciVpRemoteValue       AtmNcci
                 }

ncciVpLocalType OBJECT-TYPE
        SYNTAX        AtmNcciType
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The format of the NCCI contained in the NCCI ncciVpLocalValue."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVpEntry 1 }


ncciVpLocalValue OBJECT-TYPE
        SYNTAX        AtmNcci
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The NCCI value associated with the VPC identified by
             its atmVpl. It contains the the value 
             - of the assigned NCCI if a new NCCI has been assigned,  
             - of a received NCCI if it has been forwarded, 
             - of a received NCCI if it has been discarded and the 
               atmVplConnKind for this entry is 'svcOutgoing'
             - of a received NCCI if the atmVplConnKind is 'spvcTarget'

             The length and type of the NCCI is determined by the 
             ncciVpLocalType."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVpEntry 2 }

ncciVpRemoteType OBJECT-TYPE
        SYNTAX        AtmNcciType
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The format of the NCCI contained in the NCCI ncciVpRemoteValue."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVpEntry 3 }


ncciVpRemoteValue OBJECT-TYPE
        SYNTAX        AtmNcci
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The NCCI value associated with the VPC on the other side
             of the interface. 

             When the atmVplConnKind for this entry is
             'svcIncoming', contains the NCCI value received in the SETUP 
             message on the interface. 

             When the atmVplConnKind for this entry is
             'svcOutgoing', contains the NCCI value 
             received in the CONNECT message on the interface.

             The length and type of the NCCI is determined by the 
             ncciVpRemoteType."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVpEntry 4 }


-- ========================================
-- Ncci Vcl Table 
-- ========================================

ncciVcTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF NcciVcEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "The table used to manage NCCIs and their association 
             with a point-to-point or point-to-multipoints PVCs and 
             Soft PVCs in a switching system.

             This table is an augmentation of atmVclTable."
         REFERENCE
            "ATM Forum NCCI v1.0"
        ::= { ncciMIBObjects 3 }

ncciVcEntry OBJECT-TYPE
        SYNTAX        NcciVcEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
            "Each entry in this table represents a NCCI associated with
             a PVC or Soft PVC connection.

             The content of this table reflects only the NCCI values 
             associated with VCCs. atmVclTable is specified in
             ATM-MIB (RFC 2515).  

             This entry serves to identify the VCL on the interface."
        AUGMENTS { atmVclEntry }
        ::= { ncciVcTable 1 }

NcciVcEntry ::=
        SEQUENCE {
                  ncciVcLocalType         AtmNcciType,
                  ncciVcLocalValue        AtmNcci,
                  ncciVcRemoteType        AtmNcciType,
                  ncciVcRemoteValue       AtmNcci
                 }

ncciVcLocalType OBJECT-TYPE
        SYNTAX        AtmNcciType
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The format of the NCCI contained in the NCCI ncciVcLocalValue."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVcEntry 1 }


ncciVcLocalValue OBJECT-TYPE
        SYNTAX        AtmNcci
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The NCCI value associated with the VCC identified by
             its atmVcl. It contains the value 
             - of the assigned NCCI if a new NCCI has been assigned,  
             - of a received NCCI if it has been forwarded, 
             - of a received NCCI if it has been discarded and the 
               atmVclConnKind for this entry is 'svcOutgoing'
             - of a received NCCI if the atmVclConnKind is 'spvcTarget' 

             The length and type of the NCCI is determined by the 
             ncciVcLocalType."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVcEntry 2 }

ncciVcRemoteType OBJECT-TYPE
        SYNTAX        AtmNcciType
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The format of the NCCI contained in the NCCI ncciVcRemoteValue."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVcEntry 3 }


ncciVcRemoteValue OBJECT-TYPE
        SYNTAX        AtmNcci
        MAX-ACCESS    read-only
        STATUS        current
        DESCRIPTION
            "The NCCI value associated with the VCC on the other side
             of the interface. 

             When the atmVclConnKind for this entry is
             'svcIncoming', contains the NCCI value received in the SETUP 
             message on the interface. 

             When the atmVclConnKind for this entry is
             'svcOutgoing', contains the NCCI value 
             received in the CONNECT message on the interface.

             The length and type of the NCCI is determined by the 
             ncciVcRemoteType."
        REFERENCE
            "ATM Forum NCCI v1.0 section 2"
        ::= { ncciVcEntry 4 }




-- conformance information

ncciMIBConformance
                   OBJECT IDENTIFIER ::= { atmfNcciMIB 2 }
ncciMIBCompliances
                   OBJECT IDENTIFIER ::= { ncciMIBConformance 1 }
ncciMIBGroups
                   OBJECT IDENTIFIER ::= { ncciMIBConformance 2 }


-- compliance statements

ncciMIBCompliance MODULE-COMPLIANCE
        STATUS        current
        DESCRIPTION
            "The compliance statement for entities which implement
             the AESA-based NCCI MIB.

             Groups of the AESA-based NCCI objects required for using the 
             NCCI extension are identified by the suffix MinGroup.

             Groups of optional NCCI objects are identified by the
             suffix OptionalGroup."

        MODULE  -- this module
            MANDATORY-GROUPS { 
                               ncciIfMinGroup,
                               ncciVcMinGroup
                              }

        ::= { ncciMIBCompliances 1 }

-- units of conformance

ncciIfMinGroup OBJECT-GROUP
        OBJECTS { 
                   ncciIfAction,
                   ncciIfSave,
                   ncciIfinConnect,
                   ncciIfType,
                   ncciIfRoot,
                  ncciIfCastType,
                  ncciIfVcType,
                   ncciIfRowStatus

                }
        STATUS current
        DESCRIPTION
            "A collection of per interface NCCI management objects required
             for managing the NCCI extension in a switching system."
        ::= { ncciMIBGroups 1 }

ncciVcMinGroup OBJECT-GROUP
        OBJECTS {
                  ncciVcLocalType,
                  ncciVcLocalValue,
                  ncciVcRemoteType,
                  ncciVcRemoteValue
                  }
        STATUS current
        DESCRIPTION
            "A collection of per Vc NCCI objects required
             for managing the NCCI extension in a switching system."
        ::= { ncciMIBGroups 2 }

ncciIfVpOptionalGroup OBJECT-GROUP
        OBJECTS { 
                  ncciIfVpType
                }
        STATUS current
        DESCRIPTION
            "A collection of per interface NCCI management objects required
             for managing the NCCI extension when VPs are supported
             in this switching system."
        ::= { ncciMIBGroups 3 }

ncciVpOptionalGroup OBJECT-GROUP
        OBJECTS {
                  ncciVpLocalType,
                  ncciVpLocalValue,
                  ncciVpRemoteType,
                  ncciVpRemoteValue
                  }
        STATUS current
        DESCRIPTION
            "A collection of per VP NCCI management objects required
             for managing the NCCI extension when VPs are supported
             in this switching system."
        ::= { ncciMIBGroups 4 }

END
Annnex B. 
NCCI PICS Proforma for PNNI v1.0
B.1 Introduction
To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options that have been implemented.  Such a statement is called a Protocol Implementation Conformance Statement (PICS).
B.1.1 Scope
This document provides the PICS proforma for the Network Call Correlation Identifier v1.0 for PNNI v1.0, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2[2].  In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS.
B.1.2 Normative References
[1]	ISO/IEC 9646-1:1994, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 1: General Concepts. (See also ITU Recommendation X.290(1995)).
[2]	ISO/IEC 9646-2:1994, Information technology - Open systems interconnection - Conformance testing methodology and interconnection - Part 2: Abstract test suite specification. (See also ITU Recommendation X.291(1995)).
[3]	Private Network-Network Interface Specification Version 1.0, ATM Forum af-pnni-0055.000, March 1996
[4]	PNNI v1.0 Errata and PICS, ATM Forum af-pnni-0081.000, May 1997
B.1.3 Definitions
This document uses the following terms defined in ISO/IEC 9646-1[1]:
* A Protocol Implementation Conformance Statement (PICS) is a statement  made by the supplier of an implementation or system, stating which capabilities have been implemented for a given protocol.
* A PICS proforma is a document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite specifier, which when completed for an implementation or system becomes the PICS.
B.1.4 Acronyms
IE
Information Element
IUT
Implementation Under Test
M
Mandatory requirements (these are to be observed in all cases)
O	
Optional (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)
NCCI
Network Call Correlation Identifier
O.n
Optional, but support is required for either at least one or only one of the options in the group labeled with the same numeral "n".
PICS
Protocol Implementation Conformance Statement
B.1.5 Conformance
The supplier of a protocol implementation which is claimed to conform to the ATM Forum Network Call Correlation Identifier v1.0 for PNNI v1.0 is required to complete a copy of the PICS proforma provided in this document and is required to provide the information necessary to identify both the supplier and the implementation.
B.2 
Identification of the Implementation
Implementation Under Test (IUT) Identification
IUT Name: ____________________________________________________________________
IUT Version: __________________________________________________________________
______________________________________________________________________________
System Under Test (SUT) Identification
SUT Name: ___________________________________________________________________
Hardware Configuration: _________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Operating System: ______________________________________________________________
Product Supplier
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________

Client
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _______________________________________________________________
Additional Information: __________________________________________________________
PICS Contact Person
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________
PICS/System Conformance Statement
Provide the relationship of the PICS with the System Conformance Statement for the system: 
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Identification of the protocol
This PICS proforma applies to the following:
* ATM Forum Network Call Correlation Identifier v1.0 for PNNI v1.0.
B.3 
PICS Proforma
B.3.1 Global statement of conformance
The implementation described in this PICS meets all of the mandatory requirements of the reference protocol.

[ ] YES
[ ] NO

Note:   Answering "No" indicates non-conformance to the specified protocol.   Non-supported mandatory capabilities are to be identified in the following tables, with an explanation by the implementor explaining why the implementation is non-conforming.
B.3.2 Instructions for Completing the PICS Proforma
The PICS Proforma is a fixed-format questionnaire.  Answers to the questionnaire should be provided in the rightmost columns, either by simply indicating a restricted choice (such as Yes or No), or by entering a value or a set of range of values.
A supplier may also provide additional information, categorized as exceptional or supplementary information.  These additional information should be provided as items labeled X.<i> for exceptional information, or S.<i> for supplemental information, respectively, for cross reference purposes, where <i> is any unambiguous identification for the item.  The exception and supplementary information are not mandatory and the PICS is complete without such information.  The presence of optional supplementary or exception information should not affect test execution, and will in no way affect interoperability verification.  The column labeled 'Reference' gives a pointer to sections of the protocol specification for which the PICS Proforma is being written.


B.4 Roles
Item
Roles
Does the IUT of the NCCI addendum to PNNI...
Status
Prerequisite
Reference
Support
NCCI-PP
The NCCI feature for Point-to-Point calls ?
M

1.1
[ ]Yes [ ]No
NCCI-PM
The NCCI feature for Point-to-Multipoint 
calls ?
M

1.1
[ ]Yes [ ]No
Comments:


Table 1: Roles (PNNI)

B.5 NCCI encoding
Item
NCCI formats and encoding
Is the IUT capable of...
Status
Prerequisite
Reference
Support
NCCI-E-
Generating a NCCI information element  as described in Figure 2-1?
M

2, 3.2.1,3.2.2
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the IE instruction field flag set  to 1?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the "pass along request" bit set to 1?
O

7
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a SETUP message ?
M

3.1.1
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in an ADD PARTY message ?
M

3.1.2
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a CO-BI SETUP message ?
M
MC 2.2/GSS
3.1.3
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a SETUP message ?
M

3.1.1
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in an ADD PARTY message ?
M

3.1.2
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a CO-BI SETUP message ?
M
MC 2.2/GSS
3.1.3
[ ]Yes [ ]No
Comments:








Table 2: NCCI encoding (PNNI)

B.6 NCCI capabilities for Point-to-Point calls

Item
Capabilities for Point-to-Point calls
Is  the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PPC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

3.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the preceding side, receiving and processing a setup request for a Point-to-Point call containing a NCCI , and forwarding the NCCI IE to the succeeding node as received?
M

3.2.1
[ ]Yes [ ]No
Comments:







Table 3: NCCI capabilities for Point-to-Point calls (PNNI)

B.7 NCCI procedures for Point-to-Point calls

Item
Procedures for Point-to-Point  calls 
Does  the IUT ...
Status
Prerequisite
Reference
Support
NCCI-PPP-
At the preceding side, forward the NCCI when receiving a setup request containing a NCCI?
M

3.2.1
[ ]Yes [ ]No
NCCI-PPP-
At the preceding side, not assign a NCCI to the call when receiving a setup request not containing a NCCI?
M

3.2.1
[ ]Yes [ ]No
NCCI-PPP-
At the succeeding side, forward the NCCI as received when receiving a SETUP message containing a NCCI information element?
M

3.2.1
[ ]Yes [ ]No
NCCI-PPP-
At the succeeding side, not assign a NCCI to the call when receiving a SETUP message not containing a NCCI IE ?
M

3.2.1
[ ]Yes [ ]No
NCCI-PPP-
When the next interface is a PNNI interface and a NCCI IE is received in a valid message, check only the maximum information element length of the NCCI IE and does not perform any other content validation on the IE ?
M

3.2.3
[ ]Yes [ ]No
NCCI-PPP-
Support the same NCCI procedures for CO-BI SETUP message in the same way as the regular SETUP message?
M
MC 2.2/GSS
3.2
[ ] Yes [ ] No
Comments:







Table 4: NCCI procedures for Point-to-Point calls (PNNI)
B.8 
NCCI capabilities for Point-to-Multipoint calls

Item
Capabilities for Point-to-Multipoint calls :
Is the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PMC-
At the preceding side, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received?
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the preceding side, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received?
M

3.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

3.2.2.2
[ ]Yes [ ]No
Comments


Table 5: NCCI capabilities for Point-to-Multipoint calls (PNNI)

B.9 NCCI procedures for Point-to-Multipoint calls

Item
Procedures for Point-to-Multipoint calls :
Does  the IUT...
Status
Prerequisite
Reference
Support
NCCI-PMP-
At the preceding side, forward the NCCI when receiving a setup request  containing a NCCI?
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, forward the NCCI when receiving an add party request containing a NCCI?
M

3.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, not assign a NCCI to the call when receiving a setup request not containing a NCCI?
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, not assign a NCCI to the call when receiving an add party request not containing a NCCI?
M

3.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, include the unaltered NCCI received in an add party request into the SETUP message, when converting the add party request to a SETUP message ?  
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMP-
At the succeeding side, forward the NCCI information element as received when receiving a SETUP message containing a NCCI ?
M

3.2.2.1
[ ]Yes  [ ] No
NCCI-PMP-
At the succeeding side , forward the NCCI information element as received when receiving an ADD PARTY  message  containing a NCCI information element?
M

3.2.2.2
[ ]Yes  [ ] No
NCCI-PMP-
At the succeeding side, not assign a NCCI to the call when receiving a SETUP message not containing a NCCI IE ?
M

3.2.2.1
[ ]Yes [ ]No
NCCI-PMP-
At the succeeding side, not assign a NCCI to the call when receiving an ADD PARTY message not containing a NCCI IE?
M

3.2.2.2
[ ]Yes [ ]No
Comments:


Table 6: NCCI procedures for Point-to-Multipoint calls (PNNI)

Annnex C. 
NCCI PICS Proforma for AINI v1.0
C.1 Introduction
To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options that have been implemented.  Such a statement is called a Protocol Implementation Conformance Statement (PICS).
C.1.1 Scope
This document provides the PICS proforma for the Network Call Correlation Identifier v1.0 for AINI v1.0, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2[2].  In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS.
C.1.2 Normative References
[1]	ISO/IEC 9646-1:1994, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 1: General Concepts. (See also ITU Recommendation X.290(1995)).
[2]	ISO/IEC 9646-2:1994, Information technology - Open systems interconnection - Conformance testing methodology and interconnection - Part 2: Abstract test suite specification. (See also ITU Recommendation X.291(1995)).
[3]	Private Network-Network Interface Specification Version 1.0, ATM Forum af-pnni-0055.000, March 1996
[4]	PNNI v1.0 Errata and PICS, ATM Forum af-pnni-0081.000, May 1997
[5]	ATM Inter-Network Interface (AINI) Specifications, ATM Forum af-cs-0125.000, April 1999
C.1.3 Definitions
This document uses the following terms defined in ISO/IEC 9646-1[1]:
* A Protocol Implementation Conformance Statement (PICS) is a statement  made by the supplier of an implementation or system, stating which capabilities have been implemented for a given protocol.
* A PICS proforma is a document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite specifier, which when completed for an implementation or system becomes the PICS.
C.1.4 Acronyms
IE
Information Element
IUT
Implementation Under Test
M
Mandatory requirements (these are to be observed in all cases)
O	
Optional (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)
NCCI
Network Call Correlation Identifier
O.n
Optional, but support is required for either at least one or only one of the options in the group labeled with the same numeral "n".
PICS
Protocol Implementation Conformance Statement
C.1.5 Conformance
The supplier of a protocol implementation which is claimed to conform to the ATM Forum Network Call Correlation Identifier v1.0 for AINI v1.0 is required to complete a copy of the PICS proforma provided in this document and is required to provide the information necessary to identify both the supplier and the implementation.
C.2 
Identification of the Implementation
Implementation Under Test (IUT) Identification
IUT Name: ____________________________________________________________________
IUT Version: __________________________________________________________________
______________________________________________________________________________
System Under Test (SUT) Identification
SUT Name: ___________________________________________________________________
Hardware Configuration: _________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Operating System: ______________________________________________________________
Product Supplier
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________

Client
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _______________________________________________________________
Additional Information: __________________________________________________________
PICS Contact Person
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________
PICS/System Conformance Statement
Provide the relationship of the PICS with the System Conformance Statement for the system: 
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Identification of the protocol
This PICS proforma applies to the following:
* ATM Forum Network Call Correlation Identifier v1.0 for AINI v1.0.
C.3 
PICS Proforma
C.3.1 Global statement of conformance
The implementation described in this PICS meets all of the mandatory requirements of the reference protocol.

[ ] YES
[ ] NO

Note:   Answering "No" indicates non-conformance to the specified protocol.   Non-supported mandatory capabilities are to be identified in the following tables, with an explanation by the implementor explaining why the implementation is non-conforming.
C.3.2 Instructions for Completing the PICS Proforma
The PICS Proforma is a fixed-format questionnaire.  Answers to the questionnaire should be provided in the rightmost columns, either by simply indicating a restricted choice (such as Yes or No), or by entering a value or a set of range of values.
A supplier may also provide additional information, categorized as exceptional or supplementary information.  These additional information should be provided as items labeled X.<i> for exceptional information, or S.<i> for supplemental information, respectively, for cross reference purposes, where <i> is any unambiguous identification for the item.  The exception and supplementary information are not mandatory and the PICS is complete without such information.  The presence of optional supplementary or exception information should not affect test execution, and will in no way affect interoperability verification.  The column labeled 'Reference' gives a pointer to sections of the protocol specification for which the PICS Proforma is being written.


C.4 Roles
Item
Roles
Does the IUT of the NCCI addendum to AINI...
Status
Prerequisite
Reference
Support
NCCI-PP
The NCCI feature for Point-to-Point calls ?
M

1.1
[ ]Yes [ ]No
NCCI-PM
The NCCI feature for Point-to-Multipoint 
calls ?
M
AINI/ (Note 1) 
1.1
[ ]Yes [ ]No
Comments:
Note 1: Provided that the support for Point-to-Multipoint calls is implemented at the AINI.


Table 1: Roles (AINI)

C.5 NCCI encoding
Item
NCCI formats and encoding
Is the IUT capable of...
Status
Prerequisite
Reference
Support
NCCI-E-
Generating a NCCI information element as described in Figure 2-1?
M

2, 4.2.1, 4.2.2
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the IE instruction field flag set to 1?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the "pass along request" bit set to 0?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the IE action indicator set to "Discard information element and proceed"?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with a NCCI value in a AESA-based format ?
O.1

2, 4.2.1, 4.2.2
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with a NCCI value in a B-ISUP format ?
O.1

2, 4.2.1, 4.2.2
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a SETUP message ?
M

4.1
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in an ADD PARTY message ?
M
NCCI-PM
4.1
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a CONNECT message ?
M

4.1.1
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a SETUP message ?
M

4.1
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in an ADD PARTY message ?
M
NCCI-PM
4.1
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a CONNECT message ?
M

4.1.1
[ ]Yes [ ]No
Comments:
O.1. = mandatory to support one of these NCCI formats.







Table 2: NCCI encoding (AINI)

C.6 NCCI capabilities for Point-to-Point calls
Prerequisite: NCCI-PP
Item
Capabilities for Point-to-Point calls
Is  the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PPC-
Assigning a NCCI when establishing a call for a Point-to-Point VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PPC-
Assigning a NCCI when establishing a call for a Point-to-Point VPC ?
M
OPT_6/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PPC-
Assigning a NCCI when establishing a call for a Point-to-Point Soft PVC ?
M
OPT_7/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PPC-
Assigning a NCCI when establishing a call for a Point-to-Point Soft PVP ?
M
OPT_7/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PPC- 
At the preceding side, receiving and processing a setup request for a Point-to-Point call containing a NCCI , and forwarding the NCCI IE to the succeeding node as received? 
M

4.2.1
[ ] Yes [ ] No 
NCCI-PPC-
At the preceding side, receiving and processing a setup request for a Point-to-Point call containing a NCCI , and discarding the NCCI? 
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the preceding side, receiving and processing a setup request for a Point-to-Point call not containing a NCCI, and assigning a NCCI? 
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the preceding side, receiving and processing a CONNECT message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE ?
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE?
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, discarding the NCCI IE and assigning a new NCCI ?
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Point call not containing a NCCI IE, and assigning a NCCI? 
M

4.2.1
[ ]Yes [ ]No
NCCI-PPC-
At the succeeding side, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

4.2.1
[ ]Yes [ ]No
Comments:







Table 3: NCCI capabilities for Point-to-Point calls (AINI)

C.7 NCCI procedures for Point-to-Point calls
Prerequisite: NCCI-PP
Item
Procedures for Point-to-Point  calls 
Does  the IUT ...
Status
Prerequisite
Reference
Support
NCCI-PPP-
At the preceding side, not assign a NCCI if a received setup request contains a NCCI ?  
M

4.2.1
[ ]Yes [ ]No
NCCI-PPP-
At the succeeding side, insert the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if a NCCI was assigned by this node during the setup phase? 
O

4.2.1
[ ] Yes [ ] No 
NCCI-PPP-
At the succeeding side, not include the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if no NCCI was assigned by this node during the setup phase?
M

4.2.1
[ ] Yes [ ] No 
NCCI-PPP-
Guarantee a unique NCCI value for all Point-to-Point connections that are assigned a NCCI at that location over a sufficiently long period of time ?
M

4.2.1
[ ]Yes  [ ]No
Comments:







Table 4: NCCI procedures for Point-to-Point calls (AINI)

C.8 
NCCI capabilities for Point-to-Multipoint calls
Prerequisite: NCCI-PM
Item
Capabilities for Point-to-Multipoint calls :
Is the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PMC-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PMC-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VPC ?
M
OPT_6/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PMC-
Assigning a NCCI when establishing a call for a Point-to-Multipoint Soft PVC ?
M
OPT_7/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PMC-
Assigning a NCCI when establishing a call for a Point-to-Multipoint Soft PVP ?
M
OPT_7/PNNI Errata & PICS
1.1
[ ]Yes [ ]No
NCCI-PMC- 
At the preceding side, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

4.2.2.1
[ ] Yes [ ] No 
NCCI-PMC-
At the preceding side, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the preceding side, receiving and processing a setup request for a Point-to-Multipoint call not containing a NCCI, and assigning a NCCI ? 
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC- 
At the preceding side, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

4.2.2.1, 4.2.2.2
[ ] Yes [ ] No 
NCCI-PMC-
At the preceding side, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

4.2.2.1, 4.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the preceding side, receiving and processing an add party request for a Point-to-Multipoint call not containing a NCCI, and inserting in the ADD PARTY message forwarded to the succeeding node the same NCCI as assigned in the SETUP message? 
M

4.2.2.1, 4.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the preceding side, receiving and processing a CONNECT message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI IE ?
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI?
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, discarding the NCCI and assigning a new NCCI?
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing a SETUP message for a Point-to-Multipoint call not containing a NCCI IE, and assigning a NCCI ? 
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI ?
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, receiving and processing an ADD PARTY message for a Point-to-Multipoint call, and inserting in the add party indication forwarded to the preceding side of the next interface the same NCCI as assigned in the setup indication? 
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMC-
At the succeeding side, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMC-
Storing the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

4.2.3
[ ]Yes [ ]No
Comments:


Table 5: NCCI capabilities for Point-to-Multipoint calls (AINI)

C.9 NCCI procedures for Point-to-Multipoint calls
Prerequisite: NCCI-PM
Item
Procedures for Point-to-Multipoint calls :
Does  the IUT...
Status
Prerequisite
Reference
Support
NCCI-PMP-
At the preceding side, convert an add party request into a SETUP message by following the procedures of section 4.2.2.1?
M

4.2.2.1
[ ]Yes  [ ] No
NCCI-PMP-
At the preceding side, not assign a NCCI when receiving a setup request containing a NCCI ?  
M

4.2.2.1
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, forward the NCCI IE as received if a received add party request contains a NCCI and the initial setup request contained a NCCI which was forwarded?
M

4.2.2.2
[ ]Yes  [ ] No
NCCI-PMP-
At the preceding side, not include any NCCI IE in subsequent ADD PARTY messages if the initial SETUP message did not contain a NCCI IE?  
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the preceding side, if a NCCI was assigned and contained in the initial SETUP message, include the NCCI IE in all subsequent ADD PARTY messages ?  
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the succeeding side, forward the NCCI  as received if the initial SETUP message contained a NCCI IE which has been forwarded?
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the succeeding side, not include any NCCI in subsequent add party indications if the initial setup indication did not contain a NCCI?
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
At the succeeding side, if a NCCI was assigned and contained in the initial request, include the NCCI in all subsequent add party request?  
M

4.2.2.2
[ ]Yes [ ]No
NCCI-PMP-
Store the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

4.2.3
[ ]Yes [ ]No
NCCI-PMP-
Guarantee a unique NCCI value for all Point-to-Multipoint calls that are assigned a NCCI at that location over a sufficiently long period of time ?
M

4.2.2.1
[ ]Yes  [ ]No
Comments:


Table 6: NCCI procedures for Point-to-Multipoint calls (AINI)

Annnex D. 
NCCI PICS Proforma for UNI v4.0
D.1 Introduction
To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options that have been implemented.  Such a statement is called a Protocol Implementation Conformance Statement (PICS).
D.1.1 Scope
This document provides the PICS proforma for the Network Call Correlation Identifier v1.0 for UNI v4.0, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2[2].  In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS.
D.1.2 Normative References
[1]	ISO/IEC 9646-1:1994, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 1: General Concepts. (See also ITU Recommendation X.290(1995)).
[2]	ISO/IEC 9646-2:1994, Information technology - Open systems interconnection - Conformance testing methodology and interconnection - Part 2: Abstract test suite specification. (See also ITU Recommendation X.291(1995)).
[3]	ATM User-Network Interface (UNI) Signalling Specification, ATM Forum af-sig-0061.000, July 1996
D.1.3 Definitions
This document uses the following terms defined in ISO/IEC 9646-1[1]:
* A Protocol Implementation Conformance Statement (PICS) is a statement  made by the supplier of an implementation or system, stating which capabilities have been implemented for a given protocol.
* A PICS proforma is a document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite specifier, which when completed for an implementation or system becomes the PICS.
D.1.4 Acronyms
IE
Information Element
IUT
Implementation Under Test
M
Mandatory requirements (these are to be observed in all cases)
O	
Optional (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)
NCCI
Network Call Correlation Identifier
O.n
Optional, but support is required for either at least one or only one of the options in the group labeled with the same numeral "n".
PICS
Protocol Implementation Conformance Statement
D.1.5 Conformance
The supplier of a protocol implementation which is claimed to conform to the ATM Forum Network Call Correlation Identifier v1.0 for UNI v4.0 is required to complete a copy of the PICS proforma provided in this document and is required to provide the information necessary to identify both the supplier and the implementation.
D.2 
Identification of the Implementation
Implementation Under Test (IUT) Identification
IUT Name: ____________________________________________________________________
IUT Version: __________________________________________________________________
______________________________________________________________________________
System Under Test (SUT) Identification
SUT Name: ___________________________________________________________________
Hardware Configuration: _________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Operating System: ______________________________________________________________
Product Supplier
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________

Client
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _______________________________________________________________
Additional Information: __________________________________________________________
PICS Contact Person
Name: ________________________________________________________________________
Address: ______________________________________________________________________
______________________________________________________________________________
Telephone Number: _____________________________________________________________
Facsimile Number: ______________________________________________________________
Email Address: _________________________________________________________________
Additional Information: __________________________________________________________
PICS/System Conformance Statement
Provide the relationship of the PICS with the System Conformance Statement for the system: 
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
Identification of the protocol
This PICS proforma applies to the following:
* ATM Forum Network Call Correlation Identifier v1.0 for UNI v4.0.
D.3 
PICS Proforma
D.3.1 Global statement of conformance
The implementation described in this PICS meets all of the mandatory requirements of the reference protocol.

[ ] YES
[ ] NO

Note:   Answering "No" indicates non-conformance to the specified protocol.   Non-supported mandatory capabilities are to be identified in the following tables, with an explanation by the implementor explaining why the implementation is non-conforming.
D.3.2 Instructions for Completing the PICS Proforma
The PICS Proforma is a fixed-format questionnaire.  Answers to the questionnaire should be provided in the rightmost columns, either by simply indicating a restricted choice (such as Yes or No), or by entering a value or a set of range of values.
A supplier may also provide additional information, categorized as exceptional or supplementary information.  These additional information should be provided as items labeled X.<i> for exceptional information, or S.<i> for supplemental information, respectively, for cross reference purposes, where <i> is any unambiguous identification for the item.  The exception and supplementary information are not mandatory and the PICS is complete without such information.  The presence of optional supplementary or exception information should not affect test execution, and will in no way affect interoperability verification.  The column labeled 'Reference' gives a pointer to sections of the protocol specification for which the PICS Proforma is being written.

D.4 Roles
Item
Roles
Does the IUT of the NCCI addendum to UNI  support ...
Status
Prerequisite
Reference
Support
NCCI-PP-U
The NCCI feature for Point-to-Point calls at the user side?
O.1

1.1
[ ]Yes [ ]No
NCCI-PP-N
The NCCI feature for Point-to-Point calls at the network side?
O.1

1.1
[ ]Yes [ ]No
NCCI-PM-U
The NCCI feature for Point-to-Multipoint calls at the user side?
O.2
UNI / (Note 1)
1.1
[ ]Yes [ ]No
NCCI-PM-N
The NCCI feature for Point-to-Multipoint calls at the network side?
O.2
UNI
1.1
[ ]Yes [ ]No
Comments: 
Note 1: Provided that the support for Point-to-Multipoint calls is implemented at the UNI. 
O.1: Mandatory to support one of these roles
O.2: Mandatory to support one of these roles



Table 1: Roles

D.5 NCCI encoding

Item
NCCI formats and encoding
Is the IUT capable of...
Status
Prerequisite
Reference
Support
NCCI-E-
Generating a NCCI information element as described in Figure 2-1?
M

2, 5.2.1, 5.2.2
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the IE instruction field flag set to 1?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with the IE action indicator set to "Discard information element and proceed"?
O

7
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with a NCCI value in a AESA-based format ?
O.1

2, 5.2.1, 5.2.2
[ ]Yes [ ]No
NCCI-E-
Generating a NCCI information element with a NCCI value in a B-ISUP format ?
O.1

2, 5.2.1, 5.2.2
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a SETUP message ?
M

5.1.1
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in an ADD PARTY message ?
M
NCCI-PM-N, NCCI-PM-U
5.1.2
[ ]Yes [ ]No
NCCI-E-
Including one NCCI information element in a CONNECT message ?
M

5.1.3
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a SETUP message ?
M

5.1.1
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in an ADD PARTY message ?
M
NCCI-PM-N, NCCI-PM-U
5.1.2
[ ]Yes [ ]No
NCCI-E-
Including no more than one NCCI information elements in a CONNECT message ?
M

5.1.3
[ ]Yes [ ]No
Comments:
O.1. = mandatory to support one of these NCCI formats.







Table 2: NCCI encoding (UNI)

D.6 NCCI capabilities for Point-to-Point calls at the user side
Prerequisite: NCCI-PP-U
Item
Capabilities for Point-to-Point calls
Is  the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PPC-U-
Assigning a NCCI when establishing a call for a Point-to-Point VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PPC-U-
Assigning a NCCI when establishing a call for a Point-to-Point VPC ?
 M

1.1
[ ]Yes [ ]No
NCCI-PPC-U- 
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Point call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.1.1
[ ] Yes [ ] No 
NCCI-PPC-U-
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Point call containing a NCCI, and discarding the NCCI? 
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Point call not containing a NCCI, and assigning a NCCI? 
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the originating interface, receiving and processing a CONNECT message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE ?
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE?
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, discarding the NCCI IE and assigning a new NCCI ?
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Point call not containing a NCCI IE, and assigning a NCCI? 
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-U-
At the user side of the destination interface, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

5.2.1.2
[ ]Yes [ ]No
Comments:







Table 3: NCCI capabilities for Point-to-Point calls (UNI - user side)

D.7 NCCI procedures for Point-to-Point calls at the user side
Prerequisite: NCCI-PP-U
Item
Procedures for Point-to-Point  calls 
Does  the IUT ...
Status
Prerequisite
Reference
Support
NCCI-PPP-U-
At the user side of the originating interface, not assign a NCCI if a received setup request contains a NCCI ?  
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPP-U-
At the user side of the destination interface, insert the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if a NCCI was assigned by this node during the setup phase? 
O

5.2.1.2
[ ] Yes [ ] No 
NCCI-PPP-U-
At the user side of the destination interface, not include the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if no NCCI was assigned by this node during the setup phase?
M

5.2.1.2
[ ] Yes [ ] No 
NCCI-PPP-U-
Guarantee a unique NCCI value for all Point-to-Point connections that are assigned a NCCI at that location over a sufficiently long period of time ?
M

5.2.1.1, 5.2.1.2
[ ]Yes  [ ]No
Comments:







Table 4: NCCI procedures for Point-to-Point calls (UNI - user side)
D.8 
NCCI capabilities for Point-to-Multipoint calls at the user side
Prerequisite: NCCI-PM-U
Item
Capabilities for Point-to-Multipoint calls :
Is the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PMC-U-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PMC-U-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VPC ?
M

1.1
[ ]Yes [ ]No
NCCI-PMC-U- 
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.2.1.1
[ ] Yes [ ] No 
NCCI-PMC-U-
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the originating interface, receiving and processing a setup request for a Point-to-Multipoint call not containing a NCCI, and assigning a NCCI ? 
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-U- 
At the user side of the originating interface, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.2.1.1, 5.2.2.1.2
[ ] Yes [ ] No 
NCCI-PMC-U-
At the user side of the originating interface, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

5.2.2.1.1, 5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the originating interface, receiving and processing an add party request for a Point-to-Multipoint call not containing a NCCI, and inserting in the ADD PARTY message forwarded to the succeeding node the same NCCI as assigned in the SETUP message? 
M

5.2.2.1.1, 5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the originating interface, receiving and processing a CONNECT message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE ?
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI?
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, discarding the NCCI and assigning a new NCCI?
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing a SETUP message for a Point-to-Multipoint call not containing a NCCI IE, and assigning a NCCI ? 
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI ?
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call, and inserting in the add party indication forwarded to the preceding side of the next interface the same NCCI as assigned in the setup indication? 
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMC-U-
At the user side of the destination interface, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-U-
Storing the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

5.2.3
[ ]Yes [ ]No
Comments:


Table 5: NCCI capabilities for Point-to-Multipoint calls (UNI - user side)

D.9 NCCI procedures for Point-to-Multipoint calls at the user side
Prerequisite: NCCI-PM-U
Item
Procedures for Point-to-Multipoint calls :
Does  the IUT...
Status
Prerequisite
Reference
Support
NCCI-PMP-U-
At the user side of the originating interface, convert an add party request into a SETUP message by following the procedures of section 5.2.2.1.1?
M

5.2.2.1.1
[ ]Yes  [ ] No
NCCI-PMP-U-
At the user side of the originating interface, not assign a NCCI when receiving a setup request containing a NCCI ?  
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMP-U-
At the user side of the originating interface, forward the NCCI IE as received if a received add party request contains a NCCI and the initial setup request contained a NCCI which was forwarded?
M

5.2.2.1.2
[ ]Yes  [ ] No
NCCI-PMP-U-
At the user side of the originating interface, not include any NCCI IE in subsequent ADD PARTY messages if the initial SETUP message did not contain a NCCI IE?  
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMP-U-
At the user side of the originating interface, if a NCCI was assigned and contained in the initial SETUP message, include the NCCI IE in all subsequent ADD PARTY messages ?  
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMP-U-
At the user side of the destination interface, forward the NCCI as received if the initial SETUP message contained a NCCI IE which has been forwarded?
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMP-U-
At the user side of the destination interface, not include any NCCI in subsequent add party indications if the initial setup indication did not contain a NCCI?
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMP-U-
At the succeeding side, if a NCCI was assigned and contained in the initial request, include the NCCI in all subsequent add party request?  
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMP-U-
Store the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

5.2.3
[ ]Yes [ ]No
NCCI-PMP-U-
Guarantee a unique NCCI value for all Point-to-Multipoint calls that are assigned a NCCI at that location over a sufficiently long period of time ?
M

5.2.2.1.1, 5.2.2.2.1
[ ]Yes  [ ]No
Comments:


Table 6: NCCI procedures for Point-to-Multipoint calls (UNI - user side)

D.10 NCCI capabilities for Point-to-Point calls at the network side
Prerequisite: NCCI-PP-N
Item
Capabilities for Point-to-Point calls
Is  the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PPC-N-
Assigning a NCCI when establishing a call for a Point-to-Point VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PPC-N-
Assigning a NCCI when establishing a call for a Point-to-Point VPC ?
M

1.1
[ ]Yes [ ]No
NCCI-PPC-N- 
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Point call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.1.2
[ ] Yes [ ] No 
NCCI-PPC-N-
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Point call containing a NCCI, and discarding the NCCI? 
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Point call not containing a NCCI, and assigning a NCCI? 
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the destination interface, receiving and processing a CONNECT message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE ?
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE?
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Point call containing a NCCI IE, discarding the NCCI IE and assigning a new NCCI ?
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Point call not containing a NCCI IE, and assigning a NCCI? 
M

5.2.1.1
[ ]Yes [ ]No
NCCI-PPC-N-
At the network side of the originating interface, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

5.2.1.1
[ ]Yes [ ]No
Comments:







Table 7: NCCI capabilities for Point-to-Point calls (UNI - network side)

D.11 NCCI procedures for Point-to-Point calls at the network side
Prerequisite: NCCI-PP-N
Item
Procedures for Point-to-Point  calls 
Does  the IUT ...
Status
Prerequisite
Reference
Support
NCCI-PPP-N-
At the network side of the destination interface, not assign a NCCI if a received setup request contains a NCCI ?  
M

5.2.1.2
[ ]Yes [ ]No
NCCI-PPP-N-
At the network side of the originating interface, insert the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if a NCCI was assigned by this node during the setup phase? 
O

5.2.1.1
[ ] Yes [ ] No 
NCCI-PPP-N-
At the network side of the originating interface, not include the NCCI in the CONNECT message prior to progressing the message towards the preceding side, if no NCCI was assigned by this node during the setup phase?
M

5.2.1.1
[ ] Yes [ ] No 
NCCI-PPP-N-
Guarantee a unique NCCI value for all Point-to-Point connections that are assigned a NCCI at that location over a sufficiently long period of time ?
M

5.2.1.1, 5.2.1.2
[ ]Yes  [ ]No
Comments:







Table 8: NCCI procedures for Point-to-Point calls (UNI - network side)

D.12 
NCCI capabilities for Point-to-Multipoint calls at the network side
Prerequisite: NCCI-PM-N
Item
Capabilities for Point-to-Multipoint calls :
Is the IUT capable of ...
Status
Prerequisite
Reference
Support
NCCI-PMC-N-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VCC ?
M

1.1
[ ]Yes [ ]No
NCCI-PMC-N-
Assigning a NCCI when establishing a call for a Point-to-Multipoint VPC ?
M

1.1
[ ]Yes [ ]No
NCCI-PMC-N- 
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.2.2.1
[ ] Yes [ ] No 
NCCI-PMC-N-
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the destination interface, receiving and processing a setup request for a Point-to-Multipoint call not containing a NCCI, and assigning a NCCI ? 
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-N- 
At the network side of the destination interface, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and forwarding the NCCI IE to the succeeding node as received? 
M

5.2.2.2.1, 5.2.2.2.2
[ ] Yes [ ] No 
NCCI-PMC-N-
At the network side of the destination interface, receiving and processing an add party request for a Point-to-Multipoint call containing a NCCI, and discarding the NCCI? 
M

5.2.2.2.1, 5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the destination interface, receiving and processing an add party request for a Point-to-Multipoint call not containing a NCCI, and inserting in the ADD PARTY message forwarded to the succeeding node the same NCCI as assigned in the SETUP message? 
M

5.2.2.2.1, 5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the destination interface, receiving and processing a CONNECT message for a Point-to-Point call containing a NCCI IE, and discarding the NCCI IE ?
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI?
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Multipoint call containing a NCCI IE, discarding the NCCI and assigning a new NCCI?
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing a SETUP message for a Point-to-Multipoint call not containing a NCCI IE, and assigning a NCCI ? 
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE and forwarding the NCCI IE to the preceding side of the next interface as received ?
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call containing a NCCI IE, and discarding the NCCI ?
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, receiving and processing an ADD PARTY message for a Point-to-Multipoint call, and inserting in the add party indication forwarded to the preceding side of the next interface the same NCCI as assigned in the setup indication? 
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMC-N-
At the network side of the originating interface, returning the NCCI assigned by this node in the CONNECT message for a Point-to-Point call ?
M

5.2.2.1.1
[ ]Yes [ ]No
NCCI-PMC-N-
Storing the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

5.2.3
[ ]Yes [ ]No
Comments:


Table 9: NCCI capabilities for Point-to-Multipoint calls (UNI - network side)

D.13 NCCI procedures for Point-to-Multipoint calls at the network side
Prerequisite: NCCI-PM-N
Item
Procedures for Point-to-Multipoint calls :
Does  the IUT...
Status
Prerequisite
Reference
Support
NCCI-PMP-N-
At the network side of the destination interface, convert an add party request into a SETUP message by following the procedures of section 5.2.2.2.1?
M

5.2.2.2.1
[ ]Yes  [ ] No
NCCI-PMP-N-
At the network side of the destination interface, not assign a NCCI when receiving a setup request containing a NCCI ?  
M

5.2.2.2.1
[ ]Yes [ ]No
NCCI-PMP-N-
At the network side of the destination interface, forward the NCCI IE as received if a received add party request contains a NCCI and the initial setup request contained a NCCI which was forwarded?
M

5.2.2.2.2
[ ]Yes  [ ] No
NCCI-PMP-N-
At the network side of the destination interface, not include any NCCI IE in subsequent ADD PARTY messages if the initial SETUP message did not contain a NCCI IE?  
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMP-N-
At the network side of the destination interface, if a NCCI was assigned and contained in the initial SETUP message, include the NCCI IE in all subsequent ADD PARTY messages ?  
M

5.2.2.2.2
[ ]Yes [ ]No
NCCI-PMP-N-
At the network side of the originating interface, forward the NCCI as received if the initial SETUP message contained a NCCI IE which has been forwarded?
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMP-N-
At the originating interface, not include any NCCI in subsequent add party indications if the initial setup indication did not contain a NCCI?
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMP-N-
At the succeeding side, if a NCCI was assigned and contained in the initial request, include the NCCI in all subsequent add party request?  
M

5.2.2.1.2
[ ]Yes [ ]No
NCCI-PMP-N-
Store the NCCIs associated with Point-to-Multipoint calls when assigned by this implementation?
M

5.2.3
[ ]Yes [ ]No
NCCI-PMP-N-
Guarantee a unique NCCI value for all Point-to-Multipoint calls that are assigned a NCCI at that location over a sufficiently long period of time ?
M

5.2.2.1.1, 5.2.2.2.1
[ ]Yes  [ ]No
Comments:


Table 10: NCCI procedures for Point-to-Multipoint calls (UNI - network side)

Appendix A. 
B-ISUP NCCI format 
[Informative]
As shown in Figure A-1 the B-ISUP NCCI format consists of a string of 9 octets. The B-ISUP NCCI is specified in ITU-T Recommendation Q.2726.3 [5] and is divided in three parts:
Network Identifier	The network identifier consists of a 0 followed by 3 digits representing an E.164 country code padded, if necessary, on the right with 0s (2 octets of 4 BCD digits).
Point Code	The point code contains the SS7 point code of the node where the NCCI is assigned (3 octets). 
Call Identifier	The call identifier is locally unique at the point where the NCCI is assigned to the connection. The semantic of this field are determined by the assigning entity, however the values chosen shall be such as to guarantee a unique value for all connections that are assigned a NCCI at that location (as identified by the network identifier and the point code) over a long period of time (4 octets). 

Net. Id.
(2 octets)
Point Code
(3 octets)
Call Identifier
(4 octets)
Figure A-1 Format of a B-ISUP Network Call Correlation Identifier (9 octets)
Appendix B. Example of NCCIs correlation between private and ATM Service Provider networks
[Informative]
It is desirable to use a single NCCI end-to-end. However, in the case that certain ATM networks (private or public) assign their own NCCIs, then it is useful to be able to correlate these NCCIs. The intent of this annex is to describe a possible way of correlating different NCCIs end-to-end between the private and public networks. The ability to correlate NCCIs shown in this example will only work when there is a single ASP between private networks "S" and "T" or when there are multiple ASPs between private networks "S" and "T" that share the same NCCI. The following Figure B-1 is used as an example.

Figure B-1 Example of the networks interconnection when transporting NCCIs
1. The ingress edge switch (i.e. connecting to UNI "A") of the Private Network "S" assigns  its own NCCI-S which is propagated to its egress edge switch (i.e. connecting to AINI "X").  However, the NCCI-S is not forwarded to the network side of the AINI "X".
2. The ingress edge switch (i.e. connecting to AINI "X") of the ASP  Network "W" assigns its own NCCI-W which is propagated to its egress edge switch (i.e. connecting to UNI "Y").  The NCCI-W is forwarded to the user side of the UNI "Y" via the SETUP message.
3. The ingress edge switch (i.e. connecting to UNI "Y") of the Private Network "T" recorded the NCCI-W and makes an association with its own NCCI-T which is used to replace the NCCI-W in the SETUP message. The NCCI-T is then propagated to the egress edge switch (i.e. connecting to UNI "B").
4. When the CONNECT message is returned, no NCCI is included in the message at UNI "B" and UNI "Y".
5. The ingress edge switch of the ASP Network "W" inserts the NCCI-W in the CONNECT message prior to progressing the CONNECT message to the user side of the AINI "X".
6. When the Private Network "S" receives the CONNECT message, it associates the NCCI-W with the NCCI-S.
7. By using the NCCI-W, the Private Network "S" and Private Network "T" can correlate the accounting records with their own NCCIs.
AF-CS-0140.000	Network Call Correlation Identifier v1.0
March, 2000

AF-CS-0140.000	Network Call Correlation Identifier v1.0
March, 2000

Page 30 of 61	ATM Technical Committee

Page 29 of 61	ATM Technical Committee