Beta Draft Confidential
Configuring PNNI Routing
PNNI Policy-based Routing
ATM Services Configuration Guide for CBX 3500, CBX 500, GX 550, and B-STDX 9000 1/19/0521-29
Application of Policy-based Routing
In this release, policy-based routing is not supported on VNN. The example in
Figure 21-7 illustrates how policy routing in the PNNI domain can be combined with
Layer 2 VPN service in a VNN domain to allow calls to cross VNN-PNNI-VNN
boundaries. These calls will be guaranteed to be routed over proper resources as
specified by the calling party.
In a VNN network, all VNN trunks are, by default, part of the “public” Virtual Private
Network (VPN). They are assigned a VPN ID of zero (0). In a VNN domain, using
Layer 2 VPN, a call belonging to a particular VPN will use path selection performed
in one of two ways via the Private Net Overflow option:
Restricted — path selection is performed considering VNN trunks of that partic-
ular VPN only. No other resources are eligible. If path selection fails, so does the
call establishment.
Non-restricted (Public) — path selection is performed considering both VNN
trunks of that particular VPN and VNN trunks of VPN 0. The preference is given
to VPN trunks.
However, in a PNNI network with policy-based routing, by default all PNNI links are
untagged, meaning that they are not assigned to any Ne-NSC or Rp-NSC. When
routing a call through a PNNI domain, especially a call originating from or
terminating on a non-restricted VPN VNN domain, the following rule needs to be
followed to preserve the characteristics of the call request during path selection
performed in the PNNI domain:
• Besides tagging some PNNI links with Ne-NSC_X and Rp_NSC_Y to reserve
resources for a particular VPN in PNNI domain, all other public PNNI links may
be tagged with another Ne-NSC value, which may be reserved by a service
provider.
To Next Page
Loading...
