Technical Committee

PNNI SPVC Addendum
version 1.0

AF-CS-0127.000


July, 1999


(c) 1999  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

TABLE OF CONTENTS
1. INTRODUCTION	
2. ADDITIONS TO PNNI SIGNALLING MESSAGES	
3. INFORMATION ELEMENTS	
4. PROCEDURES FOR SPVC	
5. COMPATIBILITY WITH NODES NOT SUPPORTING THIS FEATURE	
6. SPVC MIB CHANGES	
7. PROTOCOL IMPLEMENTATION CONFORMANCE STATEMENT (PICS)	
7.1 ROLES	
7.2 MAJOR CAPABILITIES	
7.2.1 Information Element Encoding	
7.2.2 SPVC procedures for Point-to-Point connections	
8. REFERENCES	



1.	Introduction
This document is an optional addendum to PNNIv1.0. It contains modifications to sections 6.4.6/PNNI 1.0 "Information elements specific to PNNI" and Annex C/PNNI 1.0 "Soft Permanent Virtual Connection Procedures".
The enhanced functionality specified by this addendum is as follows:
1.  The ability to originate and/or terminate an SPVC on a frame relay endpoint.
2.  Enhanced error handling procedures
3.  Renaming the VPI field of  SPVC information elements to "VPCI" and allowing use of the full 16-bit field.  This was done to promote alignment with B-ISUP.
Only those portions of section 6.4.6/PNNI 1.0 and of Annex C/PNNI1.0 which are modified are shown in this addendum.
2.	Additions to PNNI Signalling MESSAGES
No changes are required to existing messages.
3.	Information Elements
This section describes the modifications required to the Calling and Called party soft PVPC or PVCC information element formats specified  in section 6.4.6.1/PNNI 1.0 and 6.4.6.2/PNNI 1.0.  The changes are shown by revision marks.
Throughout sections 6.4.6.1/PNNI 1.0 and 6.4.6.2/PNNI 1.0, make the following changes:
* Change VPI to VPCI
* Change Virtual Path Identifier to Virtual Path Connection Identifier


6.4.6.1/PNNI 1.0   Calling party soft PVPC or PVCC



8
7
6
5
4
3
2
1
Octet
Calling party soft PVPC or PVCC

1
1
1
0
0
0
1
1
  1
Information element identifier

1
ext
Coding
standard

IE Instruction Field




  2
Length of calling party soft PVPC or PVCC contents







  3
Length of calling party soft PVPC or PVCC contents (continued)







  4
1
0
0
0
0
0
0
1
  5*  (Note 5)
VPCI identifier







  

VPCI value

  5.1*



  5.2*
1
0
0
0
0
0
1
0
 6*  (Note 1,5)
VCI identifier







  

VCI value

  6.1*



  6.2*
1
0
0
0
0
0
1
1
7* (Note 1,2,5)
DLCI Identifier

0
0
DLCI
7.1*


(Most significant 6 bits)

Ext
Spare


0/1
DLCI
0
0
0
7.2*

(2nd most significant 4 bits)
Spare

Ext



1
DLCI
0
7.3* (Note 3)

(3rd most significant 6 bits)


Ext

Resrv

0
DLCI
7.3* (Note 4)

(3rd most significant 7 bits)

Ext


1
DLCI
0
7.4* (Note 4)

(4th most significant 6 bits)


Ext

Resrv


Note 1 - This octet group is only present in case of a soft PVCC.
Note 2 - The DLCI is 2 or 3 or 4 octets (i.e. 10 or 16 or 23 bits respectively). The standard default length of the DLCI is two octets.  The extension bit mechanism is used to indicate non-default length and thus to determine the total length of the DLCI.
Note 3 - This octet shall only be included when bilateral agreements between the nodes which are endpoints of the SPVC allow a 3-octet DLCI (16 bits).
Note 4 - These octets shall both be included only when bilateral agreements between the nodes which are endpoints of the SPVC allow a 4-octet DLCI (23 bits).
Note 5 - When octet group 7 is present neither octet group 5 nor octet group 6 may be present.
Figure 3-1  Calling party soft PVPC or PVCC Information elementApply the following changes:

VPCI value (octets 5.1 and 5.2)

A two octet binary number assigned to the ATM connection representing the identifier of the Virtual Path Connection Identifier.  The VPCI value is meaningful to the destination node and can have any two octet value.

6.4.6.2/PNNI 1.0  Called party soft PVPC or PVCC


8
7
6
5
4
3
2
1
Octet
Called party soft PVPC or PVCC

1
1
1
0
0
0
0
0
  1
Information element identifier

1
ext
Coding
standard

IE Instruction Field




  2
Length of called party soft PVPC or PVCC contents







  3
Length of called party soft PVPC or PVCC contents (continued)







  4
Selection type







  5
1
0
0
0
0
0
0
1
  6* (Note 1)
VPCI identifier







  

VPCI value

  6.1*



  6.2*
1
0
0
0
0
0
1
0
 7*  (Note 1,2)
VCI identifier







  

VCI value

  7.1*








  7.2*
1
0
0
0
0
0
1
1
8* (Note 1,2,3)
DLCI Identifier

0
0
DLCI
8.1*


(Most significant 6 bits)

Ext
Spare


0/1
DLCI
0
0
0
8.2*

(2nd most significant 4 bits)
Spare

Ext



1
DLCI
0
8.3* (Note 4)

(3rd most significant 6 bits)


Ext

Resrv

0
DLCI


(3rd most significant 7 bits)
8.3* (Note 5)
Ext


1
DLCI
0
8.4* (Note 5)

(4th most significant 6 bits)


Ext

Resrv


Note 1 - This octet group is not included when the selection type indicates "any value".  If present, it shall be ignored. When the selection type is coded as "required value" or "assigned value", either octet group 6-7 (ATM endpoint) or 8 (frame relay endpoint) may be included but not both.Note  2 - This octet group is only present in case of a soft PVCC.
Note 3 - The DLCI is 2 or 3 or 4 octets (i.e. 10 or 16 or 23 bits respectively). The standard default length of the DLCI is two octets.  The extension bit mechanism is used to indicate non-default length and thus to determine the total length of the DLCI.
Note 4 - This octet shall only be included when bilateral agreements between the nodes which are endpoints of the SPVC allow a 3-octet DLCI (16 bits).
Note 5 - These octets shall both be included only when bilateral agreements between the nodes which are endpoints of the SPVC allow a 4-octet DLCI (23 bits).

Figure 3-2 Called party soft PVPC or PVCC Information element

Apply the following changes:

VPCI value (octets 6.1 and 6.2)

A two octet binary number assigned to the ATM connection representing the identifier of the Virtual Path Connection Identifier.  The VPCI value is meaningful to the destination node and can have any two octet value. 

4.	Procedures for SPVC
This section describes modifications to the SPVC procedures. All changes are shown as revision marks.
Throughout Annex C/PNNI 1.0, make the following changes:
* Change VPI to VPCI
* Change Virtual Path Identifier to Virtual Path Connection Identifier
 
9.  Annex C/PNNI 1.0  Soft Permanent Virtual Connection Procedures
Paragraph one is modified as shown:
This Annex describes the procedures for establishment of soft Permanent Virtual Connections which are established by management action.  Both permanent virtual channel connection (PVCC) and permanent virtual path connections (PVPC) are supported at the PNNI. PVCC connections can connect cell relay and/or frame relay endpoints. PVPC connections can connect cell relay endpoints only..   Soft PVCCs can be established between cell relay endpoints, frame relay endpoints or between a cell relay and frame relay endpoint.  Note that the SPVC can be originated from or terminated at either the cell or frame relay endpoint.  Soft PVPCs can be established only between cell relay endpoints.  These relationships are shown in the following table.

Connection Type
To/From 
Cell Relay Endpoint
To/From
Frame Relay Endpoint
VCC
Supported
Supported
VPC
Supported
Not Supported

Paragraph four is modified as shown:
Before a soft PVPC/PVCC can be established, there must be a means to uniquely identify the endpoints of the PVPC/PVCC.  The identity of the calling endpoint is encoded in the Calling party number information element.  The Called party of the soft PVPC/PVCC identifies the network interface at the destination network node.  The network management system provides the ATM addresses of the endpoints of a soft PVPC/PVCC as well as information about the VPCI/VCI  or frame relay DLCI values to be used at the two endpoints.


9.2/PNNI 1.0  Procedures for point-to-point soft PVPC/PVCCs

9.2.1/PNNI 1.0  Initiating PVPC/PVCC establishment
Paragraph two is modified as shown:

A Bearer Class of VP or X is included in the Broadband bearer capability which identifies establishment of a VPC or a VCC, respectively, between the connecting points.  To identify the VPCI/VCI or frame relay DLCI of the PVPC/PVCC at the destination network node,  the Called party soft PVPC/PVCC information element, coded as shown in Figure 3-2 shall be included in the SETUP message.  The Called party number information element shall contain the configured peer PVPC/PVCC connecting point identifier, and the calling party number information element shall contain the PVPC/PVCC connecting point's own identifier.
When sending the Called or Calling party soft PVPC/PVCC information element, the instruction flag field (bit 5 of octet 2) shall be set to "follow explicit instruction", the action indicator (bits 1-3 of octet 2) shall be set to "clear call", and the pass along request flag (bit 4 of octet 2) shall be set to "pass along request".

9.2.2/PNNI 1.0  Receiving a CONNECT message at the calling NI
Paragraph one  is modified as shown:

When the originating node receives a CONNECT message, it puts the PVPC/PVCC in an operational state.  If the CONNECT message contains the Called party soft PVPC/PVCC information element, the VPCI or VPCI/VCI or DLCI values of the PVPC/PVCC segment between the called connecting point and the user will be passed to the management entity.


9.2.3/PNNI 1.0  Receiving a SETUP message at the called NI
Add the following text after the first paragraph (see section 1.4):
If the called party number identifies a cell relay network interface and the Called party soft PVPC or PVCC information element specifies a DLCI, or the called party number identifies a frame relay network interface and the Called party soft PVPC or PVCC information element specifies a VPCI/VCI, the call shall be cleared by sending a RELEASE COMPLETE message with cause #88 "incompatible destination".

9.2.3.1/PNNI 1.0  Last PVPC segment VPCI allocation/selection
Replace the contents of the section with the following:
The calling connecting point shall indicate one of the following for the called endpoint of soft PVPCs:
a)	Any VPCI;
b)	Required VPCI.

In case a), the called connecting point selects any available VPCI.  If no VPCI value is available, the call shall be cleared by sending a RELEASE COMPLETE message with ITU-T specific cause #34 "no circuit/channel available".  If a VPCI value is specified in the Called party soft PVPC/PVCC information element, the value shall be ignored.  The selected VPCI value shall be returned in the Called party soft PVPC/PVCC information element in the CONNECT message.  The selection type field shall be coded as "assigned value".
In case b), if the indicated VPCI is available, the called connecting point selects it for the call.  The Called party soft PVPC/PVCC information element may be returned in the CONNECT message with the selection type field coded as "assigned value".  If the VPCI is not available, a RELEASE COMPLETE message with PNNI specific cause #34, "requested called party soft PVPC/PVCC not available", shall be sent.  If the Called party soft PVPC/PVCC information element does not specify a VPCI, a RELEASE COMPLETE message with cause #100 "Invalid information element contents" shall be sent.
9.2.3.2/PNNI 1.0  Last PVCC segment VPCI/VCI allocation/selection
Replace the contents of the section with the following:
The calling connecting point shall indicate one of the following for the called endpoint of soft PVCCs:
a)	Any VPCI; any VCI;
b)	Required VPCI; required VCI.

In case a), the called connecting point selects any available VPCI/VCI.  If no VPCI/VCI value is available, the call shall be cleared by sending a RELEASE COMPLETE message with ITU-T specific cause #34, "no circuit/channel available". If a VPCI/VCI value is specified in the Called party soft PVPC/PVCC information element, the value shall be ignored. The selected VPCI/VCI value shall be indicated in the Called party soft PVPC/PVCC information element in the CONNECT message.  The selection field shall be coded as "assigned value".
In case b), if the indicated VPCI/VCI is available, the called connecting point selects it for the call. The Called party soft PVPC/PVCC information element may be returned in the CONNECT message with the selection type field coded as "assigned value".  If the VPCI/VCI is not available, a RELEASE COMPLETE message with cause #34, "requested called party soft PVPC/PVCC not available", shall be sent.  If the Called party soft PVPC/PVCC information element does not specify a VPCI/VCI, a RELEASE COMPLETE message with cause #100 "Invalid information element contents" shall be sent.

The following section is added for the support of frame relay endpoints.

9.2.3.3/PNNI 1.0  Last Frame Relay PVCC segment DLCI allocation/selection
The calling connecting point shall indicate one of the following for the called endpoint of frame relay soft PVCCs:
a)  Any DLCI;
b)  Required DLCI.
In case a), the called connecting point selects any available DLCI. If no DLCI value is available, the call shall be cleared by sending a RELEASE COMPLETE message with ITU-T specific cause #34  "no circuit/channel available". If a DLCI value is specified in the Called party soft PVPC/PVCC information element, the value shall be ignored.  The selected DLCI value shall be indicated in the Called party soft PVPC/PVCC information element in the CONNECT message. The selection field shall be coded as "assigned value".
In case b), if the indicated DLCI is available, the called connecting point selects it for the call. The Called party soft PVPC/PVCC information element may be returned in the CONNECT message with the selection type field coded as "assigned value".  If the requested DLCI is not available, a RELEASE COMPLETE message with PNNI specific cause #34 "requested called party  soft PVPC/PVCC not available" shall be sent. If the Called party soft PVPC/PVCC information element does not specify a DLCI, a RELEASE COMPLETE message with cause #100 "Invalid information element contents" shall be sent.

9.3/PNNI 1.0  Procedures for point-to-multipoint PVCCs
Add the following paragraph to the end of the section:
When sending the Called or Calling party soft PVPC/PVCC information element, the instruction flag field (bit 5 of octet 2) shall be set to "follow explicit instruction", the action indicator (bits 1-3 of octet 2) shall be set to "clear call", and the pass along request flag (bit 4 of octet 2) shall be set to "pass along request".

9.3.3.2.1/PNNI 1.0  Last PVCC segment VPCI/VCI allocation/selection
Replace the contents of the section with the following:
The calling connecting point shall indicate one of the following for the called endpoint of soft PVCCs:
a)	Any VPCI; any VCI;
b)	Required VPCI; required VCI.
In case a), the called connecting point selects any available VPCI/VCI.  If no VPCI/VCI value is available, the call shall be cleared by sending an ADD PARTY REJECT message with ITU-T specific cause #34, "no circuit/channel available".  If a VPCI/VCI value is specified in the Called party soft PVPC/PVCC information element, the value shall be ignored. The selected VPCI/VCI value shall be indicated in the Called party soft PVPC/PVCC information element in the ADD PARTY ACK message.  The selection field shall be coded as "assigned value".
In case b), if the indicated VPCI/VCI is available, the called connecting point selects it for the call.  The Called party soft PVPC/PVCC information element may be returned in the ADD PARTY ACK message with the selection type field coded as "assigned value".  If the VPCI/VCI is not available, an ADD PARTY REJECT message with PNNI specific cause #34, "requested called party soft PVPC/PVCC not available" shall be sent.  If the Called party soft PVPC/PVCC information element does not specify a VPCI/VCI, a RELEASE COMPLETE message with cause #100 "Invalid information element contents" shall be sent.
The following section is added.

9.4  Procedures at Intermediate Switches
The following procedures shall apply at switches between the two SPVC endpoints.
If a Calling or Called party soft PVPC/PVCC information element is received no content validation shall be performed on the information element, other than verifying the maximum information element length. If the maximum length of the Calling or Called party soft PVPC/PVCC information element is exceeded, a RELEASE COMPLETE or ADD PARTY REJECT message as appropriate with cause #100 "Invalid information element contents" shall be returned. 
If the call is progressed, the received Calling or Called party soft PVPC/PVCC information element shall be forwarded unchanged, provided the next interface is PNNI.
This allows for support of other endpoint types in the future, without having to upgrade intermediate nodes which do not support this other endpoint type.
5.	Compatibility with Nodes Not Supporting This Feature
This section describes how this feature operates in a network containing nodes that do not support this extension.
PNNIv1.0 specifies that the high order four bits of the VPI field in SPVC information elements must be zero.  PNNI nodes not supporting this feature might treat a received SPVC information element with a non-zero value in the high order four bits of the VPCI field as invalid contents (if a 12 bit value is enforced). Such a node would therefore reject the call as a result of having the action indicator (bits 1-3 of octet 2) set to "clear call".
Use of the DLCI octet group in the Calling and Called party soft PVPC and PVCC information elements to connect to or from a frame relay endpoint requires that all nodes along the path of the call which validate the content of these information elements support this feature.  This is due to the fact that the Calling and Called soft PVPC and PVCC information elements are already defined in PNNI1.0. Hence addition of the DLCI octet group defined in this addendum will result in the information element being treated as a recognized information element with invalid contents.
Therefore, the Calling and Called soft PVPC and PVCC information elements specifying a DLCI or a 16-bit VPCI shall be coded with the IE instruction flag field (bit 5 of octet 2) set to "follow explicit instruction", the action indicator (bits 1-3 of octet 2) set to "clear call", and the pass along request flag (bit 4 of octet 2) set to "pass along request".

6.	SPVC MIB Changes
This section is for information only to summarize the changes made to the SPVC MIB from the PNNI1.0 Errata and PICS [2].  The normative MIB text can be found in af-cs-0127.000.mib.txt.  This MIB builds upon RFC 2514 [3] and RFC 2515 [4], which comprise the updated version of the AtmMib.
The following objects are added to the atmSoftPVccEntry  of the SPVC MIB:


atmSoftPVccTargetDlci    OBJECT-TYPE
SYNTAX		Integer32
MAX-ACCESS		read-create
STATUS		current
DESCRIPTION
		"The DLCI value at the target Frame Relay interface.

		This value is not relevant when the value of 
atmSoftPVccTargetType is other than 'frameRelay' or
when the atmSoftPVccTargetSelectType is 'any'."
: :=	{ atmSoftPVccEntry 16 }

atmSoftPVccTargetType   OBJECT-TYPE
	SYNTAX	INTEGER {
					other(1),
					atm(2),
					frameRelay(3)
					}
	MAX-ACCESS	read-create
	STATUS	current
	DESCRIPTION
		"The protocol (e.g. ATM, Frame Relay) used at the target
		interface.

		The atmSoftPVccTargetVpci and atmSoftPVccTargetVci objects
		are only relevant if the target protocols is 'atm'. Otherwise,
		no VPCI/VCI should be included in the SETUP message.
		
		The atmSoftPVccTargetDlci object is only relevant if the target
		protocol is 'frameRelay'. Otherwise, no DLCI should be included
		in the SETUP message.
		
	DEFVAL { atm }
	: := { atmSoftPVccEntry 17 }


atmSoftPVccTargetVpci	OBJECT-TYPE
	SYNTAX	INTEGER (0..65535)
	MAX-ACCESS	read-create
	STATUS	current
	DESCRIPTION
		"The VPCI value of the VCL used at the target interface.

		This value is not relevant when the value of 
		atmSoftPVccTargetSelectType is 'any'."
	DEFVAL { 0 }
	::= { atmSoftPVccEntry 18 }


The following object is deprecated from the atmSoftPVccEntry of the SPVC MIB:

atmSoftPVccTargetVpi


The following object is added to the atmSoftPVpcEntry of the SPVC MIB:

atmSoftPVpcTargetVpci	OBJECT-TYPE
	SYNTAX	INTEGER (0..65535)
	MAX-ACCESS	read-create
	STATUS	current
	DESCRIPTION
		"The VPCI value of the VPL used at the target interface.

		This value must be filled in when the
		atmSoftPVpcTargetSelectType is set to 'required'.
		This value is not relevant when the value of
		atmSoftPVpcTargetSelectType is 'any'."
	::= { atmSoftPVpcEntry 15 }

The following object is deprecated from the atmSoftPVpcEntry of the SPVC MIB:

atmSoftPVpcTargetVpi
7.	
Protocol Implementation Conformance Statement (PICS)
The following PICS are in addition to those specified for Soft PVCs in [2].
7.1	Roles

Item Number
Item Description
Status 
Predicate
Reference
Support
SPVC-PP
Does the IUT support the frame relay SPVC endpoint feature  for point-to-point connections?
O

 4
Yes[ ] No[ ]
7.2	Major Capabilities

Item Number
Item Description
Status 
Predicate
Reference
Support
SPVC-MC.1
Is the IUT capable of initiating a SPVC connection to a frame relay endpoint?
M
SPVC-PP
4
 Yes[ ] No[ ]
SPVC-MC.2
Is the IUT capable of initiating a SPVC connection from a frame relay endpoint? 
O
SPVC-PP
4
 Yes[ ] No[ ]
SPVC-MC.3
Is the IUT capable of terminating a SPVC connection to a frame relay endpoint?
O
SPVC-PP
4
Yes[ ] No[ ]
SPVC-MC.4
Is the IUT capable of terminating a SPVC connection from a frame relay endpoint?
M
SPVC-PP
4
Yes[ ] No[ ]


7.2.1	Information Element Encoding

Item
Protocol Feature
Status 
Predicate
Reference
Support
SPVC-E.1
Is the Calling party soft PVPC or PVCC information element with a DLCI  coded as shown  in   Figure 3-1?
M
SPVC-MC.2
3
Yes[ ] No[ ]
SPVC-E.2
Is the Called party soft PVPC or PVCC information element with a DLCI coded  as  shown in   Figure 3-2?
M
SPVC-MC.1
3
Yes[ ] No[ ]


7.2.2	SPVC procedures for Point-to-Point connections

Item
Procedures Feature

Status 
Predicate
Reference
Support
 SPVC-PPP.1
If the received DLCI is set to "required value" and the requested DLCI is not available, does the IUT send a RELEASE COMPLETE message with PNNI specific cause #34 "requested called party soft PVPC/PVCC not available"?
M
SPVC-MC.3
4
Yes[ ] No[ ]
SPVC-PPP.2
If a Called party soft PVPC or PVCC information element is received at a frame relay Network Interface (NI), with selection type coded as "Any value" and no  DLCI is available, does the IUT send a RELEASE COMPLETE message with ITU-T specific cause #34 "no circuit/channel available"?
M
SPVC-MC.3
4
Yes[ ] No[ ]
SPVC-PPP.3
If the received DLCI is set to "Required value" and no DLCI is specified, does the IUT send a RELEASE COMPLETE message with cause #100 "Invalid information element contents"?
M
SPVC-MC.3
4
Yes[ ] No[ ]
 SPVC-PPP.4
If a Called party soft PVPC or PVCC information element is received at a frame relay interface,  with selection type coded as "Any value" and a DLCI is present, does the IUT ignore the DLCI?
M
SPVC-MC.3
4
Yes[ ] No[ ]
SPVC-PPP.5
If the CONNECT message contains the Called party soft PVPC/PVCC information element with a DLCI, is the DLCI value of the PVCC segment between the called connecting point and the user passed to the management entity? 
M
SPVC-MC.1
4
Yes[ ] No[ ]
SPVC-PPP.6
For the last PVCC segment, does the calling connecting point indicate for the called frame relay endpoint soft PVCC either
- any DLCI or
- Required DLCI ?
M
SPVC-MC.1
4
Yes[ ] No[ ]
SPVC-PPP.7
If the called party identifies a cell relay interface and the Called party soft PVPC or PVCC information element specifies a DLCI, does the IUT send a RELEASE COMPLETE message with cause #88 "incompatible destination"?
 M

4
Yes[ ] No[ ] 
SPVC-PPP.8
If the called party identifies a frame relay interface  and the Called party soft PVPC or PVCC information element specifies a VPCI or VPCI/VCI does the IUT send a RELEASE COMPLETE message with cause #88 "incompatible destination"?
 M
SPVC-MC.3
4
Yes[ ] No[ ] 
SPVC-PPP.9
If a Called party soft PVPC or PVCC information element is received at a cell relay interface, with selection type coded as "Any value" and no  VPCI or VPCI/VCI is available, does the IUT send a RELEASE COMPLETE message with ITU-T cause #34 "no circuit/channel available"?
M

4
Yes[ ] No[ ]
SPVC-PPP.10
If a Called party soft PVPC or PVCC information element is received at a cell relay interface, with selection type coded as "Any value" and a VPCI or VPCI/VCI is present, does the IUT ignore the VPCI or VPCI/VCI?
M

4
Yes[ ] No[ ]
SPVC-PPP.11
If the received VPCI or VPCI/VCI is set to "Required value" and no VPCI or VPCI/VCI is specified, does the IUT send a RELEASE COMPLETE message with cause #100 "Invalid information element contents"?
M

4
Yes[ ] No[ ]
SPVC-PPP.12
If the IUT is not the termination point of the SPVC, does it pass along unchanged Calling and Called party soft PVPC or PVCC information elements containing a DLCI?
M

4
Yes[ ] No[ ]
SPVC-PPP.13
If the IUT is not the termination point of the SPVC, does it pass along unchanged Calling and Called party soft PVPC or PVCC information elements containing unrecognized content?
M

4
Yes[ ] No[ ]

8.	
References
1.  ATM Forum, "Private Network-Network Interface Specification version 1.0 (PNNI 1.0)", af-pnni-0055.000, march 1996.
2.  ATM Forum, "PNNI v1.0 Errata and PICS", af-pnni-0081.000, May 1997.
3.  Network Working Group, "Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC2514, February 1999.
4.  Network Working Group, "Definitions of Managed Objects for ATM Management", RFC2515, February 1999.

af-cs-tbd.000		SPVC Addendum version 1.0 Final Ballot 



  		 	 		 	 		 	

Page ii of iv		ATM Forum Technical Committee

  		  		 		 


af-cs-0127.000		SPVC Addendum version 1.0 Final Ballot 



 SPVC Addendum version 1.0		af-cs-0127.000		 	 		 	 		 	

Page ii of iii		 ATM Forum Technical Committee

ATM Forum Technical Committee		Page iii				 


Page 14 of 13		 ATM Forum Technical Committee

ATM Forum Technical Committee		Page 14