No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Configuration Guide - MPLS

S7700 and S9700 V200R010C00

This document describes MPLS configurations supported by the switch, including the principle and configuration procedures of static LSPs, MPLS LDP, MPLS TE, MPLS QoS, MPLS OAM, Seamless MPLS, and MPLS common features, and provides configuration examples.
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).
CS-LSP Setup

CS-LSP Setup

CR-LSP Setup Overview

CR-LSP Setup Modes

A CR-LSP can be statically or dynamically set up.

A static CR-LSP is set up depending on manual configuration. This section describes how dynamic CR-LSPs are set up through RSVP-TE.

Introduction to RSVP-TE

The Resource Reservation Protocol (RSVP) is designed for the integrated services model, and reserves resources for nodes along a path. This bandwidth reservation capability makes RSVP-TE a suitable signaling protocol for establishing MPLS TE paths.

RSVP-TE provides the following extensions based on RSVP to support MPLS TE implementation:
  • RSVP-TE adds Label Request objects to Path messages to request labels and adds Label objects to Resv messages to allocate labels.

  • An extended RSVP message can carry path constraints in addition to label binding information.

  • The extended objects carry MPLS TE bandwidth constraints to implement resource reservation.

RSVP Message Types

RSVP defines the following types of messages:

  • Path message: is sent downstream by the sender and saves path information on the nodes it passes through.

  • Resv message: is sent upstream by the receiver to respond to the Path message and to request resource reservation.

  • PathErr message: is sent by an RSVP node to its upstream node if an error occurs while this node is processing a Path message.

  • ResvErr message: is sent by an RSVP node to its downstream node if an error occurs while this node is processing a Resv message.

  • PathTear message: is sent to delete path information and functions in the opposite way to a Path message.

  • ResvTear message: is sent to delete the resource reservation state and functions in the opposite way to a Resv message.

  • ResvConf message: is sent downstream from the sender hop by hop to confirm a resource reservation request. This message is sent only when the Resv message contains the RESV_CONFIRM object.

  • Srefresh message: is used to update the RSVP state.

RSVP-TE Implementation
Table 5-4 describes RSVP-TE implementation.
Table 5-4  RSVP-TE implementation

Function

Description

Setup of Dynamic CR-LSPs

A CR-LSP is set up according to the CSPF calculation result or an explicit path. CR-LSP setup is triggered on the ingress node.

Maintenance of Dynamic CR-LSPs

  • Path Status Maintenance

    After a CR-LSP is set up, RSVP-TE still sends RSVP messages to maintain the path state on each node.

  • Error Signaling

    RSVP nodes send error messages to notify upstream and downstream nodes that faults have occurred during path establishment or maintenance.

  • Path Teardown

    A CR-LSP is torn down, and labels and bandwidth on each node are released. The ingress node initiates teardown requests.

Setup of Dynamic CR-LSPs

To establish a dynamic CR-LSP from an ingress node to an egress node, the ingress node sends Path messages to the egress node and the egress node sends Resv messages back to the ingress node. Path messages are sent to create Resource Reservation Protocol (RSVP) sessions and associate the path status. Every node that receives a path message creates a path state block (PSB). A Resv message carries resource reservation information. Every node that receives a Resv message creates a reservation state block (RSB) and allocates a label.

Figure 5-16 shows how RSVP-TE sets up a CR-LSP.

Figure 5-16  CR-SLP setup through RSVP-TE
  1. PE1 uses CSPF to calculate a path from PE1 to PE2, on which the IP address of every hop is specified. PE1 generates an explicit route object (ERO) with the IP address of each hop and adds the ERO in a Path message. PE1 then creates a PSB and sends the Path message to P1 according to information in the ERO. Table 5-5 describes objects carried in the Path message.

    Table 5-5  Path message on PE1
    Object Value
    SESSION Source: PE1-if1; Destination: PE2-if0
    RSVP_HOP PE1-if1
    EXPLICIT_ROUTE P1-if0; P2-if0; PE2-if0
    LABEL LABEL_REQUEST
  2. After P1 receives the Path message, it parses the message and creates a PSB according to information in the message. Then P1 updates the message and sends it to P2 according to the ERO. Table 5-6 describes objects in the Path message.

    • The RSVP_HOP object specifies the IP address of the outbound interface through which a Path message is sent. Therefore, PE1 sets the RSVP_HOP object to the IP address of the outbound interface toward P1, and P1 sets the RSVP_HOP field to the IP address of the outbound interface toward P2.

    • P1 deletes the local LSR ID and IP addresses of the inbound and outbound interfaces from the ERO field in the Path message.

    Table 5-6  Path message on P1
    Object Value
    SESSION Source: PE1-if1; Destination: PE2-if0
    RSVP_HOP P1-if1
    EXPLICIT_ROUTE P2-if0; PE2-if0
    LABEL LABEL_REQUEST
  3. After receiving the Path message, P2 creates a PSB according to information in the message, updates the message, and then sends it to PE2 according to the ERO field. Table 5-7 describes objects in the Path message.

    Table 5-7  Path message on P2
    Object Value
    SESSION Source: PE1-if1; Destination: PE2-if0
    RSVP_HOP P2-if1
    EXPLICIT_ROUTE PE2-if0
    LABEL LABEL_REQUEST
  4. After PE2 receives the Path message, PE2 knows that it is the egress of the CR-LSP to be set up according to the Destination field in the Session object. PE2 then allocates a label and reserves bandwidth, and generates a Resv message based on the local PSB. The Resv message carries the label allocated by PE2 and is sent to P2.

    PE2 uses the address carried in the RSVP_HOP field of the received Path message as the destination IP address of the Resv message. The Resv message does not carry the ERO field because it is forwarded along the reverse path. Table 5-8 describes objects in the Resv message.
    NOTE:

    If a Resv message carries the RESV_CONFIRM object, the receiver needs to send a ResvConf message to the sender to confirm the resource reservation request.

    Table 5-8  Resv message on PE2
    Object Value
    SESSION Source: PE2-if0; Destination: PE1-if1
    RSVP_HOP PE2-if0
    LABEL 3
    RECORD_ROUTE PE2-if0
  5. When P2 receives the Resv message, P2 creates an RSB according to information in the message, allocates a new label, updates the message, and then sends it to P1. Table 5-9 describes objects in the Resv message.

    Table 5-9  Resv message on P2
    Object Value
    SESSION Source: PE2-if0; Destination: PE1-if1
    RSVP_HOP P2-if0
    LABEL 17
    RECORD_ROUTE P2-if0; PE2-if0
  6. After receiving the Resv message, P1 creates an RSB according to information in the message, updates the message, and then sends it to PE1. Table 5-10 describes objects in the Resv message.

    PE1 obtains the label allocated by P1 from the received Resv message. Resources are successfully reserved and a CR-LSP is set up.

    Table 5-10  Resv message on P1
    Object Value
    SESSION Source: PE2-if0; Destination: PE1-if1
    RSVP_HOP P1-if0
    LABEL 18
    RECORD_ROUTE P1-if0; P2-if0; PE2-if0

Maintenance of Dynamic CR-LSPs

Path Status Maintenance

Soft State

The Resource Reservation Protocol (RSVP) is a soft-state protocol. RSVP-TE periodically updates RSVP messages to maintain the resource reservation states on nodes.

Resource reservation states include the path state and the reservation state. RSVP nodes along an established CR-LSP periodically send Path and Resv messages (collectively called RSVP Refresh messages) to maintain the path and reservation states. RSVP Refresh messages are used to synchronize path state block (PSB) and reservation state block (RSB) between RSVP nodes. If an RSVP node does not receive any Refresh message within a specified period, it deletes the path or reservation state.

RSVP Refresh

RSVP sends its messages as IP datagrams, which cannot ensure a reliable delivery. After a CR-LSP is set up, the soft state mechanism synchronizes the PSB and RSB between RSVP neighbors. Each node periodically sends RSVP Refresh messages to its upstream and downstream nodes.

Refresh messages carry information that has already been advertised. The Time Value field in Refresh messages specifies the refresh interval.

If a node does not receive any Refresh message about a certain state block after the specified refreshing intervals elapses, it deletes the state.

A node can send Path and Resv messages to its neighbors in any sequence.

RSVP Srefresh

In addition to state synchronization, RSVP Refresh messages can also be used to detect reachability between RSVP neighbors and maintain RSVP neighbor relationships. Because Path and Resv messages are large, sending many RSVP Refresh messages to establish a large number of CR-LSPs consumes excess network resources. RSVP Summary Refresh (Srefresh) can address this problem.

RSVP Srefresh is implemented based on extended objects and the following mechanisms:
  • Message_ID extension and retransmission

    The Message_ID extension extends objects carried in RSVP messages. Among the objects, the Message_ID and Message_ID_ACK objects acknowledge received RSVP messages to ensure reliable RSVP message delivery.

    The Message_ID object can also provide the RSVP retransmission mechanism. A node resets the retransmission timer (Rf seconds) after sending an RSVP message carrying the Message_ID object. If the node receives no ACK message within Rf seconds, the node retransmits an RSVP message after (1 + Delta) x Rf seconds. The Delta value depends on rate at which the sender increases the retransmission interval. The node keeps retransmitting the message until it receives an ACK message or the retransmission count reaches the threshold (retransmission multiplier).

  • Srefresh messages transmission

    Srefresh messages can be sent instead of standard Path or Resv messages to update RSVP states. These messages reduce the amount of information that must be transmitted and processed for maintaining RSVP states. When Srefresh messages are sent to update the RSVP states, standard Refresh messages are suppressed.

    Each Srefresh message carries a Message_ID object, which contains multiple message IDs to identify the Path and Resv states to update. Srefresh implementation depends on the Message_ID extension. Srefresh messages can only update the states that have been advertised in Path and Resv messages containing Message_ID objects.

    When a node receives a Srefresh message, the node compares the Message_ID in the message with that saved in the local PSB or RSB. If the two Message_IDs match, the node updates the local state block, just like it receives a standard Path or Resv message. If they do not match, the node sends a Srefresh NACK message to the sender. Later, the node updates the Message_ID and the state block based on the received Path or Resv message.

    A Message_ID object contains a message identifier. When a CR-LSP changes, the message identifier increases. A node compares the message identifier in the received Path message with the message identifier saved in the local state block. If they are the same, the node does not update the state block. If the received message identifier is larger than the local message identifier, the node updates the state block.

Error Signaling
RSVP-TE uses the following messages to advertise CR-LSP errors:
  • PathErr message: is sent by an RSVP node to its upstream node if an error occurs while this node is processing a Path message. The message is forwarded upstream by intermediate nodes and finally reaches the ingress node.

  • ResvErr message: is sent by an RSVP node to its downstream node if an error occurs while this node is processing a Resv message. The message is forwarded downstream by intermediate nodes and finally reaches the egress node.

Path Teardown

After the ingress node receives a PathErr message or an instruction to delete a CR-LSP, it immediately sends a PathTear message downstream. After receiving this message, the downstream nodes tear down the CR-LSP and reply with a ResvTear message.

The functions of PathTear and ResvTear messages are as follows:
  • PathTear message: is sent to delete path information and functions in the opposite way to a Path message.

  • ResvTear message: is sent to delete the resource reservation state and functions in the opposite way to a Resv message.

RSVP-TE Messages

Nodes on an MPLS TE network send RSVP-TE messages to exchange information.

RSVP Message Format

Each type of RSVP messages contains a common header, followed by multiple objects with variable lengths and types. Figure 5-17 shows the format of RSVP messages.

Figure 5-17  RSVP message format

Table 5-11 describes each field in an RSVP message.

Table 5-11  Fields an RSVP message

Field

Length

Description

Version

4 bits

Indicates the RSVP version number. Currently, the value is 1.

Flags

4 bits

Indicates the message flag. Generally, the value is 0. RFC 2961 extends this field to identify whether Summary Refresh (Srefresh) is supported. If Srefresh is supported, the value of the Flags field is 0x01.

Message Type

8 bits

Indicates RSVP messages type. For example, the value 1 indicates a Path message, and the value 2 indicates a Resv message.

RSVP Checksum

16 bits

Indicates the RSVP checksum. The value 0 indicates that the checksum of messages is not checked during transmission.

Send_TTL

8 bits

Indicates the TTL of an RSVP message. When a node receives an RSVP message, it compares the Send_TTL and the TTL in the IP header to calculate the number of hops that the message has passed in a non-RSVP area.

Reserved

8 bits

Indicates that the field is reserved.

RSVP Length

16 bits

Indicates the total length of an RSVP message, in bytes.

Objects

Variable

Indicates the objects in an RSVP message. Each RSVP message contains multiple objects. The carried objects vary in different types of messages.

Length

16 bits

Indicates the total length of an object, in bytes. The value must be a multiple of 4, and the smallest value is 4.

Class_Number

8 bits

Identifies an object class. Each object class has a name, such as SESSION, SENDER_TEMPLATE, or TIME_VALUE.

C-Type

8 bits

Indicates an object type. Class-Number and C-Type together identify an object.

Object Content

Variable

Indicates the content of an object.

Path Message

RSVP-TE uses Path messages to create RSVP sessions and to maintain path states. A Path message is sent from the ingress node to the egress node. A path state block (PSB) is created on each node the Path message passes.

The source IP address of a Path message is the LSR ID of the ingress node and the destination IP address is the LSR ID of the egress node.

Table 5-12 lists some of the objects carried in a Path message.

Table 5-12  Objects in a Path message

Object

Class_Number

C-Type

Object Content

SESSION

1

1

Carries RSVP session information, such as the destination address, tunnel ID, and extend tunnel ID.

RSVP_HOP

3

1

Carries the IP address and index of the outbound interface on the previous hop that sends the Path message.

TIME_VALUE

5

1

Carries the refresh interval.

SENDER_TEMPLATE

11

1

Carries the sender IP address and LSP ID.

SENDER_TSPEC

12

2

Specifies the traffic characteristics of a data flow.

LABEL_REQUEST

19

1

Indicates that label binding is requested for the path. This object is carried only in Path messages.

ADSPEC

13

2

Collects QoS parameters of a path, such as estimated path bandwidth, minimal path delay, and path MTU.

EXPLICIT_ROUTE

20

1

Specifies the path through which an LSP passes. The path can be a strict or loose explicit path. Path messages are then forwarded along the specified Explicit Route Object (ERO). Path message transmission is not restricted by IGP shortest path.

RECORD_ROUTE

21

1

Lists the label switching routers (LSRs) that the Path message passes. The Record Route Object (RRO) can be used to collect path information and discover routing loops. It can also be copied to the next Path message to implement Route pinning.

SESSION_ATTRIBUTE

207

  • 1: LSP_TUNNEL_RA
  • 7: LSP Tunnel

Specifies the setup priority, holding priority, reservation style, affinity, and other attributes.

Resv Message

After receiving a Path message, the egress node returns a Resv message. The Resv message carries resource reservation information and is sent hop-by-hop to the ingress node. Each intermediate node creates and maintains a reservation state block (RSB) and allocates a label. When the Resv message reaches the ingress node, an LSP is set up successfully.

Table 5-13 describes objects in a Resv message.

Table 5-13  Objects in a Resv message

Object

Class_Number

C-Type

Object Content

INTEGRITY

4

1

Carries the authentication key of the RSVP message.

SESSION

1

1

Carries RSVP session information, such as the destination address, tunnel ID, and extend tunnel ID.

RSVP_HOP

3

1

Carries the IP address and the index of the outbound interface that sends the Resv message.

TIME_VALUE

5

1

Carries the refresh interval. The default value is 30s.

STYLE

8

1

Carries the resource reservation style, which is specified on the ingress node.

FLOW_SPEC

9

  • 1: Reserved (obsolete) flowspec object
  • 2: Inv-serv flowspec object

Specifies QoS characteristics of a data flow.

FILTER_SPEC

10

1

Carries the sender IP address and LSP ID.

RECORD_ROUTE

21

1

Collects the inbound interface IP address, LSR-ID, and outbound interface IP address of each node along the path.

LABEL

16

1

Carries the assigned label.

RESV_CONFIRM

15

1

Indicates a confirmation of the resource reservation request. This object carries the IP address of the node that requests resource reservation confirmation.

Reservation Styles

A reservation style is the method that an RSVP node uses to reserve resources after receiving a resource reservation request from the upstream node. The following reservation styles are supported:

  • Fixed Filter (FF) style: creates an exclusive reservation for each sender. A sender does not share its resource reservation with other senders, and each CR-LSP on a link has a separate resource reservation.

  • Shared Explicit (SE) style: creates a single reservation for a series of selected upstream senders. CR-LSPs on a link share the same resource reservation.

Translation
Download
Updated: 2019-04-18

Document ID: EDOC1000141902

Views: 73163

Downloads: 189

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next