Juniper JUNOSE 11.2.X BGP AND MPLS, Configuration Manual

Page: 303 / 742

When you issue the mpls rsvp bfd-liveness-detection command on an RSVP-TE major
interface, BFD liveness detection is established with all BFD-enabled RSVP-TE peers
associated with that interface.
When an RSVP-TE session is established with the remote peer—if BFD is enabled and if
the BFD session is not already present—then the local peer attempts to create a BFD
session to the remote peer. The BFD session is established only if when both of the
following are true:
•
At least one RSVP-TE LSP exists between (passes through) a pair of directly connected
RSVP-TE major interfaces.
• Both interfaces are BFD-enabled.
Consequently, when the last LSP is torn down between the interfaces, the BFD session
is no longer required and is brought down as well.
Each adjacent pair of peers negotiates an acceptable transmit interval for BFD packets.
The negotiated value can be different on each peer. Each peer then calculates a BFD
liveness detection interval. When a peer does not receive a BFD packet within the detection
interval, it declares the BFD session to be down and purges all routes learned from the
remote peer.
Related Topics For general information about configuring and monitoring the BFD protocol, see JunosE
IP Services Configuration Guide .
•
•
Configuring the BFD Protocol for RSVP-TE on page 300
Tunneling Model for Differentiated Services Overview
The JunosE Software supports both the pipe model and the uniform model for tunneling
with the
mpls tunnel-model command. The router also provides a way to implement
the functionality of the short pipe model for IP packets.
Pipe and Short Pipe Models
In the pipe and short pipe models, any traffic conditioning (that is, in a pure JunosE
environment, a change in traffic class/color combination) that is applied when traffic
goes through the tunnel has no effect on the EXP bits coding in the inner header. In other
words, when traffic exits an LSP (when a label is popped) or when traffic enters an LSP,
the inner header’s EXP bits coding is not changed.
The pipe and short pipe models differ in the header that the tunnel egress uses when it
determines the PHB of an incoming packet. With the short pipe model, the tunnel egress
uses an inner header that is used for forwarding. With the pipe model, the outermost
label is always used. Because of this, you cannot use PHP with the pipe model.
The pipe model is the default JunosE behavior, which you can configure with the mpls
tunnel-model command. You cannot configure the short pipe model with this command.
In fact, on ingress line modules the traffic class/color combination is always determined
from the outermost label, so fabric queuing is also based on the outermost label. However,
on the egress line module you can achieve the queuing behavior expected with the short
267 Copyright © 2010, Juniper Networks, Inc.
Chapter 3: MPLS Overview