Tunneling Model For Differentiated Services Overview; Pipe And Short Pipe Models - Juniper JUNOSE SOFTWARE FOR E SERIES 11.3.X - BGP AND MPLS CONFIGURATION GUIDE 2010-10-12 Configuration Manual

Related
Documentation

Tunneling Model for Differentiated Services Overview

Pipe and Short Pipe Models

Copyright © 2010, Juniper Networks, Inc.
When a BFD session exists between RSVP-TE peers, a peer that goes down is detected
quickly, enabling faster rerouting of traffic. Adjacency failure detection by means of hello
messages takes place on the order of seconds, whereas BFD fast failure detection can
take place on the order of hundreds of milliseconds.
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.
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
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.
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.
Chapter 3: MPLS Overview
267