Technical Committee

PNNI Transported Address Stack version 1.0

AF-CS-0115.000

May, 1999

© 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	
1.1. Addressing in Multiple Networks	
1.2. Current Address Transport Mechanisms	
1.3. Transported Address Stack	
1.4. Application of the Transported Address Stack	
1.4.1 Single Level Transported Address Stack	
1.4.2 Multi-Level Transported Address Stack	
2. Additions to PNNI Signaling Messages	
2.1. SETUP Message	
2.2. ADD PARTY Message	
2.3. CL-BI FACILITY Message	
2.4. CO-BI SETUP Message	
3. Information Element Coding	
3.1. Transported Address Information Element	
4. Procedures for Transported Address Stack Processing	
4.1. General Procedures for Transported Address Stack Processing	
4.1.1. Procedures at the Transport Origination Point	
4.1.2. Procedures at Intermediate Switches	
4.1.3. Procedures at the Transport Termination Point	
4.1.4. Messages For CdPN-Routed Message Rejection	
4.2. Interactions with DTL Roles	
4.3. Additional GSS Procedures	
5. Compatibility with Nodes Not Supporting This Feature	
6. Protocol Implementation Conformance Statement (PICS)	
6.1. Introduction	
6.1.1. Scope	
6.1.2. Definitions	
6.1.3. Acronyms	
6.1.4. Conformance	
6.2. Identification of the Implementation	
6.3 PICS Proforma	
6.3.1. Global statement of conformance	
6.3.2. Instructions for Completing the PICS Proforma	
6.3.3. Transported Address Stack - Roles	
6.3.4. Role – Transport Origination Point (TAS_MC1)	
6.3.5. Role – Transport Termination Point (TAS_MC2)	
6.3.6. Role – Intermediate Switch  (TAS_MC3)	
7. References	

Table of Figures
Figure 1.4-1  Single Level Address Stack Example	
Figure 1.4- 2 Multi Level Address Stack Example	
Figure 2.1-1  Additional SETUP Message Content	
Figure 2.2-1  Additional ADD PARTY Message Content	
Figure 2.3-1  Additional CL-BI FACILITY Message Content	
Figure 2.4-1  Additional CO-BI SETUP Message Content	
Figure 3.1-1  Transported Address Information Element	

1.	Introduction
[INFORMATIVE]
1.1.	Addressing in Multiple Networks 
For various reasons, such as local number portability and customer owned addresses, addresses might be assigned without topological significance.  In such cases, routing tables can become very large.  This results in a scalability problem for networks.  Use of the Transported Address Stack and a translation facility can help overcome this problem by decoupling the addresses used for routing within a network from those used at the edge of the network. 
For more information on Customer Owned and ATM Service Provider addressing, consult ATM Forum Addressing: User Guide [AUG] or ATM Forum Addressing: Reference Guide [ARG].
 1.2.	Current Address Transport Mechanisms
In the absence of the Transit network selection (TNS) information element, ATM networks route using  the contents of the Called party number information element.  The Called party subaddress information element is also available to end users to enable them to transport additional addressing information.  For example, an end user might place an ATM Service Provider (ASP) address in the Called Party Number and a Customer Owned (private) address in the Called Party Subaddress.  The ASP address is  used for routing through the ASP network and the contents of the Called Party Subaddress (when placed into the Called party number information element at the destination private network) is used for routing through the destination private network.  However, this type of subaddress transport mechanism is not available to ASP networks since ASPs cannot generate or alter the contents of the Subaddress information elements.
Networks have many reasons for requiring the use of an address transport mechanism such as support for number portability, Virtual Private Networks and  network internal routing.  Given that these needs are diverse and may exist simultaneously,  a solution with maximum flexibility is required.
1.3.	Transported Address Stack
Rather than defining one information element that has the capability to transport one address, a “last in, first out” stack is proposed to enable  the carriage of multiple addresses.   Each element of this stack consists of an information element known as the Transported address information element. Thus, addresses can be ‘pushed’ or ‘popped’ onto/from the Transported Address Stack.
The Transported Address Stack is only to be used to carry addresses  that must be temporarily displaced from the Called or Calling party number information elements.  When pushing a called party number onto the stack, the address that displaces it in the Called party number information element should cause the message to be routed to a location at which the pushed called party number can be used for further routing.
It is assumed that the Transported Address Stack will be used in conjunction with a translation facility.  This translation facility is not defined in this document.
1.4.	Application of the Transported Address Stack
The following examples are used to illustrate how the Transported Address Stack may be used.
1.4.1 Single Level Transported Address Stack

Figure 1.4-1  Single Level Address Stack Example   
Figure 1.4-1 illustrates a simple example of the Transported Address Stack.  In this example, the two end systems have been assigned addresses (ES A and ES B) that are not topologically significant to the numbering plan used by the ATM network.  In order to avoid configuring exceptions for such addresses in the routing tables, a translation facility is used to map the addresses of these end systems to addresses which are topologically significant and routable within the ATM network.
When ES A wishes to call ES B, the following steps occur:
1. 	ES A sends a SETUP message into the ATM Network with a Calling party number (CgPN) containing address ES A and a Called party number (CdPN) information element containing address ES B.
2. 	a) The ingress switch to the ATM Network uses a translation facility to map the address ES A to address IntA and address ES B to address IntB.  IntA and IntB are internal addresses which are topologically significant and can be used for routing within the ATM network.

b) The original Calling and Called party numbers (ES A and ES B) are placed on top of the Transported Address Stack within a single Transported address information element.

c) The call progresses through the network with the internal addresses in the Calling and Called party number information elements and the original addresses in the Transported address information element.
3. 	At the egress switch of the ATM Network, since the called party number (IntB) identifies a local address configured for the purpose of address transport termination,

a) The top (and only) Transported address information element is popped.

b) The internal addresses (IntA and IntB) are discarded and the original Calling and Called party numbers (ES A and ES B) from the popped Transported address information element are placed  into the Calling party number and Called party number information elements, respectively.

c) The call is progressed across the destination UNI toward ES B with the original Calling Party Number, ES A, and the original Called Party number ES B.

1.4.2 Multi-Level Transported Address Stack

Figure 1.4- 2 Multi Level Address Stack Example   
Key:
ES = End System	ASP = ATM Service Provider	
PNx = Private Network x	CO addr = Customer Owned address	
TF = Translation Facility	CdPN = Called party number information element	
TAS = Transported Address Stack.	Int P = ASP Internal Address P	
In the diagram above,  Private Network X (PNx) has numbered its end systems using a customer owned addressing scheme.  ASP2 is using an internal addressing scheme ‘Int’. End System ES1 wishes to call End System ES2 at address PNx.5.2.   The bold numbers in the diagram refer to the steps below, which demonstrate the progression of the call.  For simplicity, this example does not describe the manipulation of the calling party number.
1.	Address PNx.5.2 is initially placed in the CdPN by ES1 and the call is transported through network PNx.4 toward ASP1.
2.	ASP1’s ingress translation facility determines that service provider address ASP3.z is needed for routing across service provider networks, since customer-owned address PNx.5.2 is unsuitable. Therefore it pushes PNx.5.2 onto the stack and places ASP3.z in the Called party number information element. 
3.	ASP2’s ingress translation facility determines that it needs to use an internal routing address IntP to reach the egress to the next network.  Therefore it pushes ASP3.z onto the stack and places IntP in the Called party number information element.
4.	ASP2’s egress switch determines that routing on address IntP is complete.  The egress switch pops address ASP3.z from the stack and places this address into the Called party number information element.
5.	ASP3’s egress switch determines that routing on address ASP3.z is complete.  The egress switch pops address PNx.5.2 from the stack and places this address into the Called party number information element.
Note that an ingress switch may push more than one Transported address information element onto the stack, e.g., if the translation facility first determines that a service provider address is needed to replace a customer-owned address, and secondly determines that an internal address is needed for routing across its own network.
In this example the address manipulation in ASP1, ASP2 and ASP3 is invisible to the private network.  This is an example of a virtual private network.
2.	Additions to PNNI Signaling Messages
[NORMATIVE]
2.1.	SETUP Message
Figure 6-8/PNNI 1.0 SETUP Message Content is augmented with the following:

Information Element	Reference	Type	Length		
Broadband repeat indicator	6.4.5.13/
PNNI 1.0	O(1)	5		
Transported address	3	O(2)	(3)		

Note 1 -	This information element shall be included when one or more Transported address information elements are present.  The Broadband repeat indicator information element shall be included immediately before the first Transported address information element. The Broadband repeat indication field shall be coded as “Last-in, First out stack”.
Note 2 -	The maximum number of instances allowed is 5.
Note 3 -	The length depends on the numbering plan.  Maximum length is 53.
Figure 2.1-1  Additional SETUP Message Content   
2.2.	ADD PARTY Message
Figure 6-19/PNNI 1.0 ADD PARTY Message Content is augmented with the following:

Information Element	Reference	Type	Length		
Broadband repeat indicator	6.4.5.13/
PNNI 1.0	O(1)	5		
Transported address	3	O(2)	(3)		

Note 1 -	This information element shall be included when one or more Transported address information elements are present.  The Broadband repeat indicator information element shall be included immediately before the first Transported address information element. The Broadband repeat indication field shall be coded as “Last-in, First out stack”.
Note 2 -	The maximum number of instances allowed is 5.
Note 3 -	The length depends on the numbering plan.  Maximum length is 53.
Figure 2.2-1  Additional ADD PARTY Message Content   

2.3.	CL-BI FACILITY Message
Figure 26-1/GSS CL-BI FACILITY Message Content is augmented with the following:

Information Element	Reference	Type	Length		
Broadband repeat indicator	6.4.5.13/PNNI	O(1)	5		
Transported address	3	O(2)	(3)		

Note 1 -	This information element shall be included when one or more Transported address information elements are present.  The Broadband repeat indicator information element shall be included immediately before the first Transported address information element. The Broadband repeat indication field shall be coded as “Last-in, First out stack”.
Note 2 -	The maximum number of instances allowed is 5.
Note 3 -	The length depends on the numbering plan.  Maximum length is 53.
Figure 2.3-1  Additional CL-BI FACILITY Message Content   

2.4.	CO-BI SETUP Message
Figure 26-2/GSS CO-BI SETUP Message Content is augmented with the following:

Information Element	Reference	Type	Length		
Broadband repeat indicator	6.4.5.13/PNNI	O(1)	5		
Transported address	3	O(2)	(3)		

Note 1 -	This information element shall be included when one or more Transported address information elements are present.  The Broadband repeat indicator information element shall be included immediately before the first Transported address information element. The Broadband repeat indication field shall be coded as “Last-in, First out stack”.
Note 2 -	The maximum number of instances allowed is 5.
Note 3 -	The length depends on the numbering plan.  Maximum length is 53.
Figure 2.4-1  Additional CO-BI SETUP Message Content   

3.	Information Element Coding
[NORMATIVE]
3.1.	Transported Address Information Element
The purpose of the Transported Address Stack is to allow transparent carriage of addresses through a PNNI network.  Section 4 0 describes the procedures for constructing and processing a Transported Address Stack.

8	7	6	5	4	3	2	1	Octet	
Transported Address		
1	1	1	0	0	1	1	0	  1	
Information element identifier		
1
ext	Coding
standard	IE Instruction Field	  2	
Length of Transported Address contents	  3	
Length of Transported Address contents (continued)	  4	
0	0	0	0	0	0	0	1		
Transported Called Party Number indicator	5	
Length of Transported Called Party Number Information	5.1 (Note 1)	
Length of Transported Called Party Number Information(continued)	5.2	

1
ext.	
Type of number
	
Numbering plan identification	
5.3	

Transported Called Party Number Information
	
5.4 etc.	
0	0	0	0	0	0	1	0		
Transported Calling Party Number indicator	6*	
Length of Transported Calling Party Number Information	6.1* (Note 2)	
Length of Transported Calling Party Number Information (continued)	6.2*	

0/1
ext.	
Type of number
	
Numbering plan identification	
6.3*	

Transported Calling Party Number Information
	
6.4* etc.	
Figure 3.1-1  Transported Address Information Element   

Note 1 - Length includes octet 5.3 and 5.4 etc., but not octets 5, 5.1 and 5.2.
Note 2 - Length includes octet 6.3 and 6.4 etc., but not octets 6, 6.1 and 6.2 .

Coding standard (octet 2)

      Bits	Meaning	
	7	6								
	1	1							ATM Forum specific	

Numbering Plan Identification (octet 5.3 and 6.3)  

      Bits	Meaning	
					4	3	2	1		
					0	0	1	1	X.121 address plan	
									Other values as defined in 4.5.11/Q.2931 Called party number	

Transported Called Party Number  (octet group 5)
If the Numbering Plan Identification value (from octet 5.3) is 0011, then octets 5.3, 5.4 etc. are coded as defined for the Called party number information element in 10.5.6/X.36, octets 3, 4 etc., respectively.
Otherwise, octets 5.3, 5.4 etc. are coded as defined for the Called party number information element in 4.5.11/Q.2931, octets 5, 6 etc., respectively. Note that this implies non-International Type of Number values for ISDN (Rec. E.164) addresses may be transported.

Transported Calling Party Number  (octet group 6)
If the Numbering Plan Identification value (from octet 6.3) is 0011, then octet 6.3 is coded as defined for the Calling party number information element in 10.5.8/X.36, octet 3, and octets 6.4 etc. are coded as defined for the Calling party number information element in 10.5.8/X.36, octets 3a, 4 etc.  Note that octet 3a specifies the Presentation and Screening Indicators.
Otherwise, octet 6.3 is coded as defined for the Calling party number information element in 4.5.13/Q.2931, octet 5,  and octets 6.4 etc. are coded as defined for the Calling party number information element in 4.5.13/Q.2931 octets 5a, 6 etc. This implies non-International Type of Number values for ISDN (Rec. E.164) addresses may be transported.  Note that octet 5a specifies the Presentation and Screening Indicators.
4.	Procedures for Transported Address Stack Processing
[NORMATIVE]
4.1.	General Procedures for Transported Address Stack Processing
The procedures for stacking, propagating, and unstacking Transported address information elements are specified in this section.
Any signalling message that may be routed based on the Called party number information element can carry the Transported address information element. The term “CdPN-routed message” in the text below is used to designate any such message.  This is in contrast to messages that follow a pre-existing path using call references.    The CdPN-routed messages are listed in Section 2.
The Transported Address Stack is implemented as a set of information elements in a push on, pop off stack, similar to the PNNI DTL information element stack.  The address in the Called party number information element designates the point in the network where the top Transported address information element is to be popped.  This is called the  “transport termination point”.
The called and calling party numbers in a CdPN-routed message may be mapped to new called and calling party numbers using a translation facility.  Specification of this translation facility or when address mapping is to be performed is beyond the scope of this document..  When mapped, the original called and calling party numbers are added to the Transported Address Stack for transport when the CdPN-routed message is forwarded.  The newly-derived called and calling party numbers are placed into the respective Called party number and Calling party number information elements.  A point in the network where a new Transported address information element is pushed onto the stack is called a “transport origination point”.  It is possible that multiple Transported address information elements may be pushed onto the Transported Address Stack by the same transport origination point. The call is progressed from the transport origination point in the normal manner using the current called and calling party numbers.
At a transport termination point, a Transported address information element is popped from the Transported Address Stack.  The contents of the Transported address information  element are promoted to the Called and Calling party number information elements.   It is possible that multiple Transported address information elements are popped from the Transported Address Stack by the same transport termination point.
A new subaddress shall not be generated if a Transported address information element is present.  The called and/or calling party subaddresses shall not be promoted to the Called and/or Calling party number information elements when a Transported address information element is present.
4.1.1.	Procedures at the Transport Origination Point
If the received CdPN-routed message contains one or more Transported address information elements and if the first Transported address information element is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then the message shall be rejected using the message  specified in Section 4.1.4 with cause #96, “mandatory information element is missing” with diagnostics including the information element identifier for the Broadband repeat indicator information element.
It may be determined by local means that the called party number and perhaps also the calling party number of a received CdPN-routed message are to be mapped to other Called and/or Calling Party Numbers, with the received Called and/or Calling Party Numbers carried transparently using the Transported Address Stack.
If such a mapping is to be performed, the following procedures are executed:
a)	A new Transported address information element is created.
b)	The Called Party number in the received CdPN-routed message shall be inserted into the new Transported address information element.  The newly- derived Called Party Number shall be placed into the Called party number information element.  Note that the Called party number information element indicates the transport termination point for this Transported address information element.
c) 	The Calling Party Number in the received CdPN-routed message shall be inserted into the new Transported address information element.  If no Calling party number information element is present in the received message, then octet group 6 (Transported Calling Party Number Information) shall be omitted from the Transported address information element.

If a new Calling Party Number is to be used, then the newly derived Calling Party Number shall be placed into the Calling party number information element.  Otherwise, if no new Calling Party Number is to be used, then the original Calling party number information element shall be maintained unchanged in the message (in addition to being copied into the Transported address information element).
d) 	The new Transported address information element shall be pushed onto the Transported Address Stack.
These procedures may be repeated if more than one level of Transported address information element stacking is to be performed.
When this is not a transport termination point for the call, no content validation shall be performed on any received Transported address information elements, other than verifying the maximum information element length and maximum number of instances.  If either of these maximums is exceeded, then the procedures for mandatory information element with information element content error shall be followed.  If the call is progressed, all received Transported address information elements shall be forwarded without modification.  This allows support for other address types in the future. 
4.1.2.	Procedures at Intermediate Switches
The following procedures apply at switches which are neither a transport origination point nor a transport termination point.
If the received CdPN-routed message contains one or more Transported address information elements and if the first Transported address information element is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then the message shall be rejected using the message  specified in Section 4.1.4with cause #96, “mandatory information element is missing” with diagnostics including the information element identifier for the Broadband repeat indicator information element.
No content validation shall be performed on any received Transported address information elements, other than verifying the maximum information element length and maximum number of instances.  If either of these maximums is exceeded, then the procedures for mandatory information element with information element content error shall be followed.  If the call is progressed, all received Transported address information elements shall be forwarded without modification.  This allows support for other address types in the future. 
4.1.3.	Procedures at the Transport Termination Point
It is determined that a transport termination point has been reached when the Called party number in the CdPN-routed message identifies a local address configured for the purpose of Address Transport termination (and may designate, for example, a port on this switch).
If the received CdPN-routed message contains one or more Transported address information elements and if the first Transported address information element is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then the message shall be rejected using the message specified in Section 4.1.4 with cause #96, “mandatory information element is missing” with diagnostics including the information element identifier for the Broadband repeat indicator information element.
Otherwise
a)	If there is no Transported address information element remaining in the CdPN-routed message and there is no other address information that can be promoted to the Called party number, then the message shall be rejected using the message specified in Section 4.1.4with cause #28, “invalid number format (address incomplete)”.
 b)	The top Transported address information element on the stack shall be removed.  If the top Transported address information element has content not recognized by the switch, then the message shall be rejected using the message specified in Section 4.1.4 with cause #100, “invalid information element contents”.
c)	The Called party number field in the popped Transported address information element shall be placed into the Called party number information element.
d)	If there is a Calling Party number field in the popped Transported address information element, it shall be placed into the Calling party number information element.  Otherwise, the Calling party number information element shall be deleted from the message. 
e)	If the new Called party number is determined to be a local address used for the purpose of Address Transport termination, then the procedures in items (a) through (d) shall be repeated and the next Transported address information element shall be popped. Otherwise, the CdPN-routed message shall be progressed as determined by the local system depending on the current Called party number. 
In order to support other address types in the future, Transported address information elements that are not popped shall be forwarded without modification, without performing any content validation other than verifying the maximum information element length and maximum number of instances.  If either of these maximums is exceeded, then the procedures for mandatory information element with information element content error shall be followed.  
4.1.4.	Messages For CdPN-Routed Message Rejection
Table  4.1-1 specifies the appropriate message to be used to reject the corresponding CdPN-routed message.

CdPN-routed Message	Reject Message	
SETUP	RELEASE COMPLETE or RELEASE	
ADD PARTY	ADD PARTY REJECT	
CL-BI FACILITY	No message.  CL-BI FACILITY is dropped	
CO-BI SETUP	RELEASE COMPLETE or RELEASE	
Table 4.1-1 – CdPN-routed Message Rejection
4.2.	Interactions with DTL Roles
A switching system acting as the DTL Originator for a CdPN-routed message may also act as a transport termination point prior to commencement of PNNI route selection.  Once PNNI route selection commences, the node does not act as a transport termination point unless it is also the DTL Terminator.

A switching system acting as the DTL Originator for a CdPN-routed message may also act as a transport origination point, either prior to commencement of PNNI route selection or in conjunction with PNNI route selection.

PNNI switching systems that do not act as the DTL Originator or the DTL Terminator for a CdPN-routed message shall not be transport origination points or transport termination points for the CdPN-routed message.  If the CdPN-routed message is progressed, the Transported Address Stack shall be forwarded without modification.

A switching system acting as the DTL Terminator for a CdPN-routed message may also act as a transport termination point.  It may act as a transport origination point after PNNI processing as the DTL Terminator is completed.
4.3.	Additional GSS Procedures
The procedures below are intended to augment those from [GSS].
Add the following statement to section 26.9.1.3.1/GSS:
-	The preceding side shall include one or more Transported address information elements in the CO-BI SETUP message if instructed by GFT-Control.
Add the following statement to section 26.9.1.4.1/GSS:
-	The sending node shall include one or more Transported address information elements in the FACILITY message if instructed by GFT-Control.
Modify Section 26.9.2.2.1.1/GSS to contain the underlined text below:
GFT-Control shall request the inclusion of one or more Designated transit list information elements in accordance with Annex A procedures for an originating node.    GFT-Control may request the inclusion of one or more Transport address information elements in accordance with Section 4.1.1.
Add the following to the first paragraph of  Section 26.9.2.2.3.1/GSS:
If the incoming CO-BI SETUP message contains a Transported address information element, then the procedures of  Section 4.1.3 shall be performed.  This may cause a new CO-BI SETUP to be originated by GFT-Control toward a new destination.
Modify  Section  26.9.2.3.1/GSS to contain the underlined text as follows:
-	if a route to the destination can be selected, select the appropriate PNNI link based on the destination address given in the request and inform Protocol Control to send a FACILITY message which shall contain:
- Optionally one or more Transported address information elements in accordance with Section 4.1.1
Add the following to the beginning of  Section  26.9.2.3.3/GSS:
If the received FACILITY message contains a Transported address information element, then the procedures of  Section 4.1.3 shall be performed.  This may cause a new FACILITY message to be originated by GFT-Control toward a new destination.
Modify  Section  26.10.2.3/GSS to contain the underlined text as follows:
The contents of the following information elements contained in the PNNI protocol are discarded:
- Notification indicator information element
If one or more Transported address information elements are present in a PNNI CO-BI SETUP message, then a PNNI RELEASE message is returned with cause #3, “no route to destination”.
Add the following text to  Section  26.10.2.4/GSS:
If one or more Transported address information elements are present in a PNNI FACILITY message, then the message is discarded.

5.	Compatibility with Nodes Not Supporting This Feature
[NORMATIVE]

The Transported Address Stack is an optional Addendum to PNNI v1.0.  This section describes how the Transported Address Stack feature exists in a network containing nodes that do not support the feature.
Only nodes  “pushing” Transported address information elements onto the stack (transport origination point) and nodes “popping” Transported address information elements from the stack (transport termination point) need to support this feature.  Intermediate nodes do not need to support the Transported Address Stack.  As such, the Transported address information element shall be coded with the IE instruction flag field (bit 5 of octet 2) set to “follow explicit instruction”, the pass along request field (bit 4 of octet 2) set to “pass along request” and the action indicator (bits 1-3 of octet 2) set to “clear call”. 
It is a configuration error if the node that is intended to pop the top Transported address information element does not support this feature.  Since the node pushing the Transported address information element (transport origination point) is configured to do so by some entity, this entity is also responsible for ensuring that the node at which the Transported address information element is to be popped (transport termination point) also supports the Transported Address Stack feature.  In the presence of such a configuration error, calls will most likely be cleared at the node at which the Transported address information element is to be popped.  

6.	Protocol Implementation Conformance Statement (PICS)
[INFORMATIVE]
6.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).
6.1.1.	Scope
Section 0 provides the PICS proforma for the Transported Address Stack, as specified in this document in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2 [CTMI].  In most cases, statements contained in notes in the specification, which were intended as information, are not included in the PICS. 
6.1.2.	Definitions

This following terms defined in ISO/IEC 9646-1[CTMF] are used below:
•	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.
6.1.3.	Acronyms

I.E.	Information Element
IUT	Implementation under test
M	Mandatory requirements (these are to be observed in all cases)
N/A	Not supported, not applicable, or the conditions for status are not met.
O	Optional (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)
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
PMP	Point-to-Multipoint
SUT	System under test
6.1.4.	Conformance
The supplier of a protocol implementation which is claimed to conform to the ATM Forum Transported Address Stack 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.
6.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:

* Transported Address Stack as defined in this document
6.3	PICS Proforma

6.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.
6.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.
6.3.3.	Transported Address Stack - Roles

Item Number	Item Description	Status	Predicate	Reference	Support	
TAS_MC1	Transport Origination Point	M		4.1, 4.1.1	Yes_  No_	
TAS_MC2	Transport Termination Point	M		4.1, 4.1.3	Yes_  No_	
TAS_MC3	Intermediate Switch	M		4.1, 4.1.2	Yes_  No_	

6.3.4.	Role – Transport Origination Point (TAS_MC1)

Item Number	Item Description
For all CdPN-routed messages if a new Transported address information element is created…	Status	Predicate	Reference	Support	
TASO_1	If the first Transported address information element in the CdPN-routed message is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then does the IUT reject the message with cause  #96, “mandatory information element is missing”?	M		4.1.1,
4.1.4	Yes_  No_	
TASO_2	Does the IUT insert the received Called Party Number into a new Transported address information element and replace the contents of the Called party number information element?	M		      4.1.1	Yes_  No_	
TASO_3	If there is a Calling party number information element in the received message, does the IUT insert the received calling party number into the new Transported address information element?	M		      4.1.1	Yes_  No_	
TASO_4	If there is no Calling party number information element in the received message does the IUT omit the Calling Party Number Information field in the new Transported address information element?	M		      4.1.1	Yes_  No_	
TASO_5	If a new calling party number is to be used for the message, is the new calling party number placed into the Calling party number information element?	M		      4.1.1	Yes_  No_	
TASO_6	If no new calling party number is to be used for the message, is the original Calling party number information element present when the message is progressed?	M		      4.1.1	Yes_  No_	
TASO_7	Is the new Transported address information element pushed on top of the current Transported Address Stack?	M		      4.1.1	Yes_  No_	
TASO_8	Can the Transported address information element be included in the 			      4		
	- SETUP message?	M			Yes_  No_	
	- ADD PARTY message?	M			Yes_  No_	
	- FACILITY message?	M	MC2.4 (from [GSS])		Yes_  No_	
	- CO-BI SETUP message?	M	MC2.3 (from [GSS])		Yes_  No_	
TASO_9	Is the Transported address information element coded as shown in Figure 3.1-1  Transported Address Information Element?	M		      3.1	Yes_  No_	
TASO_10	If this is not a Transport Termination Point and there is one or more Transported address information elements included in the received message, does the IUT include all received Transported address information elements unchanged in the forwarded message?	M		      4.1.1	Yes_  No_	

6.3.5.	Role – Transport Termination Point (TAS_MC2)

Item Number	Item Description
For all CdPN-routed messages if the Called Party Number is a local address configured for the purpose of Address Transport Termination … 	Status	Predicate	Reference	Support	
TAST_1	If the first Transported address information element in the CdPN-routed message is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then does the IUT reject the message with cause #96, “mandatory information element is missing”?	M		4.1.3,
4.1.4	Yes_  No_	
TAST_2	If there is no Transported  address information element and there is no other address information that can be promoted to the Called party number information element, then does the IUT reject the message with cause #28, “invalid number format (address incomplete)”?	M		4.1.3,
4.1.4	Yes_  No_	
TAST_3	If the top Transported address information element has content unrecognized to the switch, does the IUT reject the message with cause #100, “invalid information element contents”?	M		4.1.3,
4.1.4	Yes_  No_	
TAST_4	Does the IUT replace the received Called party number information element with the popped called party number?	M		      4.1.3	Yes_  No_	
TAST_5	If a Calling Party Number is present in the top Transported address information element, does the IUT replace the received Calling party number information element with the popped Calling Party Number?	M		      4.1.3	Yes_  No_	
TAST_6	If no Calling Party Number is present in the top Transported address information element, does the IUT delete the Calling party number element from the message?	M		4.1.3	Yes_ No_	
TAST_7	If the current Called Party Number is a local address configured for the purpose of Address Transport Termination, does the IUT repeat the transport termination point procedures? (TAST_2, TAST_3, TAST_4, TAST_5, TAST_6, TAST_7)	M		      4.1.3	Yes_  No_	

6.3.6.	Role – Intermediate Switch  (TAS_MC3) 

Item Number	Item Description
For all CdPN-routed messages 	Status	Predicate	Reference	Support	
TASI_1	If the first Transported address information element in the CdPN-routed message is not immediately preceded by the Broadband repeat indicator information element coded to “Last-in, First out stack”, then does the IUT reject the message with cause #96, “mandatory information element is missing”?	M		4.1.2, 4.1.4	Yes_  No_	
TASI_2	If there is one or more Transported address information elements included in the received message, does the IUT include all received Transported address information elements unchanged in the forwarded message?	M		      4.1.2	Yes_  No_	

7.	References
[AUG]	"ATM Forum Addressing: User Guide", The ATM Forum Technical Committee, af-ra-0105.000
[ARG]	"ATM Forum Addressing: Reference Guide", The ATM Forum Technical Committee
[PNNI]	"Private Network-Network Interface Specification Version 1.0 (PNNI1.0)", The ATM Forum Technical Committee, af-pnni-0055.000, March 1996
[GSS]	"PNNI1.0 Addendum 1 - B-QSIG Interworking and Generic Support for Supplementary Services”, The ATM Forum Technical Committee, af-cs-0102.000, 
[Q2931]	" B-ISDN DSS2 User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control ",  ITU-T Q.2931,  February, 1995
[CTMF]	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)). 
[CTMI]	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)). 
[X36]	“Amendment 1: Switched Virtual Circuit (SVC) signalling and refinements of Permanent Virtual Circuit (PVC) signalling”, ITU-T X.36 Amendment 1, October, 1996