Page 185

6-7

Cisco AVVID Network Infrastructure Enterprise Quality of Service Design

956467

Chapter 6 QoS with MPLS in an AVVID-Enabled Network

Considerations for MPLS VPN QoS

To expand this to larger sites, the same routing configurations can be expanded to provide for multiple
primary and backup links. However, it is easiest to deploy this configuration when voice is kept on a
single link and video is kept on a single link (which may be the same link as voice). This way, the
network can be configured with substantially less effort and complexity. This makes it easier to create
ACLs to influence IP routing, both outbound from and inbound to the site, and to control the flow of call
setup when primary links are down.

Additionally, the SP can implement MPLS traffic engineering, which can be tailored to reduce the time
required for convergence in the event of a link failure within the MPLS backbone. Note that in this case,
there will be a minimum of three labels in the stack: one assigned by BGP for identifying the VPN, one
by the label distribution protocol (LDP), and one for traffic engineering.

To provide additional resiliency, the customer can use ISDN backup. A router can be deployed either
just for that customer, in which case it would function as another CE device, or for a pool of customers.

Note

In the past, support has not been available for CEF on dialer interfaces, which would eliminate the ability
to deploy MPLS on this node as a PE device. With IOS 12.2T, support was included for VRF-aware
dialer interfaces. Enabling an SP can use a single access server or router for multiple customers.

Using IP Multicast over MPLS VPNs

Initially, MPLS VPNs did not natively support IP multicast traffic. To provide for IP multicast traffic
(music-on-hold, broadcast video, etc.), GRE tunnels were provisioned allowing the IP multicast packets
to ride inside of IP unicast tunnels. Because the GRE tunnels were point-point, there was an inherent
scalability concern as the number of CE routers grew. In addition, the CE routers, which were the tunnel
endpoints, were required to perform a substantial amount of packet replication.

Then, multicast VPNs (MVPNs) were outlined in the IETF draft, Multicast in MPLS/BGP VPNs
(draft-rosen-vpn-mcast-03.txt). This draft defines three possible methods of providing for IP multicast
in a MPLS VPN environment:

Multicast domains--The PE router creates a multicast tunnel interface (MTI) and multicast virtual
routing and forwarding (VRF). The MTI encapsulates the customer multicast traffic within it's own
multicast packet for traversing the core.

VPN-IP PIM--The provider MPLS network runs PIM natively and the customer multicast VRFs are
leaked into the global routing table.

Multicast domain using PIM NBMA functionality--This creates a tunnel interface on the PE routers
and unicast encapsulates the multicast packets. This is very resource intense on the PE router as it
must replicate all multicast packets for each remote PE.

Cisco's implementation is based upon the multicast domain solution.

The provider must have a multicast-enabled core to use the Cisco MVPN solution. However, the
customer's IP Multicast network does not interact with the provider's multicast control plane. This
means that although the PE must interact with the CE router, the provider's multicast stability has no
dependency upon the CE's multicast stability.

Also, the MVPN solution does not require BGP to be deployed in the service provider core. However,
the PE routers must have MBGP for the next hop information. Note that only PIM-Sparse mode is
supported. Only PE routers that have connected CE routers which have requested to join this PIM group
will join the provider's multicast tree. The PE routers must be PIM adjacencies and have a BGP
relationship.