Technical Committee PNNI Transported Address Stack version 1.0 AF-CS-0115.000 May, 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 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. for exceptional information, or S. for supplemental information, respectively, for cross reference purposes, where 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 af-cs-0115.000 PNNI Transported Address Stack PNNI Transported Address Stack af-cs-0115.000 Page iv of 24 ATM Forum Technical Committee ATM Forum Technical Committee Page 1 of 24