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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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]