Resource Reservation Protocol

RSVP

We cant build a large network with static LSPs so we need a protocol like RSVP. RSVP still requires manual configuration on the ingress router, every other hop takes care of establishing the path.

The benefit of manul configuration is the rich set of traffic engineering capabilities

• follow the best path
• take a specific path
• reserve BW across the path
• optimize the path as topology changes

RSVP Features

• Different priority levels
• automatic re-signalling of BW
• automatic split of LSPs
• Backup/standby path
• local repair (protection from link/node failure)
• Tagging of links (admin-groups)
• P2MP LSPs (for multicast applications)

RSVP carry opaque objects that carry useful information like BW, labels etc which are meaningless to RSVP but useful to MPLS routers.

Routers learn about these attributes like tags, BW, priority etc from the IGP extensions. OSPF/IS-IS are extended to carry traffic engineering information.

TE extensions are enabled by default in IS-IS. In OSPF, we need to manually enable these TE extensions.

TE information is stored in the TED (Traffic Engineering Database).

We can configure RSVP LSPs to either use the TED or use the regular LSDB.

• Use the TED to calculate a traffic engineered path
• Use the LSDB to follow the shortest path

If we use TED, the ingress router calculates the complete path based on the constraints set and includes the path in an ERO (Explicit Route Object) when the LSP is signalled. Each router in the path obeys the ERO.

If we use the LSDB only, ingress router calculates the best path, but does not include any EROs. It decides only the next-hop but not the exact end-to-end path. Each hop runs SPF to decide the next hop.

LSPs can still reserve BW with out TE, but if BW is not available, the LSP fails.

Configuring RSVP

• configure MPLS on core facing interfaces in both data plane and control plane
• configure RSVP on core facing interfaces
• Allow RSVP through control plane protection firewall filters (if any applied)
• Enable traffic engineering extensions (turned on by default in IS-IS, requires manual config in OSPF)

[edit]
root@juniper# set interfaces <interface-name> unit 0 family mpls
[edit]
root@juniper# set protocols mpls interface <interface-name>
[edit]
root@juniper# set protocols rsvp interface <interface-name>

Enabling RSVP doesn’t itself automatically create LSPs. It simply enables the interface to talk the RSVP protocol. RSVP does not use any Transport protocol like UDP/TCP, it has its own protocol number, 46. RSVP is IP protocol `46.

root@juniper> show rsvp interface

Up means RSVP configured on the local router, it tells nothing about the remote router.

To verify both ends of a link, use

root@juniper> show rsvp neighbor

Idle should be 0 and both Hello Tx/Rx should increase.

Once we have configured RSVP LSP, to test that LSP is able to forward traffic, we can make use of MPLS self-ping which uses UDP port 8503.

Configuring the Core for OSPF for Simple RSVP LSP (without TE)

• single area
• reference BW
• p2p interfaces
• No TE extensions (for now)
• choose a name for the LSP, specify the endpoint, and turn of CSPF

Constrained Shortest Path First calculates the traffic engineered paths. Since we have not yet enabled TE extensions for OSPF, TED will be empty at this point.

[edit]
root@juniper# set protocols mpls label-switched-path <lsp-name> to 10.20.30.9 no-cspf

RSVP LSPs are configured under edit protocols mpls hierarchy, not under edit protocols rsvp.

Since we used no-cspf, this LSP uses only LSDB. Ingress router calculates the best next-hop to the egress IP (10.20.30.9) and sends a Path message to that next-hop device. The next-hop device does the same, calculates a best next-hop to the egress IP and sends a Path message downstream towards the egress. No EROs carried in these messages.

If the Path is successful, Resv messages confirm that the LSP has been setup. The Resv messages start from egress towards the ingress and travel upstream. When these Resv messages reach the ingress router, the LSP is complete and traffic can be sent down it.

To display all LSPs (Ingress, Egress, and Transit)

root@juniper> show mpls lsp

In the inet.3 table, we see an entry for the egress IP as [RSVP/7/1] , with a next-hop as the LSP name.

root@juniper> show mpls lsp name <lsp-name> extensive

• Egress router IP
• Ingress router IP
• LSP name
• ActivePath: (primary )
• LSPType: Static Configured, Penultimate hop popping
• Primary
• Priorities 7 0
• Recived RRO (Record Route Object)
• Logs with timestamp

Each hop adds itself to the RRO object, to indicate the full end-to-end path.

Logs:

• Originate Call - started signalling LSP
• LSP-ID created
• Record Route
• Self-ping enqueued
• Self-ping started
• Up
• Self-ping ended successfully
• Selected as active path

MPLS Self-ping

To check if an LSP is ready to forward traffic, the router sends a packet down the LSP, destined to itself.

In Junos, no additional config required. When the packet reaches the other end of the LSP, it will be sent back to the ingress router as pure IP traffic. Through this, one-way MPLS connectivity is verified.

Remember LSPs are unidirectional.

With self-ping, one-way LSP has been tested for forwarding without relying on an LSP in the reverse direction.

If we dont allow MPLS self-ping, LSP will still come up, will still forward traffic.

But the backup/local repair paths will fail.

MPLS self-ping is required in situations where a second alternative path is required.

RSVP LSP Signalling

• Hello Messages
• Path Messages (ingress to egress, requesting LSP to be setup)
• Resv Messages (egress to ingress, confirming LSP setup)

All RSVP messages contain a lot of objects, each object carries a piece of information.

Session Object:

• Destination: egress device ip
• Tunnel ID: unique number identifying the LSP

Session Attribute Object:

• Name: LSP name
• Setup Priority: 7
• Hold Priority: 0

Label Request Object- which label to use

Record Route Object- Each router in the path adds its outgoing interface IP to this list, so that all devices have full visibility of the path this message has taken so far. Useful for loop detection also.

To see RSVP-specific state (similar to show mpls lsp)

root@juniper> show rsvp session

Labelin, Labelout, Style, LSPname are shown in this output.