A P2MP TE network contains the following elements, which are shown in the figure below:

• The headend router, also called the source or ingress router, is where the label switched path (LSP) is initiated. The headend router can also be a branch point, which means the router performs packet replication and the sub-LSPs split into different directions.
• The midpoint router is where the sub-LSP signaling is processed. The midpoint router can be a branch point.
• The tailend router, also called the destination, egress, or leaf-node router, is where sub-LSP signaling ends.
• A bud router is a midpoint and tailend router at the same time.
• A P2MP tunnel consists of one or more sub-LSPs. All sub-LSPs belonging to the same P2MP tunnel employ the same constraints, protection policies, and so on, which are configured at the headend router.

Figure 1. Basic P2MP TE Tunnels

P2MP TE tunnels build on the features that exist in basic point-to-point TE tunnels. The P2MP TE tunnels have the following characteristics:

• There is one source (headend) but more than one destination (tailend).
• They are unidirectional.
• They are explicitly routed.
• Multiple sub-LSPs connect the headend router to various tailend routers.

The figure below shows a P2MP TE tunnel that has three destinations.

• PE1 is the headend router.
• P01 is a branch point router, where packet replication occurs.
• PE2, PE3, and PE4 are tailend routers, where the sub-LSP ends.

Between the PE and CE routers, PIM is enabled to exchange multicast routing information with the directly connected customer edge (CE) routers. PIM is not enabled across the P2MP TE tunnel.

Database of Sub-LSP Failure Errors

If any sub-LSP, whether P2MP or P2P, fails to recover after an SSO switchover, the failure is noted in an error database for troubleshooting. You can use theshow ip rsvp high database lsp command to display the error database entries.

Figure 2. Network Topology with P2MP TE Tunnel

RSVP TE extensions defined in RFC 4875 allow multiple sub-LSPs to be signaled from the headend router. A P2MP TE tunnel consists of multiple sub-LSPs that connect the headend router to various tailend routers.

The headend router sends one RSVP path message to each destination. The tailend router replies with a RESV message. The Label Forwarding Information Base (LFIB) is populated using the RSVP labels allocated by the RESV messages.

The P2MP TE feature does not support signaling of multiple sub-LSPs in the same Path/Resv message. If multiple sub-LSPs occur in the same message, the router sends a PathErr Unknown Objects message, and the Path/Resv message with multiple sub-LSPs is not forwarded.

The tailend routers allocate unreserved labels, which are greater than 15 and do not include implicit or explicit null labels. Using unreserved labels allows IP multicast to perform a Reverse Path Forwarding (RPF) check on the tailend router. Because a sub-LSP tailend router cannot be represented as a regular interface, a special LSP virtual interface (VIF) is automatically created. The LSP VIF represents the originating interface for all IP multicast traffic originating from the P2MP TE tailend router.

The figure below shows the LSP signaling process.

Figure 3. How LSPs Are Signaled

At the headend of the traffic engineering tunnel, through a static Internet Group Management Protocol (IGMP) group-to-tunnel mapping, IP multicast traffic is encapsulated with a unique MPLS label, which is associated with the P2MP TE tunnel. The multicast traffic is label switched in the P2MP tree and replicated at branch and bud nodes along the P2MP tree. When the labeled packet reaches the tailend (a PE router), the MPLS label is removed and forwarded to the IP multicast tree towards the end point.This process is shown in the figure below.

Note	The P2MP TE feature does not support penultimate-hop popping. Therefore, the egress router must allocate an explicit null or non-null label.

Figure 4. How Packets Traverse the P2MP Tree

When sub-LSPs share a common router (branch point) and use the same ingress interface of the router, the same MPLS label is used for forwarding. The multicast state is built by reusing the MPLS labels at the branch points, as shown in the figure below, where MPLS label 17 is shared by two sub-LSPs that both use router C.

Figure 5. Reusing MPLS Labels in Branch Points

You can either specify explicit paths or allow paths to be created dynamically. You can also specify bandwidth parameters, which are flooded throughout the MPLS network through existing RSVP-TE extensions to Open Shortest Path First (OSPF) and Integrated Intermediate System-to-Intermediate System (IS-IS).

The MPLS core network uses RSVP to enable end-to-end IP multicast connectivity. The tailend router and the end point router use PIM to exchange multicast routing information with directly connected CE routers. PIM is not configured in the MPLS core.

P2MP TE tunnels can co-exist with regular P2P TE tunnels. Existing path calculation and bandwidth preemption rules apply in this case.

You create IGP paths by enabling dynamic path computation, configuring explicit paths through CLI commands, or using both methods in your P2MP TE network.

• Dynamic paths are created using Constrained Shortest Path First (CSPF) to determine the best path to a destination. CSPF uses path constraints, such as bandwidth, affinities, priorities, and so on, as part of the computation.
• Explicit paths allows you to manually specify the path a sub-LSP uses from the headend router to the tailend router. You configure static paths on the headend router.

The P2MP TE feature provides the following benefits:

• You can configure signaling attributes, such as affinities, administrative metrics, FRR protection, and bandwidth constraints, when you set up P2MP TE sub-LSPs.
• P2MP TE provides a single point of traffic control. You specify all the signaling and path parameters at the headend router.
• You can configure explicit paths to optimize traffic distribution.
• You can enable FRR link protection and bandwidth protection for P2MP TE sub-LSPs.
• Protocol Independent Multicast (PIM) is not needed in the MPLS core. Only the non-MPLS interfaces on the tailend routers need to be configured with PIM.

A P2MP TE tunnel is operational (up) when the first sub-LSP has been successfully signaled. The P2MP TE tunnel is not operational (down) when all sub-LSPs are down. Certain events can trigger a tunnel re-optimization:

• One of the sub-LSPs is fast-rerouted to a backup tunnel (for dynamic LSPs).
• A link is operational. (if the command mplstraffic-engreoptimizeeventslink-up is configured).
• A periodic schedule optimization occurs through the mplstraffic-engreoptimizetimersfrequency command.
• The network administrator forces a tunnel optimization through the mplstraffic-engreoptimizecommand.
• An FRR protected interface becomes operational.
• A non-FRR LSP detects a remerge situation.

When a P2MP tunnel is reoptimized, a new LSP is signaled and traffic is moved to the new LSP.

To determine if a tunnel should be reoptimized, the router considers the following criteria:

• The router compares the number of reachable destinations between the new tree and current tree. If the new tree contains more reachable destinations than the current tree, the router performs a reoptimization. If the new tree contains fewer reachable destinations than the current tree, then the router keeps the current tree.
• The router verifies that the same set of reachable destinations in the current tree are also in the new tree. If the new tree does not contain the same destinations, the router keeps the current tree.
• The router compares the number of destinations in the new tree with the number of destinations in the old tree. If the number of destinations in the new tree is greater than the number of destinations in the current tree, the router switches to the new tree. This guarantees that the new tree will contain all of the existing destinations and more.
• The router compares the metric between the current and new tree to ensure the new tree and current tree contain the same set of reachable destinations.
• The router compares the administrative weights of the old tree and the new tree. The router switches to the new tree if the cumulative administrative weight is lower. This step applies as a tie breaker if all the other conditions are the same.

P2MP TE uses make-before-break reoptimization, which uses the following reoptimization process:

• The new LSP is signaled.
• The headend router initiates a timer to ensure sufficient time elapses before traffic moves from the current LSP to the new LSP.
• Traffic is redirected from the current LSP to the new LSP.
• The timer is started for the purpose of tearing down the old sub-LSPs.

Both P2P and P2MP TE tunnels share the following characteristics:

• Tunnel bandwidth is configured the same way in both P2P and P2MP tunnels. In P2MP TE tunnels, any bandwidth parameters you configure are applied to all the destination routers. That is, the bandwidth parameters apply to all sub-LSPs. Both P2P and P2MP TE tunnels use the same IGP extension to flood link bandwidth information throughout the network.
• Tunnel setup and hold priorities, attributes flags, affinity and mask, and administrative weight parameters are configured the same way for P2P and P2MP TE tunnels. P2MP TE tunnel parameters apply to all sub-LSPs.
• FRR-enabled P2MP sub-LSPs coexist with FRR-enabled P2P LSPs in a network. For P2P TE, node, link, and bandwidth protection is supported. For P2MP TE, only link and bandwidth protection are supported.
• The method of computing the path dynamically through CSPF is the same for P2P and P2MP TE.
• Auto-tunnel backup behaves slightly different with P2P and P2MP tunnels. With P2P tunnels, auto-tunnel backup creates two backup tunnels: one for the node protection and one for the link protection. The node protection backup is preferred for P2P LSP protection. With P2MP tunnels, auto-tunnel backup creates one backup tunnel, which is the link protection. Only the link protection backup can be used for P2MP sub-LSPs. The P2P and P2MP tunnels can coexist and be protected.

Note	If P2MP sub-LSPs are signaled from R1->R2->R3 and a P2P tunnel is signaled from R3->R2->R1, then issue themplstraffic-engmulticast-intactcommand on R3 in IGP configuration mode under router OSPF or IS-IS to ensure to accommodate multicast traffic for R3's sub-LSPs.

FRR applies to P2P LSPs and P2MP sub-LSPs in the same manner. No new protocol extensions are needed to support P2MP.

Note	For P2MP TE FRR protection, issue the iproutingprotocolpurgeinterface command on every penultimate hop router. Otherwise, the router can lose up to 6 seconds worth of traffic during a FRR cutover event.

FRR minimizes interruptions in traffic delivery as a result of link or node failure. FRR temporarily fast switches LSP traffic to a backup path around a network failure until the headend router signals a new end-to-end LSP.

FRR-enabled P2MP sub-LSPs coexist with FRR-enabled P2P LSPs in a network. For P2MP TE, only link and bandwidth protection is supported. Node, link, and bandwidth protection are supported for P2P TE.

You can configure P2P explicit backup tunnels on point of local repair (PLR) nodes for link protection of P2MP sub-LSPs, similar to LSPs for P2P TE tunnels. You can also enable automatic creation of backup tunnels using the Auto-tunnel Backup feature for P2P TE tunnels. All sibling sub-LSPs that share the same outgoing link are protected by the same backup tunnel. All cousin sub-LSPs that share the same outgoing link can be protected by multiple P2P backup tunnels.

Link protection for a P2MP TE tunnel is illustrated in the figure below, which shows PE1 as the tunnel headend router and PE2, PE3, and PE4 as tunnel tailend routers. The following sub-LSPs are signaled from PE1 in the network:

• From PE1 to PE2, the sub-LSP travels the following path: PE1 -> P01 -> P02 -> PE2
• From PE1 to PE3, the sub-LSP travels the following path: PE1 -> P01 -> P03 -> PE3
• From PE1 to PE4, the sub-LSP travels the following path: PE1 -> P01 -> P04 -> PE4

Node P01 is a branch node that does packet replication in the MPLS forwarding plane; ingress traffic originating from PE1 will be replicated towards routers P02, P03, and P04.

Figure 6. P2MP TE Link Protection Example

To protect the three sub-LSPs, separate point-to-point backup tunnels are signaled. Note that backup tunnels can be created only for links that have an alternative network path. In this example, router P01 is the Point of Local Repair (PLR) and routers P02, P03, and P04 are Merge Points (MPs).

If a link failure occurs between routers P01 and P04, the following events are triggered:

1. Router P01 switches traffic destined to PE4 to the backup tunnel associated with P04.
2. Router P01 sends RSVP path error messages upstream to the P2MP TE headend router PE1. At the same time, P01 and P04 send IGP updates (link state advertisements (LSAs)) to all adjacent IGP neighbors, indicating that the interfaces associated with links P01 through P04 are down.
3. Upon receiving RSVP path error messages and IGP LSA updates, the headend router triggers a P2MP TE tunnel reoptimization and signals a new sub-LSP. (This occurs if you have specified dynamic path creation.)

Note	If only one sub-LSP becomes active, it remains down until all the sub-LSPs become active.

Bandwidth Admission Control and preemption mechanisms for P2MP TE sub-LSPs are the same as for LSPs associated with P2P TE tunnels. Any link affinities or constraints defined for the P2MP TE tunnel will be taken into account. The bandwidth signaled for the sub-LSP is removed from the appropriate pool at the appropriate priority, and if needed, lower priority sub-LSPs are preempted with a higher priority sub-LSP.

A P2MP tunnel can be configured to use sub-pool or global-pool bandwidth. When bandwidth is configured, all sub-LSPs of the P2MP tunnel are signaled with the same bandwidth amount and type. If the bandwidth amount or type of a P2MP tunnel is changed, the P2MP tunnel ingress always signals a new set of sub-LSPs (a new P2MP LSP) with the new bandwidth amount and type.

Preemption procedures do not take into account the tunnel type. The same priority rules apply to P2P LSPs and P2MP sub-LSPs. A sub-LSP with a higher setup priority preempts a (sub-)LSP with a lower hold priority, regardless of tunnel type. Thus, a P2MP sub-LSP may preempt a P2P LSP, and vice versa. The determination of which LSPs get preempted is based on hold priority.

You can configure a P2MP TE tunnel to use subpool or global-pool bandwidth. All sub-LSPs associated with the P2MP TE tunnel are signaled with the same bandwidth amount and type. If the bandwidth amount or type is changed, the P2MP tunnel headend router signals a new set of sub-LSPs with the new bandwidth parameters.

Bandwidth sharing is similar for P2MP TE sub-LSPs and P2P TE LSPs. When adding a new sub-LSP, the P2MP-TE headend router determines whether it should share bandwidth with the other sub-LSPs. Two sub-LSPs can share bandwidth as long as they are a “Transit Pair,” meaning the sub-LSPs share the output interface, next-hop and output label.

LSPs and sub-LSPs cannot share bandwidth if they use different bandwidth pools. A change in bandwidth requires reoptimizing P2P or P2MP TE tunnels, which may result in double-counting bandwidth on common links.

Using FRR with Bandwidth Protection has the following requirements:

• A backup tunnel is required to maintain the service level agreement while the new sub-LSP is created.
• The PLR router selects the backup tunnel only if the tunnel has enough bandwidth capacity.
• The backup tunnel might not signal bandwidth.
• The PLR router decides the best backup path to protect the primary path, based on backup bandwidth and class type.

1.    enable


2.    configure terminal


3.    mpls traffic-eng tunnels


4.    ip multicast-routing [vrfvrf-name] [distributed]


5.    interface tunnel number


6.    tunnel mode mpls traffic-eng point-to-multipoint


7.    tunnel destination list mpls traffic-eng {identifierdest-list-id|namedest-list-name}


8.    ip igmp static-group {* | group-address [source{source-address| ssm-map}] | class-mapclass-map-name}


9.    ip pim {dense-mode [proxy-register {listaccess-list | route-mapmap-name}] | passive | sparse-mode| sparse-dense-mode}


10.    exit


11.    mpls traffic-eng destination list {namedest-list-name | identifierdest-list-id}


12.    ip ip-address path-option id {dynamic | explicit {namename | identifierid}


13.    exit


14.    ip explicit-path {nameword| identifiernumber} [enable | disable]


15.    next-address [loose | strict] ip-address


16.    end

Router> enable

Router# configure terminal

Router(config)# mpls traffic-eng tunnels

Router(config)# ip multicast-routing 

Router(config)# interface tunnel 100

Router(config-if)# tunnel mode mpls traffic-eng point-to-multipoint

Router(config-if)# tunnel destination list mpls traffic-eng name in-list-01

Router(config-if)# ip igmp static-group 239.100.100.101 source 10.11.11.11

Router(config-if)# ip pim passive

Router(config-if)# exit

Router(config)# mpls traffic-eng destination list name in-list-01

[verbatim]}

Router(cfg-te-dest-list)# ip 10.10.10.10 path-option 1 dynamic

Router(cfg-te-dest-list)# exit

Router(config)# ip explicit-path name path1 enable

Router(cfg-ip-expl-path)# next-address 10.0.0.2

Router(cfg-ip-expl-path)# end

No special configuration is needed to support the P2MP TE feature on the midpoint routers. The midpoint routers must have Cisco IOS Release 12.2(33)SRE or later release installed. They must be able to support and implement the P2MP signaling extensions. The MPLS TE configuration of the midpoint routers supports both P2P and P2MP TE. All multicast traffic is label switched. The midpoint routers do not require IPv4 multicast routing or PIM. For information on configuring MPLS TE, see MPLS Traffic Engineering and Enhancements.

1.    enable


2.    configure terminal


3.    ip multicast-routing [vrfvrf-name] [distributed]


4.    ip multicast mpls traffic-eng [rangeaccess-list-number | access-list-name]


5.    interface type slot / port


6.    ip pim {dense-mode [proxy-register {listaccess-list | route-mapmap-name}] | passive | sparse-mode | sparse-dense-mode}


7.    exit


8.    ip mroute [vrfvrf-name] source-addressmask{fallback-lookup {global | vrfvrf-name} | rpf-address | interface-typeinterface-number} [distance]


9.    end

Router> enable

Router# configure terminal

Router(config)# ip multicast-routing 

Router(config)# ip multicast mpls traffic-eng

or 

            
              interface
             type slot/port-adapter/port 

Router(config)# interface ethernet 1/1 

or 

Router(config)# interface fastethernet 1/0/0 

Router(config-if)# ip pim sparse-dense-mode

Router(config-if)# exit

Router(config)# ip mroute 10.10.10.10 255.255.255.255 10.11.11.11

Router(config)# end

To enable link protection for sub-LSPs associated with a P2MP TE tunnel, perform the following configuration tasks:

• Enable FRR on the headend router for each P2MP TE tunnel.
• Configure P2P backup tunnels for network interfaces that require protection.

See MPLS Traffic Engineering—Fast Reroute Link and Node Protection for information and configuration instructions.

MPLS Traffic Engineering system logging allows you to view the following events:

• Setting up and tearing down of LSPs
• RSVP Path and RESV requests
• Sub-LSP status (through path-change messages)

Commands to enable system logging include:

• mpls traffic-eng logging lsp path-errors
• mpls traffic-eng logging lsp preemption
• mpls traffic-eng logging lsp reservation-errors
• mpls traffic-eng logging lsp setups
• mpls traffic-eng logging lsp teardowns
• mpls traffic-eng logging tunnel path change

This section includes the following tasks: