Independent Submission A. Chidester Internet-Draft Independent Researcher Intended status: Informational 31 August 2025 Expires: 28 February 2026 Private Network-to-Network Interface (PNNI) Signaling in Asynchronous Transfer Mode (ATM) Networks draft-chidester-pnni-signaling-00 Abstract This document describes the Private Network-to-Network Interface (PNNI) signaling procedures used in Asynchronous Transfer Mode (ATM) networks. PNNI is a hierarchical link-state routing protocol that enables topology discovery, dynamic routing, and call establishment across ATM networks. This document outlines the signaling model, hierarchical routing structures, call setup procedures, and interoperability considerations for both modern and legacy ATM network implementations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 February 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Scope and Applicability . . . . . . . . . . . . . . . . 4 2. PNNI Signaling Model . . . . . . . . . . . . . . . . . . . . 4 2.1. Peer Group Structure . . . . . . . . . . . . . . . . . . 4 2.2. Topology Distribution . . . . . . . . . . . . . . . . . 5 3. Call Setup and Signaling Procedures . . . . . . . . . . . . 5 3.1. Call Setup Flow . . . . . . . . . . . . . . . . . . . . 6 3.2. Crankback Procedures . . . . . . . . . . . . . . . . . . 6 4. Quality of Service Signaling . . . . . . . . . . . . . . . . 6 4.1. Service Categories . . . . . . . . . . . . . . . . . . . 7 4.2. Traffic Parameter Negotiation . . . . . . . . . . . . . 7 5. Interoperability Considerations . . . . . . . . . . . . . . . 7 5.1. Protocol Version Compatibility . . . . . . . . . . . . . 8 5.2. Vendor-Specific Extensions . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Topology Spoofing . . . . . . . . . . . . . . . . . . . 8 6.2. Resource Exhaustion Attacks . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Private Network-to-Network Interface (PNNI) is a hierarchical link-state routing protocol specifically designed for Asynchronous Transfer Mode (ATM) networks. PNNI provides automated topology discovery, dynamic routing, and Quality of Service (QoS) aware path selection capabilities that are essential for scalable ATM network operations. Originally developed by the ATM Forum in the mid-1990s [ATM-FORUM-PNNI], PNNI addresses the unique requirements of ATM networks, including support for multiple service categories, traffic management, and connection-oriented communication. The protocol operates across hierarchical peer groups, enabling scalable routing in large ATM networks while maintaining detailed QoS information for optimal path selection. This document revisits PNNI signaling principles in the context of modern networking requirements, identifies common interoperability issues encountered in multi-vendor environments, and proposes clarifications for current implementers and network operators [CHIDESTER-2024]. While ATM technology is considered legacy in many contexts, PNNI principles continue to inform modern network design, particularly in areas requiring strict QoS guarantees and hierarchical routing structures. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Scope and Applicability This document focuses on the signaling aspects of PNNI and is intended for network operators managing existing ATM infrastructure, implementers developing or maintaining PNNI-capable systems, researchers studying hierarchical routing protocols, and engineers migrating from ATM to modern networking technologies. 2. PNNI Signaling Model PNNI signaling operates through a distributed model where each ATM switch maintains local topology information and participates in network-wide topology distribution. The signaling model consists of several key components working in coordination to provide end-to-end connectivity establishment. 2.1. Peer Group Structure PNNI organizes ATM networks into hierarchical peer groups. Within each peer group, nodes exchange detailed topology information using the PNNI topology distribution protocol. Each peer group elects a Peer Group Leader (PGL) responsible for representing the group at higher hierarchy levels and aggregating topology information. The hierarchical structure enables scalable routing by reducing the amount of detailed topology information that must be maintained at each level. Lower-level groups provide summarized reachability information to higher levels, while detailed routing decisions are made locally within each peer group. 2.2. Topology Distribution Topology information is distributed through PNNI Topology State Elements (PTSEs), which are flooded within peer groups using a reliable flooding mechanism. PTSEs contain information about node connectivity and available resources, link characteristics including bandwidth, delay, and cost metrics, QoS parameters for different service categories, and reachability information for external addresses. The flooding mechanism ensures that all nodes within a peer group maintain consistent topology databases, enabling optimal path computation for connection establishment. 3. Call Setup and Signaling Procedures PNNI call setup procedures extend standard ATM signaling protocols with routing capabilities. The signaling process involves route computation, resource reservation, and connection establishment across potentially multiple peer groups. 3.1. Call Setup Flow The call setup process follows these major steps: route computation based on destination address and QoS requirements, resource reservation along the computed path, signaling message propagation using the computed route, and connection establishment and confirmation. Each step involves coordination between multiple network elements and MUST maintain consistency with PNNI topology information and QoS constraints. 3.2. Crankback Procedures When a connection setup fails due to resource unavailability or other constraints, PNNI provides crankback mechanisms to attempt alternate routes. Crankback information SHOULD include specific failure reasons to enable intelligent alternate route selection and avoid repeated failures. 4. Quality of Service Signaling PNNI provides comprehensive QoS signaling capabilities that enable connection establishment with specific performance guarantees. The QoS model supports multiple ATM service categories and allows for detailed specification of traffic parameters and performance requirements. 4.1. Service Categories PNNI supports signaling for all standard ATM service categories including Constant Bit Rate (CBR), Variable Bit Rate (VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). Each service category has specific QoS parameters that MUST be considered during route computation and resource reservation. 4.2. Traffic Parameter Negotiation During connection establishment, PNNI signaling allows for negotiation of traffic parameters to accommodate network capabilities and resource availability. Parameter negotiation SHOULD be performed in a way that maintains the essential QoS requirements while allowing for reasonable flexibility in implementation. 5. Interoperability Considerations Multi-vendor PNNI implementations have historically faced several interoperability challenges. This section identifies common issues and provides guidance for ensuring successful deployment across heterogeneous environments. 5.1. Protocol Version Compatibility Implementations SHOULD support graceful degradation when communicating with nodes running different PNNI versions. Version negotiation mechanisms MUST be implemented to ensure baseline functionality across mixed environments. 5.2. Vendor-Specific Extensions Vendor-specific PNNI extensions SHOULD be designed to fail gracefully when interoperating with implementations that do not support these extensions. Critical functionality MUST NOT depend on vendor-specific features to ensure broad interoperability. 6. Security Considerations PNNI signaling introduces several security considerations that network operators and implementers must address to ensure network integrity and prevent unauthorized access or service disruption. 6.1. Topology Spoofing Malicious nodes may attempt to inject false topology information to redirect traffic or cause network instability. Implementations SHOULD implement authentication mechanisms for PNNI peer relationships and validate topology state information before accepting updates. 6.2. Resource Exhaustion Attacks Attackers may attempt to exhaust network resources through excessive connection setup requests or by advertising false resource availability. Rate limiting and resource reservation validation mechanisms SHOULD be implemented to mitigate these attacks. 7. IANA Considerations This document makes no requests to IANA. All protocol elements described in this document use existing ATM Forum assigned values or are implementation-specific parameters that do not require global coordination. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [ATM-FORUM-PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0", ATM Forum af-pnni-0055.000, March 1996. [CHIDESTER-2024] Chidester, A., "PNNI (Private Network-Network Interface) Signaling in ATM Networks", MC Inc, March 2024. Acknowledgments The author would like to acknowledge the foundational work performed by the ATM Forum in developing the original PNNI specifications, as well as the contributions of implementers and operators who have provided valuable feedback on PNNI deployment experiences over the years. Author's Address Ashlan Chidester Independent Researcher Email: ashlan54@gmail.com Chidester Expires 28 February 2026 [Page 1] Internet-Draft PNNI Signaling in ATM August 2025 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Scope and Applicability . . . . . . . . . . . . . . . . 4 2. PNNI Signaling Model . . . . . . . . . . . . . . . . . . . . 4 2.1. Peer Group Structure . . . . . . . . . . . . . . . . . . 4 2.2. Topology Distribution . . . . . . . . . . . . . . . . . 5 3. Call Setup and Signaling Procedures . . . . . . . . . . . . 5 3.1. Call Setup Flow . . . . . . . . . . . . . . . . . . . . 6 3.2. Crankback Procedures . . . . . . . . . . . . . . . . . . 6 4. Quality of Service Signaling . . . . . . . . . . . . . . . . 6 4.1. Service Categories . . . . . . . . . . . . . . . . . . . 7 4.2. Traffic Parameter Negotiation . . . . . . . . . . . . . 7 5. Interoperability Considerations . . . . . . . . . . . . . . . 7 5.1. Protocol Version Compatibility . . . . . . . . . . . . . 8 5.2. Vendor-Specific Extensions . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.1. Topology Spoofing . . . . . . . . . . . . . . . . . . . 8 6.2. Resource Exhaustion Attacks . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Chidester Expires 28 February 2026 [Page 2] Internet-Draft PNNI Signaling in ATM August 2025 1. Introduction The Private Network-to-Network Interface (PNNI) is a hierarchical link-state routing protocol specifically designed for Asynchronous Transfer Mode (ATM) networks. PNNI provides automated topology discovery, dynamic routing, and Quality of Service (QoS) aware path selection capabilities that are essential for scalable ATM network operations. Originally developed by the ATM Forum in the mid-1990s, PNNI addresses the unique requirements of ATM networks, including support for multiple service categories, traffic management, and connection-oriented communication. The protocol operates across hierarchical peer groups, enabling scalable routing in large ATM networks while maintaining detailed QoS information for optimal path selection. This document revisits PNNI signaling principles in the context of modern networking requirements, identifies common interoperability issues encountered in multi-vendor environments, and proposes clarifications for current implementers and network operators. While ATM technology is considered legacy in many contexts, PNNI principles continue to inform modern network design, particularly in areas requiring strict QoS guarantees and hierarchical routing structures. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Scope and Applicability This document focuses on the signaling aspects of PNNI and is intended for network operators managing existing ATM infrastructure, implementers developing or maintaining PNNI-capable systems, researchers studying hierarchical routing protocols, and engineers migrating from ATM to modern networking technologies. Chidester Expires 28 February 2026 [Page 3] Internet-Draft PNNI Signaling in ATM August 2025 2. PNNI Signaling Model PNNI signaling operates through a distributed model where each ATM switch maintains local topology information and participates in network-wide topology distribution. The signaling model consists of several key components working in coordination to provide end-to-end connectivity establishment. 2.1. Peer Group Structure PNNI organizes ATM networks into hierarchical peer groups. Within each peer group, nodes exchange detailed topology information using the PNNI topology distribution protocol. Each peer group elects a Peer Group Leader (PGL) responsible for representing the group at higher hierarchy levels and aggregating topology information. The hierarchical structure enables scalable routing by reducing the amount of detailed topology information that must be maintained at each level. Lower-level groups provide summarized reachability information to higher levels, while detailed routing decisions are made locally within each peer group. 2.2. Topology Distribution Topology information is distributed through PNNI Topology State Elements (PTSEs), which are flooded within peer groups using a reliable flooding mechanism. PTSEs contain information about node connectivity and available resources, link characteristics including bandwidth, delay, and cost metrics, QoS parameters for different service categories, and reachability information for external addresses. The flooding mechanism ensures that all nodes within a peer group maintain consistent topology databases, enabling optimal path computation for connection establishment. Chidester Expires 28 February 2026 [Page 4] Internet-Draft PNNI Signaling in ATM August 2025 3. Call Setup and Signaling Procedures PNNI call setup procedures extend standard ATM signaling protocols with routing capabilities. The signaling process involves route computation, resource reservation, and connection establishment across potentially multiple peer groups. 3.1. Call Setup Flow The call setup process follows these major steps: route computation based on destination address and QoS requirements, resource reservation along the computed path, signaling message propagation using the computed route, and connection establishment and confirmation. Each step involves coordination between multiple network elements and MUST maintain consistency with PNNI topology information and QoS constraints. 3.2. Crankback Procedures When a connection setup fails due to resource unavailability or other constraints, PNNI provides crankback mechanisms to attempt alternate routes. Crankback information SHOULD include specific failure reasons to enable intelligent alternate route selection and avoid repeated failures. 4. Quality of Service Signaling PNNI provides comprehensive QoS signaling capabilities that enable connection establishment with specific performance guarantees. The QoS model supports multiple ATM service categories and allows for detailed specification of traffic parameters and performance requirements. 4.1. Service Categories PNNI supports signaling for all standard ATM service categories including Constant Bit Rate (CBR), Variable Bit Rate (VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR). Each service category has specific QoS parameters that MUST be considered during route computation and resource reservation. Chidester Expires 28 February 2026 [Page 5] Internet-Draft PNNI Signaling in ATM August 2025 4.2. Traffic Parameter Negotiation During connection establishment, PNNI signaling allows for negotiation of traffic parameters to accommodate network capabilities and resource availability. Parameter negotiation SHOULD be performed in a way that maintains the essential QoS requirements while allowing for reasonable flexibility in implementation. 5. Interoperability Considerations Multi-vendor PNNI implementations have historically faced several interoperability challenges. This section identifies common issues and provides guidance for ensuring successful deployment across heterogeneous environments. 5.1. Protocol Version Compatibility Implementations SHOULD support graceful degradation when communicating with nodes running different PNNI versions. Version negotiation mechanisms MUST be implemented to ensure baseline functionality across mixed environments. 5.2. Vendor-Specific Extensions Vendor-specific PNNI extensions SHOULD be designed to fail gracefully when interoperating with implementations that do not support these extensions. Critical functionality MUST NOT depend on vendor-specific features to ensure broad interoperability. 6. Security Considerations PNNI signaling introduces several security considerations that network operators and implementers must address to ensure network integrity and prevent unauthorized access or service disruption. 6.1. Topology Spoofing Malicious nodes may attempt to inject false topology information to redirect traffic or cause network instability. Implementations SHOULD implement authentication mechanisms for PNNI peer relationships and validate topology state information before accepting updates. Chidester Expires 28 February 2026 [Page 6] Internet-Draft PNNI Signaling in ATM August 2025 6.2. Resource Exhaustion Attacks Attackers may attempt to exhaust network resources through excessive connection setup requests or by advertising false resource availability. Rate limiting and resource reservation validation mechanisms SHOULD be implemented to mitigate these attacks. 7. IANA Considerations This document makes no requests to IANA. All protocol elements described in this document use existing ATM Forum assigned values or are implementation-specific parameters that do not require global coordination. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [ATM-FORUM-PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.0", ATM Forum af-pnni-0055.000, March 1996. [CHIDESTER-2024] Chidester, A., "PNNI (Private Network-Network Interface) Signaling in ATM Networks", MC Inc, March 2024. Chidester Expires 28 February 2026 [Page 7] Internet-Draft PNNI Signaling in ATM August 2025 Acknowledgments The author would like to acknowledge the foundational work performed by the ATM Forum in developing the original PNNI specifications, as well as the contributions of implementers and operators who have provided valuable feedback on PNNI deployment experiences over the years. Author's Address Ashlan Chidester Independent Researcher Email: ashlan54@gmail.com Chidester Expires 28 February 2026 [Page 8]