|
|
PNNI-1
Private Network to Node Interface
-- Phase One
by
Michael Patterson |
- Disclaimer
- This interpretation of PNNI-1 technology is
based almost entirely on the af-pnni-0055.000 PNNI-1
specification from the ATM Forum. The author of this paper
has done his best to correctly explain this protocol and
related topics. This document is intended to simplify many
of the topics discussed in the PNNI-1 specification, and
because of this, many sentences and even some paragraphs in
this document are taken directly from the stated
specification. The author of this paper has attempted to
provide a fair example of a scalable PNNI-1 network, which
may not be the best configuration for every situation. The
following material is not necessarily proprietary to
Enterasys equipment, though Enterasys devices are used in
most of the examples.
This white paper intends to explain PNNI-1
in a basic configuration with little regard for proper
network design. Network design in an ATM infrastructure
needs to take into account the applications running on the
network (database, video streaming, Web, etc.), the number
of end stations, the QoS necessary for the end users (UBR,
ABR, VBR, CBR, etc.), critical nodes, and the higher layer
protocols being used (IP, IPX, AppleTalk, DecNET, etc.).
Because of the enormous amount of information involved,
design is not considered in this document.
- Assumptions
- The author of this paper assumes that the
reader has an understanding of basic ATM principles such as
the 20 byte NSAP address, UNI signaling, VCC, PVC, SVC, VPI,
VPC, VCI, CAC, RIP, OSPF, B-ICI, LANE concepts (LES, BUS,
LECS, LEC, etc.), and basic QoS considerations. Due to the
length of NSAP addresses, it becomes laborious to type them
repeatedly. In an effort to save time and preserve the
author's sanity, most of the NSAP addresses used in this
paper are abbreviated. For example,
39.0000.00.000045.004A.952D is often written as 952D or
~952D.
- Why PNNI-1?
- Most ATM network administrators have
experienced the frustration of documenting the NSAP
addresses of every ATM switch for static route purposes.
Little did we understand when we purchased the ATM equipment
that setting up IISP routes could be so tedious and
unforgiving.
Imagine a routed network containing 500
routers, all of which need to know about each other in the
event of a possible data transfer. Using a protocol such as
RIP, each router would have at least one route to each of
the 499 other routers. Some routers would be in a single
routing table more than once, as redundancy was probably
configured into the network to maintain fault tolerance.
Imagine then, that every routing table roughly 500 entries
per router must be sent to each of the 499 other routers
every 60 seconds. Consider the amount of traffic that this
would create.
PNNI-1 breaths new life into ATM networks,
especially those infrastructures where the enormous overhead
involved with IISP is simply not feasible. PNNI-1 automates
the routing table process and allows for greater scaling of
ATM enterprises. It has provisions for Quality of Service
(QoS) and because it is an ATM Forum standard, it allows for
interoperability among different vendors' switches.
Companies such as Enterasys are releasing powerful Ethernet
switches with high-speed ATM uplinks which support LANE and
the new 802.1p standard, allowing for priority queuing of
packets in the Ethernet switch. By integrating 802.1p into
Ethernet switches on the ATM periphery, the ATM uplink
running LANE can ask for QoS ABR connections based on 802.1p
parameters, thereby providing QoS connections across the ATM
fabric. Unlike 802.1p Gigabit Ethernet switches, ATM
switches have Call Admission Control (CAC), enabling a
congested ATM switch to refuse any additional calls. Not
only will Gigabit Ethernet routers, when congested, continue
to allow additional calls, but the QoS for existing
connections will decrease and the connections in place with
a lower 802.1p priority will suffer even greater. Because of
the connection-oriented nature of ATM, this technology is
the only reliable technology for true QoS.
Routing protocols requiring all routers to
understand the entire topology are not very scalable. OSPF
was therefore developed in an effort to deliver just enough
information to routers to create a connection. After all,
creating a connection is the real goal, not creating the
largest routing table ever engineered. PNNI-1 borrowed many
concepts from OSPF to deliver an ATM routing protocol which
could support networks even larger than the current
Internet.
- PNNI-1 and Peer Groups
- To explain the PNNI-1 ATM routing protocol,
it is best to begin with the smallest common denominator,
the node. A node, or switch, at the lowest level is called a
lowest level node. The nodes are organized into peer groups.
In PNNI-1 route determination, end systems
are identified by the 19 most significant octets of the ATM
NSAP. However, the peer group ID comprises one octet level,
and up to 13 octets of the most significant bytes of the
node's ATM address. For example, if the level is 96 (12
octets), the NSAP address,
39.0000.00.000045.004A.95CD.0130.00001D112233.00, can be
broken down as follows in PNNI-1 terms. The first 12 bytes
of this address, 39.0000.00.000045.004A.95CD.01, identify
this node/switch as part of a group. In fact, it is likely
that the address (NSAP) on this switch will be manually
changed by the administrator to match the peer group ID of
the others in the same group. This of course creates more
work for ATM administrators who configure these switches, as
they must determine the correct peer group ID. Changing the
switch prefix allows the switches in a peer group to share
some commonality. Think of it like the telephone system;
everyone in the state of Maine has a telephone area code of
207, and everyone in the state of New Hampshire has an area
code of 603. Later we will examine how these NSAPs can be
further broken down into smaller groups, thereby creating a
hierarchy. For example: Within the state of Maine there are
towns; 207-439 is the local exchange for Kittery, and
207-384 is the local exchange for South Berwick. This is in
effect the same principle used in a PNNI-1 routed topology.
Figure 1: This is an example of a PNNI-1
peer group. The peer group ID is seen to be
60.39.0000.00.000045.004A.95CD01, where 0x60 (96) is the
level and corresponds with the example discussed in the
earlier paragraph. A 20 byte NSAP is equal to 160 bits (20
bytes * 8 bits per byte = 160 bits per NSAP).
A switch will know if another switch is in
the same peer group (collection of logical nodes) after
"hello" packets are exchanged over a reserved VCC
with VPI=0 and VCI=18. A "peer group identifier"
is compared. Nodes whose peer group IDs match are said to
belong to the same peer group and are connected by what is
known as a "horizontal link." Nodes with differing
peer group IDs are said to be border nodes; the connection
between them is called a "border link."
PTSE
Each node in the peer group exchanges
"hello" packets which contain the immediate
neighbors and local state information, including the
identity and peer group membership of the node's immediate
neighbors, and the status of its links to those neighbors.
Each node then bundles its state information in "PNNI
Topology State Elements" (PTSEs), which are reliably
flooded throughout the peer group. Basically, PTSEs are a
collection of all PTSEs received from other nodes, which
represent the nodes' current view of the active network.
Keep in mind that these PTSEs transmitted between nodes also
include information such as metrics, bandwidth, and
administrative weight of individual links.
When neighboring nodes realize, by
comparing peer group IDs through the use of
"hellos," that they are in the same peer group,
they proceed to synchronize their "topology
databases." This process results in both nodes having
identical topology databases. These databases include
detailed local peer group connectivity information as well
as abstract information about remote peer groups
representing the rest of the PNNI-1 network. After database
synchronization between respective neighboring nodes has
been successfully completed, the link is advertised via PTSE
transmissions. PTSEs are sent to neighbors periodically
until the destination acknowledges the reception of the PTSE.
Routing entries created by PTSEs eventually time out and are
removed, unless they are refreshed by new PTSEs. Only the
node that originally sent a particular PTSE can re-originate
that PTSE.
The 0,18 VCC on which the
"hello" packets are sent is called the PNNI
Routing Control Channel (RCC). The "hello" packets
sent out periodically over this connection specify the ATM
End System Address, node ID, and the port ID of the link.
The peer group ID can also be sent to enable neighboring
nodes to determine whether they belong to the same peer
group.
To allow the PNNI-1 network to scale, and
to prevent every node from sending out its understanding of
the entire topology, a peer group leader (PGL) is selected
for each peer group. At any one time there is only one
active peer group leader per peer group. The role of the PGL
in the network is to disseminate information pertaining to
the PNNI hierarchy. See Figure 1.
The "Peer Group Leader Election"
(PGLE) process takes place to determine which node will be
the PGL. The node bidding the highest "leadership
priority" becomes the PGL. This PGL election process is
constantly occurring, and if the primary PGL fails, the node
with the next highest leadership priority becomes PGL. If a
race condition occurs where both nodes bid the same
leadership priority, the node with the highest node ID
becomes the PGL. When a node becomes the PGL it increases
its leadership priority to ensure stability. The PGL is
responsible for the upward flow of information about the
peer group (reachability and topology aggregation) to higher
level peer groups.
Note: Internal operation of a peer group
does not require a PGL. A PNNI domain configured as a single
peer group can achieve full connectivity even without a PGL.
This is how most vendors are releasing their switches with
PNNI-1 support today. Enterasys is releasing products
supporting PGL.
Figure 2: Nodes connecting two different
peer groups are called border nodes. The level of the peer
group is 80 (0x50), so all the peer groups should have 50 as
the first byte.
In Figure 2, a peer group is referred to
as a logical group node, which is addressable by a unique
ATM End System Address that may, for example, correspond to
the address of the lowest level node in the same switching
system but with a different selector value. This
representation depends on the policies and algorithms of the
peer group leader.
Figure 3: Here we see that each of the
individual peer groups is part of a larger peer group
(39.0000.00.000045.004A.95), which also has its own peer
group leader. To use the telephony analogy again, each of
the three "town" peer groups (CD, EF and 2D) are
in the "state of Maine" larger peer group (95).
In Figure 3, each of the logical peer
groups (58.39.0000.00.000045.004A.95EF, 58.39.0000.00.000045.004A.952D,
58.39.0000.00.000045.004A.95CD) is part of a
higher level peer group (50.39.0000.00.000045.004A.95).
Again, the first byte of each peer group is its level, in
this case 0x58 (88) for lower peer groups and 0x50 (80) for
the higher peer group. The lower peer groups are now
considered "child peer" groups by the "parent
peer" group (50.39.0000.00.000045.004A.95).
A parent peer group is identified by a peer group ID that
must be shorter in length than its child peer group IDs. Any
node capable of becoming peer group leader of the parent
group "50.39.0000.00.000045.004A.95"
(see the example in Figure 3) will be configured with its
parent peer group ID.
- Address Scoping
- As we have seen, the length of the peer
group ID indicates the level of that peer group within the
PNNI hierarchy; this is commonly known as the "level
indicator." 0 to 104 bits (104 bits = 13 bytes) is the
range of the level indicator. Similarly, reachability
information advertised by a PGL always has a scope
associated with it. The scope denotes a level in the PNNI
routing hierarchy, and is the highest level at which this
address can be advertised or summarized. If an address has a
scope indicating a level lower than that of the level of the
node, the node will not advertise the address. If the scope
indicates a level that is equal to or higher than the level
of the node, the address will be advertised in the node's
peer group. For example, in Figure 3 the PGL CD.5 will
advertise to the hierarchy the highest level address which
supports every node in the peer group (58.39.0000.00.000045.004A.95CD)
which is at level 88 (8 bits * 11 bytes). It will also
advertise support for PG: 58.39.0000.00.000045.004A.952D
(88 (decimal) = 01011000 (binary) = 58 (hex)). This is done
because the PGL CD.5 discovered that the adjacent PG is also
advertising level (88) which is equal to itself. Also, the
connection from PG: 58.39.0000.00.000045.004A.95CD to
PG: 58.39.0000.00.000045.004A.952D must be advertised
in order for the higher levels to accurately understand the
topology.
When summarizing addresses, the address
with the highest scope will determine the scope of the
summary address. The same rule applies to group addresses;
for example, if two or more nodes in a peer group advertise
reachability to the same group address but with a different
scope, their parent node will advertise reachability to the
group address with the highest scope. For example, in Figure
3 the PGL (95EF) is getting advertisements for three
different peer groups (CD, 2D and EF), all advertising a
level of 88. Since the higher level for PGL Ö.(95)EF is 80
or (0x50) and all the advertisements it is receiving match
at this level (50.39.0000.00.000045.004A.95), PGL: 95EF will
only advertise PG: 39.0000.00.000045.004A.95 up to a higher
parent if there is one. This said, PGL Ö95EF will advertise
peer group 50.39.0000.00.000045.004A.95 as being reachable
through itself. If that sounds complicated, consider the
telephony analogy and look at it another way. The PGL for
group 50.39.0000.00.000045.004A.95 will advertise for all
the towns in the state of Maine.
As mentioned earlier, the PGL is
responsible for the upward flow of information about the
peer group (reachability and topology aggregation) to higher
level peer groups. Reachability refers to the summarized
address information (explained later) needed to determine
which addresses can be reached through the lower level peer
groups. Topology aggregation refers to the summarized
topology information needed to route into and across this
peer group. This process prevents PTSEs flooded in a lower
level group from inundating the higher level groups and
other child peer groups.
Each member of the logical group (logical
group node) feeds information down to its own peer group.
This is done through the use of PTSEs which it originates or
receives from other members of the peer group. PTSEs flow
horizontally through a peer group; only a summary of the
PTSEs in the parent peer group are sent downward into and
through child peer groups. In other words, only information
about other states (New Hampshire, Massachusetts,
California, Texas, etc.) is sent downward into and through
the towns in the state of Maine.
Figure 4: This figure shows the result of
flooding PTSEs.
Through the process of PTSEs and the
summarization of other peer groups, an individual node
(switch) has an accurate picture of its own peer group and
an awareness of the other peer groups. An individual node
also knows which nodes in the peer group are
"gateways" to the other groups.
In order for a node to realize which
border nodes have connectivity with other higher level
nodes, the border nodes must advertise links to the higher
level nodes, enabling the information to be disseminated
through the use of PTSEs. For example, node 2D.2 in Figure 5
needs to send out PTSEs to its own peer group
(39.0000.00.000045.004A.952D), enabling the PGL to receive
this information and send it up to the parent peer group.
This connection to another peer group gained by border node
2D.2 is called an "uplink." In the telephony
environment, we have border towns. For example, Kittery,
Maine borders the town of Eliot, Maine. At the state level,
Kittery, Maine borders Portsmouth, New Hampshire.
Figure 5: This diagram shows the impact
that border nodes have on the topology.
In Figure 5, the logical node representing
peer group CD is called the upnode for peer group 2D, and
the logical link from 2D.2 to this logical node (upnode) is
called the uplink (shown as a bold dashed line). For certain
"hello" states, a border node must include an
Uplink Information Attribute (ULIA) information group in the
"hello" packets that it sends on each outside link
to neighboring border nodes (e.g. CD sends ULIAs to 2D.2).
The ULIA sent to an outside neighbor encloses a complete set
of information about the reverse direction resources to be
advertised in the uplink advertisement that the receiving
outside neighbor generates. In Figure 5, node 2D.2 would
advertise group 88.39.0000.00.000045.004A.95CD
via itself, and 39.0000.00.000045.004A.952D.2 via
PTSE to all other nodes in group 88.39.0000.00.000045.004A.952D.
The peer group leader of group 88.39.0000.00.000045.004A.952D
would summarize this information and send it out to the
parent peer group (80.39.0000.00.000045.004A.95).
Neighboring nodes at the lowest peer group
level (nodes in the same peer group) use a reserved VCC (0,
18) for their routing information exchanges (PTSEs and
"hellos"). However, the Routing Control Channel (RCC)
between logical peer groups is a switched virtual circuit
connection (SVCC); for example, a possible RCC might be 0,
43. The information required to establish this switched
virtual circuit connection (SVCC) is derived from the uplink
advertisements in the peer group.
Figure 6: This figure introduces another
peer group. Its important to note that similar to the
telephone system, we logically organize the towns into
states. We are physically limited, however, as to the
connections from one central office to another, and
sometimes we must traverse multiple towns to reach the final
destination.
In Figure 6, node 2D.3 learns of another
node and exchanges "hellos" to determine if they
are in the same peer group. Both sides of this link will
then begin to understand more of the topology. Node 81.4
realizes that 2D.3 is not in the same peer group and sends
PTSEs to its PGL (81.2) who in turn passes the information
saying that node 88.39.0000.00.000045.004A.B681
has connectivity to peer group 80.39.0000.00.000045.004A.95.
Notice how 81.4 is not mentioned in the advertisement which
81.2 sends up to the parent peer group: 80.39.0000.00.000045.004A.B6.
In Figure 6, peer groups 80.39.0000.00.000045.004A.B6
and 80.39.0000.00.000045.004A.95
realize that they are part of a parent (grandparent) peer
group (72.39.0000.00.000045.004A).
Figure 7: This figure shows an example of
a third peer group layer.
Notice in Figure 7 that node CD.3's view
of the network is growing, yet the node still does not know
all the specific details of every other peer group. Node
CD.3 has a routing table as follows:
| Level |
Prefix |
Address |
Address |
Address |
Address |
| 88 |
39.0000.00.000045.004A.95 |
CD.1 |
CD.2 |
CD.4 |
CD.5 |
| 88 |
39.0000.00.000045.004A.95 |
EF |
2D |
|
|
| 80 |
39.0000.00.000045.004A |
95 |
|
|
|
| 72 |
39.0000.00.000045.00 |
4A |
|
|
|
Address Summarization & Reachability
Address summarization is done to reduce
the amount of addressing information that must be
distributed in a PNNI network. By default, each switch
(node) should have its netprefix defined as a summary, so
that all the addresses derived from this netprefix are
represented in the summary. Only those internal ATM
addresses which cannot be summarized by the switches'
summary addresses are advertised explicitly.
- Designated Transit Lists
- In an effort to avoid the difficulties of
hop-by-hop call setup in traditional routing protocols such
as RIP, PNNI-1 uses a source routing mechanism where the
ingress switch decides the entire hierarchy path, known as
the Designated Transit List (DLT), across the PNNI-1
network. The DTL consists of a sequence of node or port IDs
traversing the peer group. Initially, this path is not
detailed as to the specific nodes within each peer group. To
get across specific peer groups, the first node (border
node) in a each peer group selects the specific path, in
detail, across its local peer group. Since QoS could be
involved in the connection, Call Admission Control (CAC)
must also be performed by each switching system; this
generally equates to the node that decides the path through
the specific peer group. If a node "switch" has
agreed to several calls needing QoS, and has decided that
its current "QoS availability" has been degraded
due to the requests, it will notify the other nodes in the
peer group, and the links affected through the use of PTSEs,
about this change.
A complete hierarchical source route represents a route
across a PNNI routing domain that includes each hierarchical
routing level between the current level and the lowest
visible level in which the source and destination are
reachable. This is expressed as a sequence of DTLs ordered
from lowest to highest peer group level and organized as a
stack (i.e., a last in, first out data structure). The DTL
at the top of the stack is the DTL corresponding to the
lowest level peer group. Though this may sound like a
mouthful, it is actually quite simple. Take a look at the
hierarchy in the following figure, and we will expand on the
designated transit list technique in a slow and logical
manner in the following paragraphs.
Figure 8: A High Speed Interface Module,
or HSIM, slides into a Enterasys hub and allows for fast
Ethernet, FDDI or ATM uplinks.
In Figure 8, HSIM-A has received an NSAP
address (39.0000.00.000045.004A.B682.0000.00001d445566.04)
from the LAN Emulation Server (LES) to which it would like
to make a connection. Via UNI, HSIM-A asks the switch to
which it is connected (CD.3) to make a connection to the
NSAP above. CD.3 may be able to build a few different DTLs
to set up the call, but based on QoS decisions or cost,
let's assume that the following DTL is chosen.
The DTLs are then built in a stack, with a
pointer specifying which node is next to set up the call:
DTL: [39.0000.00.000045.004A.95CD.3,
39.0000.00.000045.004A.95CD.4], pointer-2
DTL: [39.0000.00.000045.004A.95CD,
39.0000.00.000045.004A.952D,], pointer-1
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-1
The first DTL row is at level 88, which
specifies all of the switches in the local peer group. The
second DTL row is at level 80, which specifies the order of
the peer groups which will be involved in the call at this
level. The third DTL row is at level 72, which specifies the
order of the peer groups which must be traversed at this
level. The pointer at the end of each DTL specifies where in
the DTL the receiving ATM switch should be looking. When the
first DTL is completed it is removed, and the next DTL is
examined and expanded. This is a recurring process as the
connection proceeds. Let's look at the telephony analogy
again. We are trying to make a connection from Roundup,
Montana to Munich, Germany. The central office in Roundup,
Montana might build a DTL as follows:
- The first DTL would list all of the
towns across Montana in the direction of Munich,
Germany.
- The second DTL would list all of the
states across the USA in the direction of Munich,
Germany.
- The third DTL would list all of the
countries across the globe in the direction of Munich,
Germany.
Before forwarding the call request, CD.3
stores the contents of the call setup in case alternate
routing is required. CD.3 then forwards the call setup to
its neighbor CD.4, which examines the top DTL and notices
the DTL pointing to its own node ID. CD.4 looks for the next
entry in the top DTL, but finds that it is exhausted.
Looking at the next DTL, the next destination is peer group
2D. Since CD.4 is not in 2D, that is, CD.4 is not in the
peer group summarized into logical node 2D, it starts
looking to see how to get to 2D. CD.4 finds that an
immediate neighbor is in 2D, so it removes the top DTL and
advances the current transit pointer in the next DTL.
DTL: [39.0000.00.000045.004A.95CD,
39.0000.00.000045.004A.952D,], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-1
The next node "switch," 2D.2,
looks at the top DTL and sees that the current destination
is 2D. Since 2D.2 is in 2D, it looks at the next entry in
the DTL, and starts routing to ~004A.B6. Analyzing the
topology, 2D.2 finds that the path is through 2D.1, 2D.6 and
2D.3, so it pushes a new DTL onto the top of the list:
DTL: [39.0000.00.000045.004A.952D.2,
39.0000.00.000045.004A.952D.1
39.0000.00.000045.004A.952D.6, 39.0000.00.000045.004A.952D.3],
pointer-2
DTL: [39.0000.00.000045.004A.95CD,
39.0000.00.000045.004A.952D], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-1
For example, because we have reached the
end of Montana (CD), the first town in the next state (2D.2)
must build a DTL to get through its local state.
Since 2D.2 added a DTL to the stack and
may be involved in alternate routing, it stores the contents
of the received SETUP message and the contents of the DTL
that it added on top of the stack, before sending the packet
to 2D.1. 2D.1 first determines that the top DTL target has
not been reached, and that the DTL is not exhausted. 2D.1
changes the pointer to 3 and sets up a call to 2D.6 as
directed in the DTL.
DTL: [39.0000.00.000045.004A.952D.2,
39.0000.00.000045.004A.952D.1
39.0000.00.000045.004A.952D.6, 39.0000.00.000045.004A.952D.3],
pointer-3
DTL: [39.0000.00.000045.004A.95CD,
39.0000.00.000045.004A.952D], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-1
2D.6 first determines that the top DTL
target has not been reached, and that the DTL is not
exhausted. 2D.6 changes the pointer to 4 and sets up a call
to 2D.3 as directed in the DTL.
DTL: [39.0000.00.000045.004A.952D.2,
39.0000.00.000045.004A.952D.1
39.0000.00.000045.004A.952D.6, 39.0000.00.000045.004A.952D.3],
pointer-4
DTL: [39.0000.00.000045.004A.95CD,
39.0000.00.000045.004A.952D], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-1
Node 2D.3 first determines that the top
DTL target has been reached, and then that the DTL is
exhausted. Looking at the next DTL, the next destination is
peer group B681. Since 2D.3 is not B681 (i.e., 2D.3 is not
in the peer group summarized into logical node B681), it
starts looking to see how to get to B681. 2D.3 finds that an
immediate neighbor (B681.4) is in B681. Node 2D.3 removes
the top two DTLs and advances the current transit pointer to
the next DTL:
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
The next node "switch,"
39.0000.00.000045.004A.B681.4 (81.4), looks at the top DTL
and sees that the current destination is 81. Since 81.4 is
in 81, it looks at the next entry in the DTL, and starts
routing to peer group 82. Before forwarding the call
request, 81.4 stores the contents of the call setup in case
alternate routing is required. Node 81.4 then analyzes the
topology and realizes another peer group (B682) must be
added to the DTL. Node 81.4 creates a higher DTL through the
local peer group, which will allow the call to be set up to
peer group 82. The call is set up to node 81.5 with the
following two new DTLs which have been pushed onto the top
of the list:
DTL: [39.0000.00.000045.004A.B681.4,
39.0000.00.000045. 004A.B681.5
39.0000.00.000045. 004A.B681.1],
pointer-2
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-1
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
Node 81.5 first determines that the top
DTL target has not been reached, and that the DTL is not
exhausted. 81.5 changes the pointer to 3 and sets up a call
to 81.1 as directed in the DTL.
DTL: [39.0000.00.000045.004A.B681.4,
39.0000.00.000045. 004A.B681.5
39.0000.00.000045. 004A.B681.1],
pointer-3
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-1
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
Node 81.1 examines the top DTL and notices
the DTL pointing to its own node ID. 81.1 looks for the next
entry in the top DTL, but finds it is exhausted. Looking at
the next level DTL, the destination is peer group 82. Since
81.1 is not in 82 (i.e., 81.1 is not in the peer group
summarized into logical node 82), it starts looking to see
how to get to peer group 82. 81.1 finds that an immediate
neighbor is in 82, so it removes the top DTL and advances
the current transit pointer in the next DTL.
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
The next node "switch," 82.4,
looks at the top DTL and sees that the current destination
is 82. Since 82.4 is in 82, it looks at the next entry in
the DTL, and starts routing to ~004A.B682. Analyzing the
topology, 82.4 finds that the path is through 82.2 and 82.1,
so it pushes a new DTL onto the top of the list. Before
forwarding the call request, 82.4 stores the contents of the
call setup in case alternate routing is required.
DTL: [39.0000.00.000045.004A.B682.4,
39.0000.00.000045.004A.B682.2,
39.0000.00.000045.004A.B682.1], pointer-2
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
Node 82.2 first determines that the top
DTL target has not been reached, and that the DTL is not
exhausted. 82.2 changes the pointer to 3 and sets up a call
to 82.1 as directed in the DTL.
DTL: [39.0000.00.000045.004A.B682.4,
39.0000.00.000045.004A.B682.2,
39.0000.00.000045.004A.B682.1], pointer-3
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
Node 82.1 determines that it is the DTL
terminator for the DTL stack, since all DTLs are at the end,
and
because 82.1 is the lowest level node and
has reachability to the destination. It then strips the DTL
stack from the SETUP message and forwards the message across
the UNI to the destination. Data transfer now takes place.
The whole process seems like quite a bit of overhead,
however most ATM switches can process over 150 calls per
second.
- PNNI-1 without PGLs
- PNNI-1 without PGLs would build large flat
infrastructures with no address summarization. For example,
node CD.3 would understand the complete connectivity of the
network, resulting in a much larger routing table and
greater overhead on the network for topology updates.
Running the entire topology with no peer group leaders is
fine for small groups of switches, as is the Routing
Information Protocol (RIP) for routed networks.
Figure 9: Node CD.3 understands all the
intricacies of the network if no PGLs or hierarchy are
defined.
In order for node CD.3 to setup a call to
HSIM-B the following DTL would be defined:
DTL: [39.0000.00.000045.004A.95CD.3,
39.0000.00.000045.004A.95CD.4, 39.0000.00.000045.004A.952D.2,
39.0000.00.000045.004A.952D.1,
39.0000.00.000045.004A.952D.6, 39.0000.00.000045.004A.952D.3,
39.0000.00.000045.004A.B681.4, 39.0000.00.000045.
004A.B681.5, 39.0000.00.000045. 004A.B681.1,
39.0000.00.000045.004A.B682.4,
39.0000.00.000045.004A.B682.2,
39.0000.00.000045.004A.B682.1], pointer-2
Initially this may seem like less work,
but the problem is that if the example architecture were
much larger in scale, the DTLs would be ridiculously long.
To follow with our telephony analogy, Roundup, Montana would
have to identify every town from Roundup to Munich, Germany.
- Crankback
- When creating a DTL, a node uses available
information about resources and connectivity. That
information may be inaccurate for a number of reasons,
including hierarchical aggregation and changes in resource
availability due to additional calls placed since the
information was produced. Therefore, a call being processed
according to the DTL may be blocked along its specified
route. Crankback and alternate routing are mechanisms for
adapting to this situation, rather than clearing the call
back to the source. When the call cannot be processed
according to the DTL, it is cranked back to the creator of
the DTL with an explanation of the problem. This node may
choose an alternate path over which to direct the call, or
may further crankback the call. An alternate path must obey
all received higher level DTLs, and must avoid the blocked
node(s) or link(s).
Crankback example:
Let's look back to when node 81.1 examines
the top DTL and notices the DTL pointing to its own node ID.
81.1 looks for the next entry in the top DTL, but finds that
it is exhausted. Looking at the next level DTL, the
destination is peer group 82. Since 81.1 is not in 82 (i.e.,
81.1 is not in the peer group summarized into logical node
82), it starts looking to see how to get to peer group 82.
81.1 finds that an immediate neighbor is in 82, so it
removes the top DTL and advances the current transit pointer
in the next DTL.
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
At this point, the call setup is blocked.
81.1 finds out either from the CAC internal to 81.1, or from
a RELEASE or a RELEASE COMPLETE message containing a
crankback, such as with blocked transit type #2, that
"call or party has been blocked at the succeeding end
of this interface," as indicated by the circle labeled
X in Figure 10.
Figure 10: A crankback example
The crankback procedure now begins with
81.1 sending a RELEASE message back through the preceding
interface. The crankback IE in the RELEASE message indicates
that the call was blocked at the link between 81.1 and peer
group 82.x, as determined from the DTLs from the received
SETUP message, and that the crankback level is 88 (the level
of peer group 81).
The RELEASE message is received at 81.5,
which did not create any DTLs for this call, so crankback
proceeds further. After or during the tearing down of the
succeeding virtual channel, the RELEASE message is sent out
the preceding interface in the direction of 81.4.
The RELEASE message is received at 81.4,
which specified a DTL for this call at level 88, so 81.4
attempts to do alternate routing. After eliminating the
blocked link from consideration, two different paths are
found across peer group 81 to peer group 82. The first
option is through 81.2 and on to peer group 82. The second
option is back through 81.5, 81.3, and then to 81.2 and over
to peer group 82. The first option is taken and the
following DTL is created.
DTL: [39.0000.00.000045.004A.B681.4,
39.0000.00.000045. 004A.B681.2],
pointer-2
DTL: [39.0000.00.000045.004A.B681,
39.0000.00.000045.004A.B682], pointer-2
DTL: [39.0000.00.000045.004A.95,
39.0000.00.000045.004A.B6], pointer-2
The call proceeds as outlined above.
Imagine if there were no hierarchy as
shown in Figure 9. The call would be cranked back all the
way to the ingress switch (CD.3), or Roundup, Montana.
- Summary
- PNNI-1 routing will be to ATM switches what
routing protocols are to routers. Interoperability between
various vendors is now possible in a plug-and-play
environment. No longer will we have to build ATM networks
and be concerned about all the necessary IISP routes.
"In the realm of ATM, PNNI is the
greatest thing since power steering. PNNI is an essential
element in building fault-tolerant ATM networks, and it is
also the enabling force behind plug-and-play ATM networks.
Never again will you spend your time meticulously reading 20
byte ATM addresses over the phone to manually update static
routes" (Network Computing, "ATM Switches:
Network Muscle Machines," p. 118).
|
|
E-Mail
Related