Enabling Rsvp Traps; Rsvp For Mpls-Te Features- Details - Cisco NCS 5500 Series Configuration Manual

Implementing RSVP for MPLS-TE

RSVP for MPLS-TE Features- Details

Related Documents
• Configuring ACL Based Prefix Filtering, on page 32

Enabling RSVP Traps

By implementing the RSVP MIB, you can use SNMP to access objects belonging to RSVP. You can also
specify two traps (NewFlow and LostFlow) which are triggered when a new flow is created or deleted. RSVP
MIBs are automatically enabled when you turn on RSVP, but you need to enable RSVP traps.
Configuration Example
This example shows how to enable RSVP MIB traps when a flow is deleted or created and also how to enable
both the traps.
RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(config)# snmp-server traps rsvp lost-flow
RP/0/RP0/CPU0:router(config)# snmp-server traps rsvp new-flow
RP/0/RP0/CPU0:router(config)# snmp-server traps rsvp all
RP/0/RP0/CPU0:router(config)# commit
RSVP for MPLS-TE Features- Details
RSVP Graceful Restart Operation
RSVP graceful restart is based on RSVP hello messages. Hello messages are exchanged between the router
and its neighbor nodes. Each neighbor node can autonomously issue a hello message containing a hello request
object. A receiver that supports the hello extension replies with a hello message containing a hello
acknowledgment (ACK) object. If the sending node supports state recovery, a Restart Cap object that indicates
a node's restart capability is also carried in the hello messages. In the Restart Cap object, the restart time and
the recovery time is specified. The restart time is the time after a loss in Hello messages within which RSVP
hello session can be re-established. The recovery time is the time that the sender waits for the recipient to
re-synchronize states after the re-establishment of hello messages.
For graceful restart, the hello messages are sent with an IP Time to Live (TTL) of 64. This is because the
destination of the hello messages can be multiple hops away. If graceful restart is enabled, hello messages
(containing the restart cap object) are send to an RSVP neighbor when RSVP states are shared with that
neighbor. If restart cap objects are sent to an RSVP neighbor and the neighbor replies with hello messages
containing the restart cap object, the neighbor is considered to be graceful restart capable. If the neighbor does
not reply with hello messages or replies with hello messages that do not contain the restart cap object, RSVP
backs off sending hellos to that neighbor. If a hello Request message is received from an unknown neighbor,
no hello ACK is sent back.
RSVP Authentication
Network administrators need the ability to establish a security domain to control the set of systems that initiates
RSVP requests. The RSVP authentication feature permits neighbors in an RSVP network to use a secure hash
to sign all RSVP signaling messages digitally, thus allowing the receiver of an RSVP message to verify the
sender of the message without relying solely on the sender's IP address.
The signature is accomplished on a per-RSVP-hop basis with an RSVP integrity object in the RSVP message
as defined in RFC 2747. The integrity object includes a key ID, a sequence number for messages, and keyed
message digest. This method provides protection against forgery or message modification. However, the
MPLS Configuration Guide for Cisco NCS 5500 Series Routers, IOS XR Release 6.2.x
34