basis (that is, established SVC connections are not re-routed based on network states, etc.). In this section, we highlight some of the differences between the two ...
Beyond Private Networks: Impact of PNNI on Broadband Networking and Services Nicholas S. HUSLAK, Steven A. WRIGHT, and Amalendu CHATTERJEE Fujitsu Network Communications, Inc. 4403 Bland Road, Somerset Park, Raleigh, NC 27609 USA Abstract: This paper explores a wide range of opportunities for the interworking of the ATM signaling and routing mechanisms of B-ISUP/BICI-based public and PNNIbased private broadband networks. A spectrum of interworking scenarios is presented that ranges from simple virtual PVC tunneling to evolution of the public network to include PNNI capabilities .
1. Introduction The ATM Forum recently released the PNNI Version 1.0 [1] specification for a new network signaling and routing protocol for use at the interface between two private network switches. The two switches can be in the same private network or in different public networks, as the acronym has two meanings: Private Network to Network Interface, and Private Network Node Interface. PNNI offers dynamic source routing using a distributed routing function derived from the IETF Open Shortest Path First routing technique. In the private networking context, PNNI is the follow-on to its precursor (the Interim Inter-Switch Protocol) as the primary routing and signaling protocol to support multimedia data communications traffic. In a broader context however, work is underway by end-users, equipment vendors, public/private network providers, and industry forums to explore potential usage and impacts of PNNI beyond the enterprise network. This broader context includes public networks. In the public environment, the Broadband ISDN User Part (B-ISUP) [2] is the standard interface used internally between switches and the Broadband Inter-Carrier Interface (B-ICI) [3] is the standard B-ISUP-based interface used between public networks. Although the PNNI and B-ISUP/BICI standards were recently released, development of software for these interfaces has been underway for some time in the industry (see, e.g., [4] and [5]). In both cases, software providers are attempting to implement and release selected features of the protocols in a phased approach that will culminate in full support of the specifications by their products. This paper explores the wide range of opportunities for interworking between public and private broadband networks (see Figure 1 below) that use the fundamentally different PNNI and B-ISUP/BICI architectures, respectively, for their routing/signaling functions. After this introductory section of the paper, we shall illustrate in Section 2 the high level differences between the two architectures. Section 3 discusses four ways in which the two network architectures can be interworked in a spectrum of scenarios ranging from simple tunneling to evolution of PNNI capabilities into the public network. A summary of the findings in the paper as well as a list of issues for future industry work are provided in Section 4.
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… Private ATM Network
Public ATM Network
PNNI
User
STP Nwk.
PNNI
Signaling Links
UNI
P1
B-ISUP
P3
B-ISUP
Calling User
UNI
B-ISUP
P2 B1
PNNI
A1 PNNI
A2
A3 PNNI
Private ATM Network
PNNI
B2
Called User UNI
Figure 1 -- Public/Private Network Interworking 2. Public/Private Network Approaches to Routing and Signaling In this section, we illustrate the high level differences in the signaling and routing approaches employed in the public networks (employing B-ISUP and B-ICI) and private ATM networks (employing PNNI). User-Network Interface (UNI) signaling is used for access by end-users in both network environments. B-ISUP has evolved from the traditions of the public switched telephone network that gave rise to narrowband ISDN. Although it is not specified as such in the ATM Forum, BISUP is the predominant node-to-node interface used within the robust and feature-rich public networks. The ATM Forum BICI standards extend BISUP to support the interface between two public ATM networks. PNNI signaling and routing evolved from roots very different from those of BICI – the connection signaling is based on UNI signaling, while IETF Open Shortest Path First (OSPF) routing formed the basis for PNNI routing. As a result, PNNI has many significant differences from BICI, in, e.g., supported address formats, message formats, the dynamics of the routing algorithms, the degree of integration of signaling and routing, and the use of hierarchy concepts. Although the routing techniques can be considered to be distributed and dynamic in both public and private network environments, only the private network running PNNI offers dynamic changes to routing information resulting from significant changes to network topology and load. PNNI introduces other capabilities that are not offered in the public network. However, in general, the B-ISUP and B-ICI environment provides more feature richness (e.g., Advanced Intelligent Network / Intelligent Network Architecture features) than does PNNI. 2.1 Static versus Dynamic Routing PNNI provides an adaptive routing technique that includes mechanisms (i.e., exchange of hellos and flooding of database update packets) for the discovery of network topology. BISUP is based on an ‘alternate route’ scheme in which provisioning operations are typically
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… used to establish the routing tables. Both protocols perform route selection on a call-by-call basis (that is, established SVC connections are not re-routed based on network states, etc.). In this section, we highlight some of the differences between the two approaches. In the public network, two basic routing mechanisms have been used for some time: alternate routing and conditional routing. Alternate routing is based on a diversity of facilities that extend between some pairs of adjacent nodes. This relatively static alternate routing technique provides rules concerning the sequence of path attempts. Successive call attempts are said to overflow to alternate routes if the earlier paths are occupied. When the point of overflow control is at the first switch, this approach is known as originating office control. Spill forward (as opposed to source routing) occurs when there is movement forward (that is, toward the call destination) of the overflow control. Crankback is said to occur when the movement of overflow control is in the opposite direction. The second basic routing mechanism is conditional routing, which can be applied to map a connection setup to a particular route to be selected from two or more candidate routes. In an inter-LATA scenario for example, the Interexchange Carrier Number is the parameter used to condition (pre-select) the routes available for final route selection. In the ATM context, QoS parameters may be used for conditional routing. In PNNI, the routing function is based on the discovery of neighbors and link status, synchronization of topology databases, flooding of PNNI topology state elements, election of peer group leaders, summarization of topology state information, and, ultimately, on usage of the PNNI routing hierarchy for connection control signaling. In contrast to the hop-by-hop alternate routing techniques in the public network, PNNI routing is based on varying levels of knowledge of global topology and link states. The route is selected on the basis of some measure of cost (using administrative weights derived from topology and link status information), with the least-cost eligible candidate route selected. The advantages of this dynamic routing scheme include increased routability and the potential for easier ATM network deployment that results from the network discovery mechanisms. However, with these advantages comes the possibility of decreased route stability inherent in dynamic routing protocols. 2.2 The Use of Hierarchies for Signaling/Routing A high-level commonality between public and private networks is the construction of a routing hierarchy to reduce the network resources devoted to routing functions; however, these routing hierarchies vary greatly in their structure and usage. The public network hierarchy (which uses designated tandem switches and high usage vs. final trunks) is relatively static. In the public network, the hierarchy is typically geographically organized. Prior to the 1984 divestiture of the U.S. public telecommunications network, a very specific five-level hierarchy was used in that environment. At divestiture, the U.S. public network was administratively restructured for multiple public carriers with fewer restrictions. Non-hierarchical routing mechanisms such as Dynamic Non-Hierarchical Routing (DNHR) [6] have been deployed since divestiture in some administrative domains. A separate signaling network (based on the SS7 protocol suite) has also been deployed to improve the performance and functionality of public network signaling. In contrast, the PNNI routing protocol uses a hierarchy for the exchange of topology and node- and link-state information used in the path selection process (but not used by the signaling protocol for the routing of individual calls once the source route is constructed). The hierarchy used by PNNI can change over time autonomously with changes in peer groups (e.g., a peer group splitting into two peer groups), the election of new peer group leaders, etc. The route selection decision is made in PNNI networks at the originating node based on the
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… topology/link state information distributed via the routing hierarchy. The PNNI hierarchy is a logical arrangement that is not required to be geographically coherent. However, the use of address prefixes to identify groups of reachable addresses from higher levels nodes may tend to result in geographical or organizational coherence in the hierarchy. 2.3 Address Formats ATM supports addressing functions at various protocol layers to accommodate the integration of services over diverse media. For ATM connection management, two classes of addresses are defined at the call control level: native E.164 addresses, and three ATM End System Address (AESA) formats. The AESA formats provide for encapsulation of E.164 addresses, Destination Country Code (DCC) addresses, or International Country Code (ICD) addresses. The latter two formats are NSAP-style addresses that are geared to the needs of the data communications industry. In general, public networks use native E.164 (telephony) addresses, while private networks use the three AESA (data communications) formats. The native E.164 and AESA formats are designed to support large address spaces; however, the length of the ATM address field makes these formats difficult to use at the human/machine interface. Although textual representation formats have been agreed upon at the ATM Forum, the techniques (adding ‘.’ at appropriate places) are more intended for maintenance interfaces than for connection establishment interfaces. A more human-friendly approach uses names as pointers to addresses. Perhaps the most well-known example of this is in the global internet, where names such as ‘www.company.com’ are now widely advertised to consumers rather than numeric addresses. In the example of the global internet, the names are translated into IP addresses using a name server running the Domain Name Service (DNS) protocol. TCP/IP over ATM is expected to be a common application for ATM networks, particularly in private networks where PNNI is likely to be deployed. The ATM Name Service [7] will provide an extension to DNS to perform the name to ATM address translation. While this mechanism will also be available in public networks, other mechanisms are already available in that environment to perform such translation functions; for example, the SS7 network provides a mechanism for translating ‘800’ numbers into physical addresses. 2.4 Public and Private Network Signaling Approaches The different evolutionary paths that led to B-ISUP/BICI and PNNI have resulted in significant differences in the feature sets they support. With its roots in telephony, BISUP/BICI supports features such as proxy signaling and leaf-initiated join that are not yet supported under PNNI. Inside the public network, the B-ISUP protocol can be used in associated mode (i.e., direct signaling between public network nodes) or a separate network of signaling transfer points (STPs) can used, in which case the B-ISUP signaling is considered to be quasi-associated. PNNI does not require, nor can it currently utilize, the resources of quasi-associated signaling. In addition to its symmetric nature and data communications focus, PNNI introduces new signaling capabilities such as the following: • The support of designated transit lists (DTLs). DTL stacks are used to transfer current lists of nodes for routing a connection setup over a hierarchically complete source route. The source PNNI node inserts a DTL stack in the SETUP message containing a route through the entire network to a node serving the called user. The DTLs in the stack have increasingly higher routing hierarchy levels because the source switch knows less and less about the detailed network topology as the route gets progressively further away from it.
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI…
•
•
As the setup request enters peer groups at these progressively higher levels, the entry border node adds routing information to the stack to progress the call through the higher level peer group. Exit border nodes delete DTLs from the stack that have served their purpose and are no longer needed. The combination of crankback and alternate routing provides signaling support for attempting alternate paths, allowing a node to cope with out-of-date information due to changes in resource availability or otherwise inaccurate information that was used to create a DTL stack at the source or to update the stack at an entry border node. Signaling for the soft PVC capability (also called a ‘smart’ or ‘switched’ PVC) has no immediate counterpart in BICI. These virtual path and channel connections span the private network by joining two interfaces at border nodes of the private network via a single management action. Soft PVCs are resilient connections in the sense that users can count on re-establishment of the connection in the event of link failure. While soft PVCs may be of considerable commercial interest, detailed analysis of their role in public/private network interworking is beyond the scope of this short paper.
PNNI call connection procedures are based upon UNI signaling for point-to-point and point-to-multipoint connections. Significant extensions are required to process the DTL stacks that arrive in call establishment messages. In contrast, B-ISUP/BICI uses routing table entries are established before incoming call establishment messages arrive -- a routing table lookup specifies the routing of the subsequent B-ISUP Initial Address Message (IAM) without any significant PNNI-like processing of incoming information on the end-to-end route. 2.5 Other Aspects of Routing/Signaling Protocol Implementation. The details of the routing algorithms can be compared from a number of different perspectives, (for example, route tree structure, and handling of multicast). The following paragraphs provide an overview of some of the challenges faced by both routing protocols in the public and private network environments. Optimal network design considerations are heavily impacted by these routing protocols. The formulae for calculating blocking probabilities in the two environments differ, and depend on the routing protocol selected. The capacity assignment problem ranges from (1) The traditional public network approach of designing for low blocking probabilities on the final trunk groups; to (2) A link-by-link problem in the PNNI case. If a network failure occurs, the alternate routing schemes in the public network fall back to pre-provisioned alternate routes. In contrast, the PNNI approach relies on topology information exchanges which must propagate through the network immediately after the network failure. Transient states can occur with nodes receiving contradictory network updates form different sources until the network stabilizes. However, this topology exchange mechanism provides significant operational advantages with network discovery mechanisms: that is, the ability to turn up new equipment without pre-provisioning routing tables, thus potentially reducing deployment planning intervals. QoS based routing requires consideration of additional parameters -- either at network design time or during the connection establishment phase. The algorithms for allocation/accumulation of QoS across multiple networks is a study item in several industry groups. The approximations that hold for small networks may be different from those applicable to large networks. Other routing constraints such as ATM layer protection schemes (requiring disjoint routing mechanisms) may require support in the future. Performance is an aspect of routing with several dimensions of concern to network implementers that we can only list here, including route/connection establishment time,
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… topology exchange overhead, and route stability. While the public networks has provided many examples for the levels of performance achievable in large networks, PNNI performance beyond prototype implementations and simulations remains to be demonstrated. 3. Interworking Between Public and Private Networks There are many scenarios in which private and public broadband networks can be interworked to provide additional connectivity options to customers, thus speeding the acceptance of ATM technology and the deployment of emerging multimedia applications. Requirements for the interworking scenarios is expected to come primarily from large end users in private networks as they lead private network deployment of ATM. Before discussing these various scenarios however, we must digress briefly on addressing issues, as the overall interworking requires interworking between the address formats that are used in the public and private network environments as we discussed in Section 2. Although the address format issues are somewhat independent of the other routing/signaling interworking issues, there are concerns regarding the efficiency of various representations in terms of the routing performance achievable. Calling party and called party address interworking are both required. As we have already pointed out, the public network will not route on the basis of DCC- or ICD-based AESAs in the near-term; the E.164-based AESA is the only format that can be easily handled at the access and egress interfaces of the public network. A tool for interworking at the public/private boundary is provided by a new capability in BICI 2.0 that allows AESAs to be carried transparently from the originating public network switch to a destination switch at the other side of the public network where it can be used for further connection control beyond the public network. Thus, the address interworking can proceed in the following sequence: 1) at the access public switch, an AESA in the Calling Party Number (CPN) information element in UNI or PNNI signaling is translated to a destination public network address for use in the CPN parameter needed inside the public network. The newly approved AESA for CPN parameter carries the AESA across the public network; and (2) At the egress public switch, the AESA in the new parameter is extracted and used to construct the CPN information element used in for further UNI or PNNI signaling. The process of translating AESAs to E.164 addresses has been the subject of many debates in the ATM Forum; proposals have ranged from a simple longest-prefix match (on the AESA against a table of summarized AESA / E.164 mappings) to usage of Advanced Intelligent Network and ATM Name Server functionality. Factors in favor of the longest prefix match approach are the proliferation of AESA types (with the recent ATM Forum acceptance of a wider range of AESA types), local variations in AESA usage, and complications arising from portability and mobility constraints. Other issues under discussion for address translation include returning translation results upstream for caching purposes [8], and using a system of collaborating databases [9] across network boundaries via arrangements between public and private operators. Returning to the interworking scenarios, we will use continue to use Figure 1 from the introduction as our example network configuration that includes both public and private segments. For the sake of simplicity, we will emphasize the case involving one public network (at the center of Figure 1) and one private network (pictured at the bottom of Figure 1), as the
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI…
Public ATM Network
P3
P1 Calling User
P2 B1
A1 A3
B2
A2 Private ATM Network
Called User
Projected Link
Figure 2 – Link Projection cases involving multiple private and public networks would involve additional considerations. In the subsections below, we will consider four interworking scenarios based on the projection of the public ATM network as seen by the PNNI network: (1) Link Projection, in which the public network is part of a PNNI link; (2) Single Node Projection, in which the public network is represented as a single PNNI node in the private network; (3) Multiple Node Projection, in which the public network is represented in the private network by two or more connected PNNI nodes; and (4) Node-for-Node Projection, a scenario where PNNI capabilities would be supported within the public network. Finally, we shall consider supporting the important case (2) above with several valid PNNI subset implementations defined in the PNNI specification. 3.1 Link Projection In this least complex example of interworking (see Figure 2, simplified from Figure 1), the public network is represented as part of the link between two private nodes (A3 and B1 in this case). First, let us briefly review processing of DTL stacks as the connection setup proceeds from the calling user to the called user. Suppose that nodes A1, A2, and A3 were collected to form peer group A, and nodes B1 and B2 are collected to form peer group B. Once the PNNI routing hierarchy in the private ATM network has been established, the called user can signal via the UNI for a connection to the called user. Node A1 builds a DTL stack { (AB) (A1A2A3) } for the connection. At the top of the stack (the rightmost DTL in our notation), the stack indicates how peer group A is to be traversed. The next (and in this case, the last) DTL indicates the routing at the next higher layer, i.e., node A to node B. Current transit pointers (indicated by underlining in our example stacks) indicate the position of the receiver in the DTLs . Node A2 merely advances the pointers and sends the stack { (AB) (A1A2A3) } to node A3. A3 recognizes from the pointer position that the peer group has been crossed, and the topmost DTL can thus be popped from the stack. The SETUP that it sends to B1 contains the stack { (AB) }. B1 recognizes its ancestor node B in the stack, pushes a route across node B onto the stack, and sends the stack { (AB) (B1B2) } to node B2. B2 pops the both DTLs in order in the stack as they point to node B2 or its ancestors, with no further routing to be performed at either level. With a now-empty DTL stack, node B2 recognizes that it serves the called user, and can signal accordingly with UNI signaling across the egress interface.
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… Interworking with B-ISUP arises in this scenario on the PNNI link joining nodes A3 and B1. In actuality, this link includes a traversal of public network nodes P1, P2, and P3. Thus, node P1 must interpret incoming PNNI signaling from node A3 before sending B-ISUP signaling across the public network. (In an alternative to the demand-based implementation described, a previously-configured connection across the public network can be used to carry PNNI signaling and user plane traffic.) Node P3 eventually receives and unpacks the B-ISUP message, including the transparent DTL information. It constructs a PNNI SETUP for transmittal to private node B1. When B1 receives the SETUP, the message is analyzed as if it came from private node A3 rather than from public node P3. The link between PNNI nodes A3 and B1 provides connectivity for information flows associated with (a) user plane traffic; (b) per-call PNNI signaling; and (c) PNNI routing topology exchanges. Note that the traffic characteristics of these information flows are different. The public network will be responsible for (1) establishing VCs and mapping the PNNI information flows into the appropriate ATM VCs for transport across the public ATM network; and (2) Performing transparent encapsulation of DTLs within IAM messages to support PNNI tunneling across the public network. The public network nodes do not appear (singly nor jointly) in PNNI DTLs in this scenario (see the discussion in [10]). The public network may use PVC or SVC mechanisms to establish the VC(s) necessary to connect the PNNI nodes. The specific triggers for SVC establishment / tear-down require further study. 3.2 Single Node Projection The PNNI specification contains a single page informative appendix (that is not required for compliance) describing the use of PNNI to connect non-PNNI routing domains such as public networks. In this scenario, which we call single node interworking, the entire public network is represented by a single PNNI node that we call the projected PNNI node. The scenario is illustrated in Figure 3,. Single node projection adds significant complexities compared to interworking using link projection. Increased flexibility comes from modeling the public network as a PNNI node using the complex node representation (CNR) as described in the PNNI specification. The CNR models the interior of the public network as the nucleus of the projected node, while the border nodes of the public network appear as ports on the projected node. Routes from one border node to another in the public network are modeled as spokes by the CNR. Thus, connectivity across the public network is advertised by the projected node using abstracted spoke information, resulting in the flexible offering of on-demand connections between pairs of border nodes (as opposed to the use of fixed access/egress points in virtual PVC tunneling over leased facilities). Many issues on this scenario are under discussion in the ATM Forum (see for example [10, 11, and 12]) such as the following: (1) How should a network topology server (or servers) be configured in the public network for the topology database? (2) How can security concerns be addressed, e.g., the release of abstracted public network topology information to users and private network operators? (3) Are the required PNNI capabilities practical for the public network to offer, considering the many other concerns already present in that environment, e.g., regulatory, network availability, congestion, emergency preparedness, and privacy? [8]; and (4) How should the public network efficiently handle the regular exchange/transport of PNNI topology information? We shall revisit single node interworking in Section 3.5 where we discuss implementations using several defined subsets of PNNI.
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI…
Public ATM Network
P3
P1 Calling User
P2 B1
A1 A3
B2
A2 Private ATM Network
Called User
Projected PNNI Node B0.
Figure 3 - Single Node Interworking 3.3 Multiple Node Projection Figure 4 illustrates the projection of the public network as multiple nodes in the PNNI network. In this third interworking scenario, the public network is represented by two or more connected PNNI nodes, each of which translates between PNNI and B-ISUP signaling at its border nodes. This interworking technique may be useful in a public network that has two or more large clusters of nodes (possibly when the clusters are in different administrative domains), each of which is extensively intraconnected and joined to one or more of the other clusters by a few high speed/bandwidth links. A pointer to future work on multiple node projection in the final sentence of the PNNI specification may be the only support for this approach to appear thus far in the literature. The complexity of multiple node interworking may render implementation less likely that the other scenarios discussed in this paper. We will not discuss this scenario further here because of space limitations. 3.4 Node-for-Node Projection A full migration of PNNI capabilities into the public network (i.e., support inside the network, not just at the boundaries) is an ambitious undertaking because of differences in signaling and routing infrastructure between the PNNI and BICI/B-ISUP architectures. We call this full migration scenario ‘node-for-node projection’, as each public ATM network node is projected separately onto the private network. It remains to be seen whether such a fundamental change in B-ICI/B-ISUP/TCAP functionality is needed (in the longer term) to accommodate private network needs. Large existing carriers may resist migration to this scenario because a logical partitioning of public networks to provide solutions for private network interworking is not dependent on node-for-node projection and requires less drastic changes to the public network. In any event, migration towards this scenario must be compatible with the concurrent technical developments in the public and private networking arenas. Although the line between these formerly disparate worlds is becoming increasingly blurred, neither public nor private network providers are likely to allow interworking concerns
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI…
Public ATM Network
P3
P1 Calling User
P2 B1
A1 A3
PNNI
B2
A2 Private ATM Network
Called User
Projection to two PNNI Nodes
Figure 4 - Multiple Node Projection (especially those for node-for-node projection) to sidetrack efforts to deploy equipment to provide revenue-producing services to their customers. Interworking in this case would be fairly straightforward as PNNI would be used end-to-end, thus providing the enterprise network user with the ability to build more detailed and flexible source routes encompassing both network environments. Besides the cost of implementation (this scenario requires the largest changes to B-ISUP/B-ICI of the scenarios we have discussed), some technical issues for this scenario will require resolution. For example, the security issues mentioned in the other scenarios become much more important in the node-for-node projection approach because relatively raw public network information would presumably be distributed outside the public network to enable efficient routing. Node-for-node projection implementations would likely begin with the introduction of rudimentary dynamic source routing capabilities, perhaps using single-level hierarchies and other simplifications to get started. 3.5 Interworking Using Valid PNNI Subset Implementations Let us complete our discussion of the single node interworking scenario in Section 3.2 by analyzing how the defined PNNI subset implementations have varying capability to support logical group and lowest level node public network projections onto a private network. As we shall see, the job of the projected PNNI node depends greatly on where it is inserted in the PNNI routing hierarchy, i.e., how the network designer chooses to form peer groups given the presence of a projected node (e.g., node B0 in Figure 3). First, let us summarize the defined subset implementations shown in Figure 5 (from Annex G of the PNNI specification) that are still considered to be valid implementations of PNNI. The minimum functional subset implementation is a simple interior PNNI node, i.e., a node supporting PNNI links to other nodes in its peer group only. To this minimum subset, implementers can add border node capability, the peer group leader / logical node capability, support for the complex node representation, and other options such as Soft PVCs. Once the border node capability has been added, the implementers can, in addition, choose to allow a lowest level node in the switching system to be able to communicate with logical group nodes should this capability be required in the planned routing hierarchy.
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… BASE SUBSETS
OPTIONS
Border node with LGN peer support PGL/LGN Border node
Exterior address Alternate routing Complex node rep. Soft PVPCs/PVCCs ATM traffic desc. neg. etc.
Minimum function
Figure 5 -- Definitions Of PNNI Subset Implementations We can now consider using the subset implementations to support the projection of the public network as a Logical Group Node (LGN) case or Lowest Level Node (LLN) case. • In both LGN and LLN cases, all of minimum function capabilities are required in all public nodes having connectivity via PNNI to private network. • The Peer Group Leader/LGN capabilities are not needed in either case unless the projected node desires to be the leader of the projected node’s PNNI peer group. Note that in the LGN case, one border node in the public network must act as the leader of the group of the public network nodes. This coordination function is not the same as peer group leadership, since the links connecting the public network ‘peer group’ are not using PNNI for interconnection between themselves. This is a separate issue from having the LGN projection being capable of acting as the leader of the (projected node) peer group. • For both the LLN and LGN cases, a capability similar to the Complex Node Representation must be available. The peers of the projected node must recognize topology exchange transmissions from the projected nodes as if the true PNNI complex node representation had been used. In reality, the reachability information advertised by the projected node is constructed artificially, as PNNI node and link state information is not exchanged between the public network nodes (hence, no PNNI aggregation technique can be directly applied). • None of the other options in the rightmost box in Figure 5 are required in order to support a projected PNNI node. • For both LGN and LLN cases, the border node capability is needed only when the projected PNNI node lies at the border of its peer group. When the projected PNNI node is PGL/LGN capable, the border node capability may also be needed at higher levels in the hierarchy. • Finally, the border node with logical group node peers capability is needed when the projected PNNI node or its ancestors are to have LGN peers at their level in the hierarchy. 4. Conclusions and Further Work Needed Preliminary implementations of the approved PNNI specification are being deployed in private networks. We have identified the four increasingly complex ways in which public ATM networks can add value by providing connectivity between PNNI-based private ATM networks. In each of the four scenarios, a different view (i.e., projection) is selected for the public network as seen by the PNNI network. 1. Link Projection: Various forms of PVC-based link emulation are feasible today to support link emulation. With some incremental industry agreements (and, in the case of quasi-
N. Huslak, S. Wright, A. Chatterjee / Impact of PNNI… associated signaling, B-ISUP deployments in the SS7 network), SVC capabilities can be added that significantly improve the scalability of this approach. 2. Single Node Projection: Emulation of the public network as a single PNNI node provides the potential for introducing PNNI features such as network discovery at the edge of the public network. However, considerable additional development and deployment effort would be required to achieve this interworking arrangement. 3. Multiple Node Projection: The costs and benefits associated with this approach have not yet been fully explored, although there are several candidate scenarios in which such an approach might make sense. 4. Node-for-Node Projection: This scenario does not leverage existing network deployments or expertise, and so may be of interest only to non-traditional public ATM network operators (for example, Internet Service Providers and cable operators). The introduction of some new features in B-ISUP to provide compatibility with PNNI seem appropriate. Identification of the specific capabilities required (i.e., from minimum functionality to all options) is for further study. The evolution of interworking from the simple tunneling of private connections over permanent public connections to more complex arrangements will be an ongoing task in the industry. We have identified many open issues for this investigation. Other issues will arise when the interworking is applied to various other network topologies such as (1) point-tomultipoint connection topologies, e.g., the case where some called user leaves are situated in the public network and some are in the private network; (2) mixed network topologies involving, for example, B-ISDN and N-ISDN networks; and (3) complications to PNNI/BICI interworking that arise when ATM networks are used as the infrastructure for internetwork level connections, for example, multisender scenarios using RSVP when providing internet integrated services, and shortcut routing techniques. As a closing remark, we note that the implementation of any of these interworking scenarios can only be driven by real user needs and the commercial vision of the network operators. Deployment of interworking will begin with the simplest scenarios that serve immediate needs before any progress is made to more complex scenarios. References [1] [2 ] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
Dykeman, D., Private Network-Network Specification Interface Version 1.0, ATM Forum Technical Committee af-pnni-0055.000 Letter Ballot, March 1996. Functional description of B-ISUP, ITU-T Recommendation Q.2761, 1995 Editor, Broadband Inter-Carrier Interface Definition v. 2.0, ATM Forum Technical Committee, 1996. Trillium Digital Systems Inc. Announces New ATM PNNI Routing Source Code, Business Wire, May 17, 1996 Kettler, D.A. et al, Evolution of the North Caroling Information Highway, IEEE Network, Nov./Dec. 1994, Vol. 8, No. 6, pp. 64-70 Ash, G.R., et al, Design and Optimization of Networks with Dynamic Routing, Bell System Technical Journal, Vol. 60, pp. 1787-1820, 1981. Nadas, S., ATM Name Service, ATM Forum Contribution AF/95-1532R3 , June 1996. Shaver, T., NSAP and Public E.164 address Interworking Issues, ATM Forum Contribution AF/96-0809, U.S. Department of Defense, June 1996. Epley, R., Address Translation Architectures, ATM Forum Contribution AF/95-0401, April 1996 Hummel, H., Interconnected PNNI Peer Groups by Means of Public Trunks, ATM Forum Contribution AF/96-0638, Siemens Munich Germany, June 1996 Ohba, T., et al, Possible Scenarios for Interworking Between PNNI and BICI, ATM Forum Contribution AF/95-0756, June 1996 Epley, R., Public Private Network Interface Workplan Suggestions, ATM Forum Contribution AF/950400, April 1996
