MPLS LSP & RSVP

Created: Jan 21, 2020 15:19:20Latest reply: Jan 22, 2020 02:50:32 91 4 0 0
  Rewarded Hi-coins: 0 (problem resolved)

Hello friends,I have few  basic questions related to MPLS & TE , as given below


1)  Can anyone explain difference b/w LSP & CR-LSP in details?

2)   LDP generate LSP & RSVP generate CR-LSP?

3)  LDP & RSVP is alternative protocols? means both are used for label & path making?if yes then whats difference?

4)  when we enable Te(traffic enginnering) command then which protocol used for LSP Creation? if RSVP then its means RSVP is automatically activate with TE?  &   no need of LDP for LSP when TE enable?


Last in MPLS L2VPN we have CR-LSP or LSP?if yes then why?


waiting for Clear & detailed reponse. Not just copy from hedex.



Thanks

  • x
  • convention:

Featured Answers
chenhui
Admin Created Jan 22, 2020 02:50:32 Helpful(0) Helpful(0)

Hi @LSA

1)  Can anyone explain difference b/w LSP & CR-LSP in details?

    Well, you can consider the LSP and CR-LSP the same somehow. CR-LSP is short for constraint-based routed label switched path, it is a LSP with some constraint conditions. A CR-LSP might need matching the bandwidth and delay requirement, while LSP doesn't provide such commitment about the forwarding path. For example, a LSP might suffer the heavy delay when carries the voice traffic, in such situation, the voice qulity will be heaily affected, but the CR-LSP could provide a low latency LSP to match this requirement.


2)   LDP generate LSP & RSVP generate CR-LSP?

Yes, CR-LSP contains static CR-LSP and dynamic CR-LSP. Like LSP, static CR-LSP is configured manually, while dynamic CR-LSP use the RSVP as the signaling protocol.


3)  LDP & RSVP is alternative protocols? means both are used for label & path making?if yes then whats difference?

No, they are two different protocols, and cannot alternate each other. For a normal dynamic LSP, the LDP is the signaling protocol. RSVP is the signaling protocol for dynamic CR-LSP.


4)  when we enable Te(traffic enginnering) command then which protocol used for LSP Creation? if RSVP then its means RSVP is automatically activate with TE?  &   no need of LDP for LSP when TE enable?

RSVP should be enabled when configure MPLS TE to generate the dynamic CR-LSP, and it's not enable automatically, you should configure it manually. It's unnecessary to enable LDP when configuring MPLS TE.

Actually, you can consider the MPLS + LDP as a combination, and MPLS TE + RSVP as a combination. When confiugring the traditional MPLS tunnel, choosing MPLS + LDP, when configuring MPLS TE, choosing MPLS TE + RSVP.



Last in MPLS L2VPN we have CR-LSP or LSP?if yes then why?

In MPLS L2VPN, the signaling protocol is LSP. 

By the way, there are no strict boundaries, cause MPLS tunnel could carry MPLS packet too. So, theoretically, it's possible to encapsulate the MPLS packets in MPLS tunnel for multiple times. As in the MPLS L3VPN option C, the packets could carry as much as three MPLS lables, it seems like MPLS over MPLS.

  • x
  • convention:

All Answers
lubna
lubna Created Jan 21, 2020 16:36:32 Helpful(0) Helpful(0)

Q3 answer
LDP vs RSVP
I want to share some brief notes about two protocols used for setting up the LSP in MPLS enabled core networks: LDP and RSVP. Both protocols have some important differences that should be understood to dig deeper into protection and restoration mechanisms as well as DiffServ-aware TE.

LDP vs RSVP



There are three protocols commonly used for the distribution of label bindings in MPLS networks:



LDP
RSVP
BGP (not covered here)


Exists multiple extensions to IGPs that enable that protocols to distribute labels as an addition to perform classical routing functions on the network. That extensions are not commonly used in real deployments, so are not going to be covered here.





LDP



Of the three, LDP is the youngest one. Was created explicitly to distribute labels and it’s not an extension or added functionality to a relatively old protocol like in the RSVP or BGP case.



LDP is designed to be highly extensible, using TLV triplets to be able to transport multiple additional fields in the future and warrantee the compatibility with previous versions via ignoring the unknown new fields.



LDP is highly flexible, as supports local and remote neighbors (using targeted LDP sessions). This flexibility allows an LSR to exchange label information with local and remote peers which enables it to support the engineering of multiple services and functionalities like LDP session protection.



LDP is a reliable protocol, because it uses TCP as transport. Only the neighbor discovery and maintenance is performed using UDP. The incremental updates functionality is a point in favor of its scalability.



If LDP is so reliable, extensible, functional and scalable, why do we even think about using an alternative to it in the MPLS core to do the job of setting up the labeled switched paths? Well, it follows the leader blindly and that may, under some circumstances, be a problem like may be in real life.



LDP follows the IGP in the decisions the later takes. The price to pay for that decision is loss of stability of the LSPs that LDP set up.



Instability: if the IGP changes, the LDP will change with it, but late. LDP could set up instable LSPs in the network.
Convergence: the convergence events that happens on every network are inherited by LDP and that could lead to data loss or looping conditions. The convergence time of the IGP will set a lower convergence time limit to LDP and to the LSPs (not considering LDP FRR capabilities yet).
Race conditions: race conditions may always appear when two protocols interact in an unsynchronized way, and that may leads to data loss.




RSVP



Please, I need you to complete this section with a similar approach so that we can compare yours with mine.



Originally, the RSVP protocol was developed to support the IntServ QoS model resource reservations for each flow that demands specific QoS requirements as it traverses the network. Original RSVP does not scale very well because the number of end to end sessions that the intermediate devices must support may grow very fast in the SP core as more flows require QoS reservations, and that affects the control plane state that devices must support.

RSVP was extended to support the creation and maintenance of LSPs, as well to being able to make bandwidth reservations for the signaled LSPs. The extension performs scalability by aggregation, but… of what? It aggregates multiple flows of data into one LSP in a way that 1 RSVP session set up 1 LSP that can transport multiple flows of data. As the amount of state on each node of the network is proportional to the number of LSPs traversing the node, aggregation alleviates (that does not solve) the problem of scalability.

The path reservation is initiated by the ingress LSR using Path and Resv messages. The Path message travels from ingress LSR (head-end) to egress LSR (tail-end) and the Resv in the opposite direction.

RSVP Path
Label request
ERO (Explicit Route Object, explicit route)
RRO (Recorded Route Object, loop avoidance)
Tspec (Bandwidth Reservation, QoS requirements)
RSVP Resv
Label object (Assigned Label)
RRO (Loop avoidance)


The LSP reservation need to be refreshed periodically via Path and Resv messages from the head-end to the tail-end. The Summary Refresh Extensions of RSVP allows the refresh of multiple LSPs at once in a way that the number of signaling messages for refreshing LSPs that share the same path may be reduced.

There is no concept of ECMP in RSVP once the traffic in tunneled over the core in the tunneled LSP. In case the applications or business requirements mandate for the need of multiple different paths, the ingress LSR or head-end should ask for multiple reservations and split the traffic over the two (or more) LSPs. Of course, the ingress LSR may ask for as many reservation as it needs for the applications, but at the cost of more state in the control plane of all the devices the LSP crosses.

Finally, for good or not, RSVP does not follow the IGP, and that allows the head-end to take independent decisions about the traffic flows it reserves.
  • x
  • convention:

i%20am%20student%20%20and%20i%20am%20doing%20BSIT%20from%20international%20Islamic%20university%20in%20islamabad
lubna
lubna Created Jan 21, 2020 16:48:56 Helpful(0) Helpful(0)

Q4 answer
3.3. MPLS
Multiprotocol Label Switching (MPLS) is a label switching technology that provides the ability to set up connection-oriented paths over a connectionless IP network. MPLS facilitates network traffic flow and provides a mechanism to engineer network traffic patterns independently from routing tables. MPLS sets up a specific path for a sequence of packets. The packets are identified by a label inserted into each packet.

MPLS is independent of any routing protocol but is considered multiprotocol because it works with protocols such as IP, ATM, Ethernet, and circuit emulation.

This section contains the following topics:

Traffic Engineering for MPLS
MPLS Label Stack
Label Edge and Label Switch Routers
LSP Types
3.3.1. Traffic Engineering for MPLS
Without traffic engineering (TE), routers route traffic according to the Shortest Path First (SPF) algorithm, disregarding congestion or packet types.

With traffic engineering, network traffic is routed efficiently to maximize throughput and minimize delay. Traffic engineering facilitates traffic flows to be mapped to the destination through a less-congested path than the one selected by the SPF algorithm.

MPLS directs a flow of IP packets along a label switched path (LSP). LSPs are simplex, meaning that the traffic flows in one direction (unidirectional) from an ingress router to an egress router. Two LSPs are required for duplex (bidirectional) traffic. Each LSP carries traffic in a specific direction, forwarding packets from one router to the next across the MPLS domain.

When an ingress router receives a packet, it adds an MPLS header to the packet and forwards it to the next hop in the LSP. The labeled packet is forwarded along the LSP path (from next hop to next hop) until it reaches the destination point. The MPLS header is removed and the packet is forwarded based on Layer 3 information such as the IP destination address. The physical path of the LSP is not constrained to the shortest path that the IGP would choose using SPF to reach the destination IP address.

3.3.1.1. TE Metric and IGP Metric
When the TE metric is selected for an LSP, the shortest path computation will select an LSP path based on the TE metric constraints instead of the IGP metric (for OSPF and IS-IS), which is the default metric. The user configures the TE metric under the router>mpls> interface context and the IGP metric under the router>ospf>area> interface context (for OSPF) and the router>isis>if>level context (for IS-IS). Both the TE and IGP metrics are advertised by OSPF and IS-IS for each link in the network.

The TE metric is part of the traffic engineering extensions of the IGP protocols. For more information on the OSPF and IS-IS routing protocols, refer to the 7705 SAR OS Routing Protocols Guide.

Typically, the TE metric is used to allow Constrained Shortest Path First (CSPF) to represent a dual TE topology for the purpose of computing LSP paths, where one TE topology is based on the RSVP-TE database and the other is based on the IGP-TE database.

An LSP dedicated to real-time and delay-sensitive user and control traffic has its path computed by CSPF using the TE metric. The user configures the TE metric to represent the amount of delay, or combined delay and jitter, of the link. In this case, the shortest path satisfying the constraints of the LSP path will effectively represent the shortest-delay path.

An LSP dedicated to non-delay-sensitive user and control traffic has its path computed by CSPF using the IGP metric. The IGP metric could represent the link bandwidth or some other value as required.

When the use of the TE metric is enabled for an LSP, the CSPF process will first eliminate all links in the network topology that do not meet the constraints specified for the LSP path; the constraints include bandwidth, admin-groups, and hop limit. CSPF will then run the SPF algorithm on the remaining links. The shortest path among all the SPF paths will be selected based on the TE metric instead of the IGP metric. The TE metric is only used in CSPF computations for MPLS paths and not in the regular SPF computation for IP reachability.

Operational metrics of LSPs that use the TE metric in CSPF path calculations can be overridden with the user-configured administrative LSP metric.

3.3.2. MPLS Label Stack
Routers that support MPLS are known as Label Edge Routers (LERs) and Label Switch Routers (LSRs). MPLS requires a set of procedures to enhance network layer packets with label stacks, which turns them into labeled packets. In order to initiate, transmit, or terminate a labeled packet on a particular data link, an LER or LSR must support the encoding technique which, when given a label stack and a network layer packet, produces a labeled packet.

In MPLS, packets can carry not just one label, but a set of labels in a stack. An LSR can swap the label at the top of the stack, pop the stack (that is, remove the top label), or swap the label and push one or more labels onto the stack. The processing of a labeled packet is completely independent of the level of hierarchy. The processing is always based on the top label, without regard for the possibility that other labels may have been above it in the past or that other labels may be below it at present.

As described in RFC 3032, MPLS Label Stack Encoding, the label stack is represented as a sequence of “label stack entries”. Each label stack entry is represented by 4 octets. Figure 1 shows the structure of a label and Table 2 describes the fields. Figure 2 shows the label placement in a packet.

Figure 1: Label Structure

Table 2: Packet/Label Field Description
Field

Description

Label

This 20-bit field carries the actual value (unstructured) of the label.

Exp

This 3-bit field is reserved for experimental use. It is currently used for Class of Service (CoS).

S

This bit is set to 1 for the last entry (bottom) in the label stack and 0 for all other label stack entries.

TTL

This 8-bit field is used to encode a time-to-live value.

A stack can carry several labels, organized in a last in/first out order. The top of the label stack appears first in the packet and the bottom of the stack appears last (Figure 2).

Figure 2: Label Packet Placement

The label value at the top of the stack is looked up when a labeled packet is received. A successful lookup reveals:

the next hop where the packet is to be forwarded
the operation to be performed on the label stack before forwarding
In addition, the lookup may reveal outgoing data link encapsulation and other information needed to properly forward the packet.

An empty label stack can be thought of as an unlabeled packet. An empty label stack has zero (0) depth. The label at the bottom of the stack is referred to as the Level 1 label. The label above it (if it exists) is the Level 2 label, and so on. The label at the top of the stack is referred to as the Level m label.

3.3.2.1. Label Values
The 7705 SAR uses RSVP-TE and LDP protocols for label forwarding, For packet-based services such as VLL, the 7705 SAR uses T-LDP for signaling PW labels between peer nodes.

Packets traveling along an LSP are identified by the packet label, which is the 20-bit, unsigned integer (see Label Edge and Label Switch Routers). The range is 0 through 1 048 575. Label values 0 to 15 are reserved and are defined below:

A value of 0 represents the IPv4 Explicit NULL label. This label value is legal only at the bottom of the label stack if the label stack is immediately followed by an IPv4 header, in which case the packet forwarding is based on the IPv4 header. If the IPv4 Explicit NULL label is not at the bottom of the label stack, then the packet forwarding is based on the subsequent label.
A value of 1 represents the router alert label. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual packet forwarding is determined by the label beneath it in the stack. However, if the packet is further forwarded, the router alert label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the router alert option in IP packets. Since this label cannot be at the bottom of the stack, it is not associated with a particular network layer protocol.
A value of 3 represents the Implicit NULL label. An LER advertises this when it is requesting penultimate hop popping and expecting unlabeled packets. Thus, the label value 3 should never appear in the label stack.
Values 4 through 15 are reserved for future use.
Table 3 lists the label ranges available for use by ingress labels (pop labels).

Table 3: Ingress Label Values (Pop Labels)
Label Values

Description

16 through 31

Reserved for future use

32 through 1023

Available for static outer LSP tunnel label assignment

1024 through 2047

Reserved for future use

2048 through 18 431

Statically assigned for services (inner pseudowire label)

32 768 through 131 071

Dynamically assigned for both MPLS and services

131 072 through 1 048 575

Reserved for future use

Table 4 lists the label ranges available for use by egress labels (push labels).

Table 4: Egress Label Values (Push Labels)
Label Values

Description

16 through 1 048 575

Can be used for static LSP tunnel and static PW labels

16 through 1 048 575

Can be dynamically assigned for both MPLS tunnel labels and PW labels

3.3.3. Label Edge and Label Switch Routers
A 7705 SAR performs different functions based on its position in an LSP—ingress, egress, or transit—as described in the following list:

ingress Label Edge Router (iLER) — The router at the beginning of an LSP is the iLER. The ingress router encapsulates packets with an MPLS header and forwards the packets to the next router along the path. An LSP can only have one ingress router.
Label Switching Router (LSR) — An LSR can be any intermediate router in the LSP between the ingress and egress routers, swapping the incoming label with the outgoing MPLS label and forwarding the MPLS packets it receives to the next router in the LSP. An LSP can have 0 to 253 transit routers.
egress Label Edge Router (eLER) — The router at the end of an LSP is the eLER. The egress router strips the MPLS encapsulation, which changes it from an MPLS packet to a data packet, and then forwards the packet to its final destination using information in the forwarding table. An LSP can have only one egress router. The ingress and egress routers in an LSP cannot be the same router.
A router in a network can act as an ingress, egress, or transit router for one or more LSPs, depending on the network design.

Constrained-path LSPs are signaled and are confined to one Interior Gateway Protocol (IGP) area. These LSPs cannot cross an autonomous system (AS) boundary.

Static LSPs can cross AS boundaries. The intermediate hops are manually configured so that the LSP has no dependence on the IGP topology or a local forwarding table.

3.3.4. LSP Types
The following LSP types are supported:

static LSPs — a static LSP specifies a static path. All routers that the LSP traverses must be configured manually with labels. No RSVP-TE or LDP signaling is required. Static LSPs are discussed in this chapter.
signaled LSPs — LSPs are set up using the RSVP-TE or LDP signaling protocol. The signaling protocol allows labels to be assigned from an ingress router to the egress router. Signaling is triggered by the ingress routers. Configuration is required only on the ingress router and is not required on intermediate routers. Signaling also facilitates path selection. RSVP-TE is discussed in this chapter, and LDP is discussed in Label Distribution Protocol.
There are two types of signaled LSP:
explicit-path LSPs — MPLS uses RSVP-TE to set up explicit-path LSPs. The hops within the LSP are configured manually. The intermediate hops must be configured as either strict or loose, meaning that the LSP must take either a direct path from the previous hop router to this router (strict) or can traverse other routers (loose). Thus, you can control how the path is set up. Explicit-path LSPs are similar to static LSPs but require less configuration. See RSVP and RSVP-TE. An explicit path that has not specified any hops will follow the IGP route.
constrained-path LSPs — for constrained-path LSPs, the intermediate hops of the LSP are dynamically assigned. A constrained-path LSP relies on the Constrained Shortest Path First (CSPF) routing algorithm to find a path that satisfies the constraints for the LSP. In turn, CSPF relies on the topology database provided by an extended IGP such as OSPF or IS-IS.
Once the path is found by CSPF, RSVP-TE uses the path to request the LSP setup. CSPF calculates the shortest path based on the constraints provided, such as bandwidth, class of service, and specified hops.
If Fast Reroute (FRR) is configured, the ingress router signals the downstream routers so that each downstream router can preconfigure a detour route for the LSP that will be used if there is a failure on the original LSP. If a downstream router does not support FRR, the request is ignored and the router continues to support the original LSP. This can cause some of the detour routes to fail, but the original LSP is not impacted. For more information on FRR, see RSVP-TE Fast Reroute (FRR).

No bandwidth is reserved for the reroute path. If the user enters a value in the bandwidth parameter in the config>router>mpls>lsp>fast-reroute context, it will have no effect on establishing the backup LSP. The following warning message is displayed:

“The fast reroute bandwidth command is not supported in this release.”

3.4. RSVP and RSVP-TE
The Resource Reservation Protocol (RSVP) is a network control protocol used by a host to request specific qualities of service from the network for particular application data streams or flows. RSVP is also used by routers to deliver quality of service (QoS) requests to all nodes along the paths of the flows and to establish and maintain operational state to provide the requested service. In general, RSVP requests result in resources reserved in each node along the data path.

The Resource Reservation Protocol for Traffic Engineering (RSVP-TE) is an extended version of RSVP for MPLS. RSVP-TE uses traffic engineering extensions to support automatic signaling of LSPs. MPLS uses RSVP-TE to set up traffic-engineered LSPs. See RSVP-TE Extensions for MPLS for more information.

3.4.1. RSVP-TE Overview
RSVP-TE requests resources for simplex (unidirectional) flows. Therefore, RSVP-TE treats a sender as logically distinct from a receiver, although the same application process may act as both a sender and a receiver at the same time. Duplex flows require two LSPs, to carry traffic in each direction.

RSVP-TE is a signaling protocol, not a routing protocol. RSVP-TE operates with unicast and multicast routing protocols. Routing protocols determine where packets are forwarded. RSVP-TE consults local routing tables to relay RSVP-TE messages.

RSVP-TE uses two message types to set up LSPs, PATH and RESV. Figure 3 depicts the process to establish an LSP.

The sender (the ingress LER (iLER)) sends PATH messages toward the receiver, (the egress LER (eLER)) to indicate the forwarding equivalence class (FEC) for which label bindings are desired. PATH messages are used to signal and request the label bindings required to establish the LSP from ingress to egress. Each router along the path observes the traffic type.
PATH messages facilitate the routers along the path to make the necessary bandwidth reservations and distribute the label binding to the router upstream.
The eLER sends label binding information in the RESV messages in response to PATH messages received.
The LSP is considered operational when the iLER receives the label binding information.
Figure 3: Establishing LSPs

Figure 4 displays an example of an LSP path set up using RSVP-TE. The ingress label edge router (iLER 1) transmits an RSVP-TE PATH message (path: 30.30.30.1) downstream to the egress label edge router (eLER 4). The PATH message contains a label request object that requests intermediate LSRs and the eLER to provide a label binding for this path.

Figure 4: LSP Using RSVP-TE Path Setup

In addition to the label request object, an RSVP-TE PATH message can also contain a number of optional objects:

explicit route object (ERO) — when the ERO is present, the RSVP-TE PATH message is forced to follow the path specified by the ERO (independent of the IGP shortest path)
record route object (RRO) — allows the iLER to receive a listing of the LSRs that the LSP tunnel actually traverses
session attribute object — controls the path setup priority, holding priority, and local rerouting features
Upon receiving a PATH message containing a label request object, the eLER transmits an RESV message that contains a label object. The label object contains the label binding that the downstream LSR communicates to its upstream neighbor. The RESV message is sent upstream towards the iLER, in a direction opposite to that followed by the PATH message. Each LSR that processes the RESV message carrying a label object uses the received label for outgoing traffic associated with the specific LSP. When the RESV message arrives at the ingress LSR, the LSP is established.

3.4.1.1. Using RSVP-TE for MPLS
Hosts and routers that support both MPLS and RSVP-TE can associate labels with RSVP-TE flows. When MPLS and RSVP-TE are combined, the definition of a flow can be made more flexible. Once an LSP is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a variety of criteria. The set of packets that are assigned the same label value by a specific node are considered to belong to the same Forwarding Equivalence Class (FEC) that defines the RSVP-TE flow.

For use with MPLS, RSVP-TE already has the resource reservation component built in, making it ideal to reserve resources for LSPs.

3.4.1.2. RSVP-TE Extensions for MPLS
The RSVP-TE extensions enable MPLS to support the creation of explicitly routed LSPs, with or without resource reservation. Several of the features enabled by these extensions were implemented to meet the requirements for traffic engineering over MPLS, which enables the creation of traffic trunks with specific characteristics. None of the TE extensions result in backward compatibility problems with traditional RSVP implementations.

To run properly, the traffic engineering capabilities of RSVP-TE require an underlying TE-enabled IGP routing protocol. The 7705 SAR supports OSPF and IS-IS with TE extensions.

Routing protocols make it possible to advertise the constraints imposed over various links in the network. For example, in order for the nodes in a network to choose the best link for signaling a tunnel, the capacity of a particular link and the amount of reservable capacity must be advertised by the IGP. RSVP-TE makes use of these constraints to request the setup of a path or LSP that traverses only those links that are part of an administrative group (admin groups are described in the following list). Thus, both RSVP-TE and the IGP-TE (that is, OSPF-TE or IS-IS-TE for the 7705 SAR) must be enabled and running simultaneously.

The following TE capabilities are supported:

hop limit — the hop limit is the maximum number of LSRs that a given LSP can traverse, including the ingress and the egress LERs. Typically, the hop limit is used to control the maximum delay time for mission-critical traffic such as voice traffic.
The hop limit applies to the primary LSP, any backup LSPs, and LSPs configured to be used in Fast Reroute (FRR) situations.
admin groups — administrative groups provide a way to define which LSR nodes should be included or excluded while signaling an LSP. For example, it might be desirable to avoid some nodes or links that are known to be used heavily from being included in the path of an LSP, or to include a specific LSR node to ensure that a newly signaled RSVP-TE tunnel traverses that LSR node.
Administrative groups apply to both primary and secondary LSPs. They are defined under the config>router>if-attribute context, and are applied at the MPLS interface level, as well as at the LSP and the primary and secondary LSP levels through include and exclude commands.
bandwidth — the bandwidth capability (supported by RSVP-TE), is similar to the Connection Admission Control (CAC) function in ATM. During the establishment phase of RSVP-TE, the LSP PATH message contains the bandwidth reservation request. If the requested capacity is available, the RESV message confirms the reservation request. The amount of reserved bandwidth stated in the request is deducted from the amount of reservable bandwidth for each link over which the LSP traverses.
The bandwidth capability applies to both primary and secondary LSPs, and LSPs configured to be used in Fast Reroute (FRR) situations.
3.4.1.3. Hello Protocol
The Hello protocol detects the loss of a neighbor node (node failure detection) or the reset of a neighbor’s RSVP-TE state information. In standard RSVP, neighbor monitoring occurs as part of the RSVP soft-state model. The reservation state is maintained as cached information that is first installed and then periodically refreshed by the ingress and egress LERs. If the state is not refreshed within a specified time interval, the LSR discards the state because it assumes that either the neighbor node has been lost or its RSVP-TE state information has been reset.

The Hello protocol extension is composed of a Hello message, a Hello request object and a Hello ACK object. Hello processing between two neighbors supports independent selection of failure detection intervals. Each neighbor can automatically issue Hello request objects. Each Hello request object is answered by a Hello ACK object.

3.4.1.4. MD5 Authentication of RSVP-TE Interface
When enabled on an RSVP-TE interface, authentication of RSVP messages operates in both directions of the interface. A node maintains a security association with its neighbors for each authentication key. The following items are stored in the context of this security association:

the HMAC-MD5 authentication algorithm
the key used with the authentication algorithm
the lifetime of the key. A key is a user-generated key using third-party software or hardware. The value is entered as a static string into the CLI configuration of the RSVP interface. The key will continue to be valid until it is removed from that RSVP interface.
the source address of the sending system
the latest sending sequence number used with this key identifier
The RSVP sender transmits an authenticating digest of the RSVP message, computed using the shared authentication key and a keyed hash algorithm. The message digest is included in an Integrity object that also contains a Flags field, a Key Identifier field, and a Sequence Number field. The RSVP sender complies with the procedures for RSVP message generation in RFC 2747, RSVP Cryptographic Authentication.

An RSVP receiver uses the key together with the authentication algorithm to process received RSVP messages.

If a point of local repair (PLR) node switches the path of the LSP to a bypass LSP, it does not send the integrity object in the RSVP messages over the bypass tunnel. If an integrity object is received from the merge point (MP) node, then the message is discarded since there is no security association with the next-next-hop MP node.

The 7705 SAR MD5 implementation does not support the authentication challenge procedures in RFC 2747.

3.4.1.5. Non-Router ID Addresses as Destinations and Hops
The address of a configured loopback interface, other than the router ID, can be used as the destination of an RSVP LSP. For a constrained-path LSP, CSPF searches for the best path that matches the constraints across all areas or levels of the IGP where this address is reachable. If the address is the router ID of the destination node, then CSPF selects the best path across all areas or levels of the IGP for that router ID, regardless of which area or level the router ID is reachable for as an interface.

The address of a loopback interface other than the router ID can also be configured as a hop in the LSP path hop definition. If the hop is “strict” and corresponds to the router ID of the node, the CSPF path may use any TE-enabled link to the downstream node based on best cost. If the hop is “strict” and does not correspond to the router ID of the node, then CSPF will fail.

3.5. RSVP-TE Signaling
RSVP-TE-based signaling provides a means to establish tunnels dynamically.

RSVP-TE uses the Downstream on Demand (DOD) label distribution mode, sending PATH messages from the ingress LER node to the egress LER, and RESV messages in the reverse direction. DOD label distribution is a router’s response to an explicit request from another router for label binding information. The DOD mode is in contrast to LDP on the 7705 SAR, which uses the Downstream Unsolicited (DU) label distribution mode for both PWs and LSPs. A router in DU mode will distribute label bindings to another router that has not explicitly requested the label bindings.

RSVP-TE signaling is supported when the 7705 SAR is deployed as an LER and as an LSR. When used as an LER, the 7705 SAR uses RSVP-TE signaling to set up constrained paths because only the LER knows all the constraints imposed on the LSP. When used as an LSR, the 7705 SAR uses RSVP-TE to interpret the RSVP-TE messages (including all the constraints).

With RSVP-TE, users can choose which services and PWs may use a particular LSP. One-to-one or many-to-one scenarios for binding PWs to RSVP-TE LSPs is supported, which is similar to binding PWs to static LSPs. Furthermore, each RSVP-TE LSP can be configured with its own set of attributes and constraints.

3.5.1. General Attributes of RSVP-TE
The following general attributes of RSVP-TE on the 7705 SAR are supported:

Authentication
OAM: BFD
Timers
LSP Resignal Limit
RSVP-TE Message Pacing
RSVP-TE Overhead Refresh Reduction
RSVP-TE Reservation Styles
3.5.1.1. Authentication
In order to ensure the integrity of a peer router, authentication for RSVP-TE is supported. It can be enabled on a per-link basis and is bidirectional. Hence both of the nodes must either enable authentication or disable it on a per-peer or per-link basis. The MD5-based authentication algorithm is implemented and sequence numbers are used to keep track of messages.

3.5.1.2. OAM: BFD
Bidirectional Forwarding Detection (BFD) is supported on the 7705 SAR. In the case of BFD for RSVP-TE, an RSVP-TE enabled link is registered with the BFD state machine, and if a failure occurs the RSVP-TE interface is taken out of service. The BFD implementation on the 7705 SAR works on a hop-by-hop basis, and if BFD detects a link failure, only the two directly connected MPLS nodes are aware of that failure. If the node that detects the link failure is an LSR node, it generates PATH-ERR messages to the originators (the LER nodes) of the failing LSPs. If FRR is configured, the detecting node takes corrective action itself. See LSP Redundancy and RSVP-TE Fast Reroute (FRR) for more information on these topics.

3.5.1.3. Timers
The following timers are implemented to ensure the successful operation of RSVP-TE:

hold-timer — the hold timer defines the amount of time before an LSP is brought up and is in service, which provides protection against unreliable nodes and links
resignal-timer — the resignal timer is used in conjunction with the route optimization process, especially after a reroute has occurred. If the newly computed path for an LSP has a better metric than the currently recorded hop list, then an attempt is made to resignal that LSP, and if the attempt is successful, then a make-before-break switchover occurs. If the attempt to resignal an LSP fails, the LSP continues to use the existing path and another resignal attempt is made the next time the timer expires.
When the resignal timer expires, a trap and syslog message are generated.
retry-timer — the retry timer defines a period of time before a resignal attempt is made after an LSP failure. This delay time protects network resources against excessive signaling overhead.
3.5.1.4. LSP Resignal Limit
When an LSP fails, an LER node tries to resignal it. The following limit can be configured:

retry-limit — the retry limit defines the number of resignaling attempts in order to conserve the resources of the nodes in the network. There could be a serious loss of capacity due to a link failure where an infinite number of retries generate unnecessary message overhead.
3.5.1.5. RSVP-TE Message Pacing
RSVP-TE message pacing provides a means to limit the overwhelming number of RSVP-TE signaling messages that can occur in large MPLS networks during node failures. RSVP-TE message pacing allows the messages to be sent in timed intervals.

To protect nodes from receiving too many messages, the following message pacing parameters can be configured:

msg-pacing — message pacing can be enabled or disabled
max-burst — maximum burst defines the number of RSVP-TE messages that can be sent in the specified period of time
period — period defines the interval of time used in conjunction with the max-burst parameter to send message pacing RSVP-TE messages
Message pacing needs to be enabled on all the nodes in a network to ensure the efficient operation of tier-1 nodes. Message pacing affects the number of RSVP-TE messages that a particular node can generate, not the number of messages it can receive. Thus, each node must be paced at a rate that allows the most loaded MPLS nodes to keep up with the number of messages they receive.

Note:
Typically, a tier-1 node is an aggregator of tier-2 node transmissions, which is an aggregator of tier-3 node transmissions. Tier-1 nodes are often installed at an MTSO, while tier-3 nodes are often installed at cell sites.

3.5.1.6. RSVP-TE Overhead Refresh Reduction
RFC 2961, RSVP Refresh Overhead Reduction Extensions, defines enhancements to the RSVP-TE signaling protocol that reduce refresh overhead, which are in addition to the message pacing function.

These extensions are:

RSVP-TE message bundling — RSVP-TE message bundling reduces the total number of RSVP-TE messages by aggregating the status information of multiple LSPs into a single RSVP-TE PDU. The 7705 SAR supports the receipt and processing of bundled RSVP-TE messages but not the transmission of bundled messages as specified in RFC 2961, section 3.3.
reliable message delivery — reliable message delivery extends RSVP-TE to support MESSAGE_ACK. Each RSVP-TE PDU has a unique message-id for sequence tracking purposes. When an RSVP-TE message arrives, the recipient acknowledges the reception of the specific message-id (this is similar to TCP ACK messages). Lost PDUs can be detected and re-sent with this method, which helps reduce the refresh rate because there are two endpoints tracking the received/lost messages.
summary refresh — the summary refresh capability uses a single message-id list to replace many individual refresh messages and sends negative ACKs (NACKs) for any message-id that cannot be matched (verified). The summary refresh capability reduces the number of message exchanges and message processing between peers. It does not reduce the amount of soft state stored in the node. The term soft state refers to the control state in hosts and routers that will expire if not refreshed within a specified amount of time (see RFC 2205 for information on soft state).
These capabilities can be enabled on a per-RSVP-TE interface basis and are referred to collectively as “refresh overhead reduction extensions”. When refresh-reduction is enabled on a 7705 SAR RSVP-TE interface, the node indicates this to its peer by setting a refresh-reduction-capable bit in the flags field of the common RSVP-TE header. If both peers of an RSVP-TE interface set this bit, all three of the capabilities listed above can be used. The node monitors the setting of this bit in received RSVP-TE messages from the peer on the interface. If the bit is cleared, the node stops sending summary refresh messages. If a peer did not set the refresh-reduction-capable bit, a 7705 SAR node does not attempt to send summary refresh messages.

Also, reliable delivery of RSVP-TE messages over the RSVP-TE interface can be enabled using the reliable-delivery option.

3.5.1.7. RSVP-TE Reservation Styles
LSPs can be signaled with explicit reservation styles for the reservation of resources, such as bandwidth. A reservation style describes a set of attributes for a reservation, including the sharing attributes and sender selection attributes. The style information is part of the LSP configuration. The 7705 SAR supports two reservation styles:

fixed filter (FF) — the fixed filter (FF) reservation style specifies an explicit list of senders and a distinct reservation for each of them. Each sender has a dedicated reservation that is not shared with other senders. Each sender is identified by an IP address and a local identification number, the LSP ID. Because each sender has its own reservation, a unique label and a separate LSP can be constructed for each sender-receiver pair. For traditional RSVP applications, the FF reservation style is ideal for a video distribution application in which each channel (or source) requires a separate pipe for each of the individual video streams.
shared explicit (SE) — the shared explicit (SE) reservation style creates a single reservation over a link that is shared by an explicit list of senders. Because each sender is explicitly listed in the RESV message, different labels can be assigned to different sender-receiver pairs, thereby creating separate LSPs.
If the FRR option is enabled for the LSP and the facility FRR method is selected at the head-end node, only the SE reservation style is allowed. Furthermore, if a 7705 SAR PLR node receives a PATH message with fast reroute requested with facility method and the FF reservation style, it will reject the reservation. The one-to-one backup method supports both FF and SE styles.

3.6. LSP Redundancy
Each primary LSP can be protected by up to two secondary LSPs. When the LER detects a primary LSP failure, it signals its secondary LSPs, if any have been configured, and automatically switches to the first one that is available. LSP redundancy supports shared risk link groups (SRLG). See Shared Risk Link Groups for more information on SRLG.

LSP redundancy differs from the Fast Reroute (FRR) feature in that LSP redundancy is controlled by the LER that initiated the LSP, whereas FRR uses the node that detects the failure to take recovery action. This means that LSP redundancy takes longer to reroute traffic than FRR because failure messages need to traverse multiple hops to reach the LER and activate LSP redundancy, whereas an FRR-configured node responds immediately to bypass the failed node or link. See RSVP-TE Fast Reroute (FRR) for more information on FRR.

The following parameters can be configured for primary and secondary LSPs:

bandwidth — the amount of bandwidth needed for the secondary LSP can be reserved and can be any value; it does not need to be identical to the value reserved by the primary LSP. Bandwidth reservation can be set to 0, which is equivalent to reserving no bandwidth.
inclusion and exclusion of nodes — by including or excluding certain nodes, you can ensure that the primary and secondary LSPs do not traverse the same nodes and therefore ensure successful recovery. Each secondary LSP can have its own list of included and excluded nodes.
hop limit — the hop limit is the maximum number of LSRs that a secondary LSP can traverse, including the ingress and egress LERs.
standby (secondary LSPs only) — when a secondary LSP is configured for standby mode, it is signaled immediately and is ready to take over traffic the moment the LER learns of a primary LSP failure. This mode is also called hot-standby mode.
When a secondary LSP is not in standby mode, then it is only signaled when the primary LSP fails. If there is more than one secondary LSP, they are all signaled at the same time (upon detection of a primary LSP failure) and the first one to come up is used.
3.6.1. Make-Before-Break (MBB) Procedures for LSP and Path Parameter Configuration Changes
The Make-Before-Break (MBB) procedure allows an LSP to switch from an existing working path to a new path without interrupting service. The MBB procedure does this by first signaling the new path when it is operationally up, having the ingress LER move the traffic to the new path, and then allowing the ingress LER to tear down the original path.

The MBB procedure is invoked during the following operations:

timer-based and manual resignal of an LSP path
Fast Reroute (FRR) global revertive procedures
Traffic Engineering (TE) graceful shutdown procedures
update of the secondary path due to an update to the primary path SRLG
LSP primary or secondary path name change
LSP or path configuration parameter change
MBB procedure coverage has been extended to most of the other LSP-level and path-level parameters as follows:

including or excluding admin groups at the LSP and path levels
enabling or disabling the LSP-level CSPF option
enabling or disabling LSP-level use-te-metric parameters when the CSPF option is enabled
enabling or disabling the LSP-level hop-limit option in the fast-reroute context
enabling the LSP-level least-fill option
enabling or disabling the LSP-level adspec option
changing between node-protect and no node-protect (link-protect) values in the LSP-level fast-reroute option
changing the LSP-level and path-level hop-limit parameter values
enabling or disabling primary or secondary path record or record-label options
The MBB procedure is not supported on a manual bypass LSP.
  • x
  • convention:

i%20am%20student%20%20and%20i%20am%20doing%20BSIT%20from%20international%20Islamic%20university%20in%20islamabad
lubna
lubna Created Jan 21, 2020 16:57:49 Helpful(0) Helpful(0)

Q1
LSP vs LDP
Each LSP is assigned a label. When there are multiple LSPs, multiple labels need to be allocated on the same link. The label resources are used more and the label forwarding table has a large maintenance workload. LDP nodes can share labels with different LSPs, and save label resources compare to RSVP.
  • x
  • convention:

i%20am%20student%20%20and%20i%20am%20doing%20BSIT%20from%20international%20Islamic%20university%20in%20islamabad
chenhui
chenhui Admin Created Jan 22, 2020 02:50:32 Helpful(0) Helpful(0)

Hi @LSA

1)  Can anyone explain difference b/w LSP & CR-LSP in details?

    Well, you can consider the LSP and CR-LSP the same somehow. CR-LSP is short for constraint-based routed label switched path, it is a LSP with some constraint conditions. A CR-LSP might need matching the bandwidth and delay requirement, while LSP doesn't provide such commitment about the forwarding path. For example, a LSP might suffer the heavy delay when carries the voice traffic, in such situation, the voice qulity will be heaily affected, but the CR-LSP could provide a low latency LSP to match this requirement.


2)   LDP generate LSP & RSVP generate CR-LSP?

Yes, CR-LSP contains static CR-LSP and dynamic CR-LSP. Like LSP, static CR-LSP is configured manually, while dynamic CR-LSP use the RSVP as the signaling protocol.


3)  LDP & RSVP is alternative protocols? means both are used for label & path making?if yes then whats difference?

No, they are two different protocols, and cannot alternate each other. For a normal dynamic LSP, the LDP is the signaling protocol. RSVP is the signaling protocol for dynamic CR-LSP.


4)  when we enable Te(traffic enginnering) command then which protocol used for LSP Creation? if RSVP then its means RSVP is automatically activate with TE?  &   no need of LDP for LSP when TE enable?

RSVP should be enabled when configure MPLS TE to generate the dynamic CR-LSP, and it's not enable automatically, you should configure it manually. It's unnecessary to enable LDP when configuring MPLS TE.

Actually, you can consider the MPLS + LDP as a combination, and MPLS TE + RSVP as a combination. When confiugring the traditional MPLS tunnel, choosing MPLS + LDP, when configuring MPLS TE, choosing MPLS TE + RSVP.



Last in MPLS L2VPN we have CR-LSP or LSP?if yes then why?

In MPLS L2VPN, the signaling protocol is LSP. 

By the way, there are no strict boundaries, cause MPLS tunnel could carry MPLS packet too. So, theoretically, it's possible to encapsulate the MPLS packets in MPLS tunnel for multiple times. As in the MPLS L3VPN option C, the packets could carry as much as three MPLS lables, it seems like MPLS over MPLS.

  • x
  • convention:

Comment

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login