P2MP TE
Point-to-multipoint (P2MP) traffic engineering (TE) is a promising solution to multicast service transmission. P2MP TE helps carriers provide high TE capabilities and increased reliability on an IP/MPLS backbone network and reduce network operational expenditure (OPEX).
Background
- IP multicast technology: deployed on a live P2P network with software upgraded. This solution reduces upgrade and maintenance costs. IP multicast, similar to IP unicast, does not support QoS or TE capabilities and provides low reliability.
- Dedicated multicast network: deployed using Asynchronous Transfer Mode (ATM) or synchronous optical network (SONET)/synchronous digital hierarchy (SDH) technologies. This solution provides high reliability and transmission rates, but has high construction costs and requires separate maintenance.
P2MP TE is such a solution. It combines advantages of efficient IP multicast forwarding and E2E MPLS TE QoS capabilities. P2MP TE establishes a tree-shape tunnel that originates from an ingress node and is destined for multiple egress nodes and reserves bandwidth for the multicast packets along the tree path. This provides sufficient bandwidth and QoS capabilities for multicast services over the tunnel. In addition, a P2MP TE tunnel supports fast reroute (FRR), which provides high reliability for multicast services.
Benefits
- Optimizes your network bandwidth resources utilization.
- Provides bandwidth assurance required by multicast services.
- Eliminates the need to use Protocol Independent Multicast (PIM) in the MPLS core.
Related Concepts
Name |
Description |
Example |
|---|---|---|
Ingress |
A node on which the inbound interface of a P2MP TE tunnel is located. The ingress calculates a tunnel path, establishes a tunnel over the path, and pushes MPLS labels into multicast packets. |
PE1 is the ingress. |
Transit node |
A relay node that processes P2MP TE tunnel signaling and forwards packets. A transit node swaps an existing label with an outgoing label in each packet. The transit node can be a branch node. |
P1 and P3 are transit nodes. |
Egress |
Also known as a leaf node on a sub-LSP. |
PE3, PE4, and PE5 are egresses. |
Sub-LSP |
An LSP that originates from an ingress and is destined for a single egress. It is also known as a source-to-leaf (S2L) sub-LSP. A P2MP TE tunnel consists of one or more sub-LSPs. |
On the network shown in Figure 4-49, PE1 -> P3 -> P4 -> PE4 is a sub-LSP. |
Bud node |
A node functioning as both an egress and a transit node. This node is connected to a device on the user side. NOTE:
A P2MP bud node has low forwarding performance because it has to replicate traffic to directly connected client-side devices. |
PE2 is a bud node. |
Branch node |
A type of transit node. A branch node copies an MPLS packet, swaps MPLS labels with outgoing labels in the copied MPLS packets, and sends duplicate MPLS packets along sub-LSPs. |
P4 is a branch node. |
P2MP TE Tunnel Establishment
Similar to the process for establishing P2P TE tunnels, the process for establishing P2MP TE tunnels consists of bandwidth advertisement, path calculation, and path establishment stages. Interior Gateway Protocol (IGP) TE is used to advertise bandwidth information for P2MP TE tunnels. Distinct path calculation and establishment processes are used for P2MP TE tunnels. Inter-IGP-area or inter-AS P2MP TE tunnels are not supported.
Path calculation and planning
The NE20E uses constraint shortest path first (CSPF) to calculate a path that originates from the ingress and is destined for each leaf node. The calculated paths form a shortest path tree. P2MP TE supports the explicit path technique. A user can configure an explicit path for a specific or every leaf node. The explicit path technique facilitates path planning, but causes the following problems:
- Crossover event: occurs when two sub-LSPs have different inbound and outbound interfaces on a transit node. Figure 4-50 illustrates that a crossover event occurs on the transit node shared by the two sub-LSPs. If a P2MP TE tunnel is to be established over these paths, duplicate bandwidth is reserved on the transit node for the tunnel.
- Re-merge event: occurs when two sub-LSPs have different inbound interfaces but the same outbound interface on a transit node. Figure 4-50 illustrates that a re-merge event occurs on the outbound interface shared by the two sub-LSPs. If a P2MP TE tunnel is to be established over these paths, duplicate MPLS packets are forwarded through the outbound interface.
The ingress cannot establish a P2MP TE tunnel after detecting either a crossover or re-merge event. A user can modify an explicit path for a sub-LSP to resolve a crossover or re-merge problem.
Establishing a tunnel
Standard protocols define a new RSVP extension that can be used to establish a P2MP TE tunnel properly. Similar to a P2P TE tunnel, a P2MP TE tunnel is established using Path and Resv messages that carry RSVP-TE signaling information. Path messages originate from the ingress and travel along an explicit path to each leaf node. Leaf nodes reply with Resv messages in the opposite direction of Path messages. After receiving a Resv message, a node reserves bandwidth for a sub-LSP to be established. After receiving all Resv messages, the ingress can properly establish a P2MP TE tunnel. Figure 4-51 demonstrates the process for establishing a P2MP TE tunnel.
A P2MP TE tunnel is to be established between the ingress PE1 and leaf nodes PE2 and PE3. This tunnel consists of sub-LSPs over the path PE1 -> P -> PE2 and the path PE1 -> P -> PE3. PE1 constructs a Path message for each leaf PE and sends the messages over an explicit path.A P2MP TE tunnel is to be established between the ingress PE1 and leaf nodes PE2, PE3. This tunnel consists of sub-LSPs over paths PE1 -> P -> PE2, PE1 -> P -> PE3. PE1 constructs a Path message for each leaf PE and sends the messages over an explicit path. After receiving the Path message, every leaf PE replies with a Resv message carrying a label assigned to its upstream node. The MPLS packets share the same incoming label on the branch node, and the branch node builds a P2MP forwarding table. For example, the P is the branch node shown in Figure 4-52. Table 4-16 illustrates how a P2MP TE tunnel is established.Table 4-16 P2MP TE tunnel establishment processNode
Event
Processing
Generated Forwarding Entry
PE2
PE2 receives a Path message sent by the P.
PE2 assigns a label with the value of 21 to the P, constructs a Resv message, and sends this message with the assigned label to the P.
in-label: LE21; action: POP
PE3
PE3 receives a Path message sent by the P.
PE3 assigns a label with the value of 31 to the P, constructs a Resv message, and sends this message with the assigned label to the P.
in-label: LE31; action: POP
P
The P receives a Resv message sent by PE2.
The P reserves bandwidth for the outbound interface3, assigns a label with the value of 11, and replies to PE1 with a Resv message carrying the assigned label.
in-label: LE11; action: SWAP; out-label: LE21
The P receives a Resv message sent by PE3.
The P reserves bandwidth for the outbound interface, assigns a label with the value of 11, and replies to PE1 with a Resv message carrying the assigned label.
in-label: LE11; action: SWAP; out-label: LE31
PE1
PE1 receives a Resv message sent by the P.
PE1 reserves bandwidth for the outbound interface. A tunnel is successfully established.
in-label: none; action: PUSH; out-label: LE11
P2MP TE Data Forwarding
P2MP TE data forwarding is similar to IP multicast data forwarding. A branch node replicates MPLS packets, swaps existing labels with outgoing labels in the MPLS packets, and sends the same MPLS packets over every sub-LSP. This process increases the efficiency of network bandwidth resource usage.
In a VPLS over P2MP scenario or an NG MVPN over P2MP scenario, each service is transmitted exclusively along a P2MP tunnel.
Node |
Forwarding Entry |
Forwarding Behavior |
|
|---|---|---|---|
Incoming Label |
Outgoing Label |
||
PE1 |
N/A |
L11 |
Pushes an outgoing label with the value of 11 into an IP multicast packet and forwards the packet to P1. |
P1 |
L11 |
L21 |
Swaps the incoming label with an outgoing label with the value of 21 in an MPLS packet and forwards the packet to P2. |
P2 (branch node) |
L21 |
LE22 |
Replicates the IP multicast packet, swaps the incoming label with an outgoing label in each packet, and forwards each packet to a next hop through a specific outbound interface. |
LE42 |
|||
PE2 (bud node) |
LE22 |
LE32 |
|
None |
|||
PE3 |
LE32 |
None |
Removes the label from the packet so that this MPLS packet becomes an IP multicast packet. |
PE4 |
LE42 |
None |
Removes the label from the packet so that this MPLS packet becomes an IP multicast packet. |
P2MP TE FRR
The P2P TE bypass tunnel is established over the path P1 -> P5 -> P2 on the network shown in Figure 4-54. It protects traffic over the link between P1 and P2. If the link between P1 and P2 fails, P1 switches traffic to the bypass tunnel destined for P2.
An FRR bypass tunnel must be manually configured. An administrator can configure an explicit path for a bypass tunnel and determine whether to plan bandwidth for the bypass tunnel.
P2P and P2MP TE tunnels can share a bypass tunnel. FRR protection functions for P2P and P2MP TE tunnels are as follows:
A bypass tunnel bandwidth with planned bandwidth can be bound to a specific number of both P2P and P2MP tunnels in configuration sequence. The total bandwidth of the bound P2P and P2MP tunnels must be lower than or equal to the bandwidth of the bypass tunnel.
A bypass tunnel with no bandwidth can also be bound to both P2P and P2MP TE tunnels.
MPLS TE Functions Shared by P2P TE and P2MP TE
Supported Function |
Description |
|---|---|
Enables the ingress to reestablish a CR-LSP over a better path. Tunnel re-optimization is implemented in either of the following modes:
|
|
Authenticates RSVP messages based on RSVP message digests. RSVP authentication helps prevent malicious attacks initiated by the modified or forged RSVP messages and improve the network reliability and security. |
|
Enables nodes to send Srefresh messages that contain Path and Resv message digests, instead of sending complete Path and Resv messages, which helps reduce bandwidth consumption. Srefresh takes effect on both P2P and P2MP TE tunnels established on the same device. |
|
Helps the neighbor complete the GR process. Principles and configuration procedures for RSVP graceful restart (GR) Helper functions for P2MP and P2P TE tunnels are similar. RSVP GR Helper functions take effect on both P2P and P2MP TE tunnels established on the same device. |
