P2MP TE

NE20E-S2 V800R012C00SPC300 Feature Description - MPLS 04

Rate and give feedback:

Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).

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

The proliferation of applications, such as IPTV, multimedia conference, and massively multiplayer online role-playing games (MMORPGs), amplifies demands on multicast transmission over IP/MPLS networks. These services require sufficient network bandwidth, quality of service (QoS) capabilities, and high reliability. The following multicast solutions are used to run multicast services, but these solutions fall short of the requirements of multicast services or network carriers:

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.

IP/MPLS backbone network carriers require a multicast solution that has high TE capabilities and can be implemented by upgrading existing devices.

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

The P2MP TE feature deployed on an IP/MPLS backbone network offers the following 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

Figure 4-49 illustrates a P2MP TE tunnel.

Figure 4-49 P2MP TE tunnel

Table 4-15 lists P2MP TE-related concepts.

Table 4-15 Related Concepts of P2MP TE

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.
Figure 4-50 Re-merge event and crossover event

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.

Figure 4-51 Path establishment 1

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.

Figure 4-52 Path establishment 2

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 process

Node	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
P	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.

A P2MP TE tunnel is established on the network shown in Figure 4-53. P2 is a branch node, and PE2 is a bud node. Table 4-17 demonstrates the process for forwarding multicast packets on each node over the P2MP TE tunnel.

Figure 4-53 P2MP TE data forwarding

Table 4-17 P2MP TE data forwarding

Node	Forwarding Entry		Forwarding Behavior
Node	Incoming Label	Outgoing Label	Forwarding Behavior
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.
P2 (branch node)	L21	LE42
PE2 (bud node)	LE22	LE32	Replicates the packet, removes a label from one packet, and forwards the packet to the CE. Swaps the incoming label with an outgoing label LE32 in the other packet before forwarding this packet to PE3.
PE2 (bud node)	LE22	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

Fast reroute (FRR) can protect P2MP and P2P TE tunnels. The NE20E supports FRR link protection, not node protection, over P2MP TE tunnels. TE FRR establishes a bypass tunnel to protect sub-LSPs. If a link fails, traffic switches to the bypass tunnel within 50 milliseconds.

Figure 4-54 FRR link protection for a P2MP TE tunnel

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

Both a P2P TE tunnel and a P2MP TE tunnel are established using the Resource Reservation Protocol-Tunnel Engineering (RSVP-TE) protocol. Therefore, they both share the following functions shown in Table 4-18.

Table 4-18 MPLS TE functions shared by P2P TE and P2MP TE

Supported Function	Description
Tunnel re-optimization	Enables the ingress to reestablish a CR-LSP over a better path. Tunnel re-optimization is implemented in either of the following modes: Periodic re-optimization When the specified interval for optimizing a CR-LSP expires, Constraint Shortest Path First (CSPF) is triggered to calculate the path of the CR-LSP. If the path calculated by CSPF has a metric smaller than that of the existing CR-LSP, a new CR-LSP is established along the new path. If the CR-LSP is successfully established, the system notifies the forwarding plane to switch traffic and tear down the original CR-LSP. After the process, re-optimization is complete. If the CR-LSP is not set up, the traffic is still forwarded along the existing CR-LSP. Manual re-optimization A re-optimization command is run in the user view to trigger re-optimization.
RSVP authentication	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.
RSVP Summary Refresh (Srefresh)	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.
RSVP GR Helper	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.

Translation

简体中文

Download

Updated: 2020-07-02

Document ID: EDOC1100147100

Downloads: 25

Average rating:

This Document Applies to these Products