158 LABEL DISTRIBUTION PROTOCOLS
assume that the path between the ingress LSR A and the egress LSR G, calculated using OSPF, passes through E and F. Using CR-LDP we can set up a CR-LSP that satisfies
a QoS criterion, such as minimize the end-to-end delay. For instance, if LSRs B, C, and D are not heavily utilized, routing the CR-LSP through these LSRs will reduce the
end-to-end delay, even though the number of hops will be higher than the E-to-F path.
The following are some of the features of CR-LDP: •
CR-LDP is based on LDP, and runs on top of TCP for reliability. •
The CR-LDP state-machine does not require periodic refreshment. •
CR-LDP permits strict and loose explicit routes. This allows the ingress LSR some degree of imperfect knowledge about the network topology see Section 6.2.3. The
source LSR might also request route pinning, which fixes the path through a loosely defined route so that it does not change when a better next hop becomes available.
• CR-LDP permits path preemption by assigning setupholding priorities to CR-LSPs. If a
route for a high-priority CR-LSP cannot be found, then existing lower-priority CR-LSPs can be rerouted to permit the higher-priority CR-LSP to be established.
• The network operator can classify network resources in various ways. CR-LDP per-
mits the indication of the resource classes that can be used when a CR-LSP is being established.
• As in the case of ATM, CR-LDP allows the specification of traffic parameters on a
CR-LSP and how these parameters should be policed. CR-LDP depends on the following minimal LDP functionality:
• Basic andor extended discovery mechanism
• Label request message for downstream on demand with ordered control
• Label mapping message for downstream on demand with ordered control
• Notification messages
• Label withdraw and release messages
• Loop detection for loosely routed segments
7.2.1 CR-LSP Setup Procedure
A CR-LSP is set up using downstream on demand allocation with ordered control. Recall that in the downstream on demand allocation scheme, each LSR binds an incoming label
to a FEC and creates an appropriate entry in its LFIB. However, it does not advertise its label mapping to its neighbors as in the unsolicited downstream allocation scheme.
Instead, an upstream LSR obtains the label mapping by issuing a request. In the ordered control scheme, the allocation of labels proceeds backwards from the egress LSR towards
the ingress LSR. Specifically, an LSR only binds a label to a FEC if it is the egress LSR for that FEC, or if it has already received a label binding for that FEC from its next
hop LSR.
An example of how a CR-LSP is set up is shown in Figure 7.10. Let us assume that LSR A has been requested to establish a CR-LSP to LSR E. A request to set up a CR-
LSP to LSR E might originate from a management system or an application. LSR A calculates the explicit route using information provided by the management system, or
the application, or from a routing table, and creates the label request message. The explicit
THE CONSTRAINED-BASED ROUTING LABEL DISTRIBUTION PROTOCOL 159
A B
E C
D
Label request message
Time Label
mapping message
Figure 7.10 An example of a CR-LSP setup.
route in this case is given by the series of LSRs B, C, and D. It is carried in a special TLV in the label request message called the explicit route TLV ER-TLV.
The ingress LSR A sends the label request message to LSR B, the first LSR indicated in the ER-TLV, requesting a label mapping for the FEC associated with the CR-LSP.
Because of the ordered control scheme, LSR B cannot create a label mapping to the FEC until it has received a label mapping from its next hop LSR C. Also, because of the
downstream on demand allocation scheme, LSR C does not advertise its label mappings to its neighbors. In view of this, LSR B forwards the label request message to LSR C
requesting a label mapping for the FEC. LSR C forwards the label mapping request to LSR D for the same reasons, which then forwards the label request message to the egress
LSR E. The egress LSR E is now allowed to create a label mapping to the FEC. It does so, and it responds to LSR D’s label request message with a label mapping message
that contains the allocated label. When LSR D receives the label mapping message form LSR E it responds to LSR C’s label request message with a label mapping message that
contains its own incoming label, and so on, until LSR A receives a label mapping message form LSR B. At that time, the CR-LSP has been set up.
Next, the label request message and the label mapping message are described.
7.2.2 The Label Request Message
The label request message is shown in Figure 7.11. The U bit is set to 0, and the message type set to label request 0x0401. The FEC TLV see Figure 7.7 must be included in
the label request message, and it contains a single new FEC element, named CR-LSP. The LSPID TLV is required and is used to give a unique identifier of a CR-LSP. It
is composed of the ingress LSR router id or any of its IPv4 addresses and a CR-LSP id which is locally unique to that LSR. The LSPID is useful in network management, in
CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV. The explicit-route TLV ER-TLV, shown in Figure 7.12, is used to specify the path
to be taken by the LSP being established. It is composed of one or more explicit route hop TLVs ER-hop TLV
which have the format shown in Figure 7.13. The type field indicates the type of the ER-hop contents, and it can take one of the following values:
IPv4 prefix, IPv6 prefix, autonomous system number, LSPID. If an LSR receives a label
160 LABEL DISTRIBUTION PROTOCOLS
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
1
Label request 0x0401 Message length
Message id FEC TLV
LSPID TLV mandatory ER-TLV optional
Traffic parameters TLV optional Pinning TLV optional
Resource class TLV optional Preemption TLV optional
Figure 7.11 The CR-LDP label request message.
1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
1
0 0 Type = 0x0800
Length ER-hop TLV 1
ER-hop TLV n
• •
•
Figure 7.12 The ER-TLV.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
1
0 0 L
Length Content
Type
Figure 7.13 The ER-hop TLV.
request message containing an ER-hop TLV which it does not support, the LSR will not progress the label message to the next hop downstream LSR and it will send back
a no route notification message. The L bit is used to indicate whether the ER-hop is loose or strict see Section 6.2.3. The contents field contains a node or an abstract node
representing a group of nodes.
THE CONSTRAINED-BASED ROUTING LABEL DISTRIBUTION PROTOCOL 161
Route pinning is applicable to segments of a CR-LSP that are loosely routed. It is
signaled using the route pinning TLV. The resource classes that can be used to set up an CR-LSP are indicated in the resource class TLV.
The preemption TLV is used to assign a setup priority and a holding priority of the CR- LSP. These priorities are used to determine if the new CR-LSP can preempt an existing
one. Assigning a higher holding priority means that the CR-LSP, once it has been set up, has a low chance of being preempted. Assigning a high setup priority means that, in the
case that resources are unavailable, the CR-LSP has a high chance of preempting existing CR-LSPs.
The traffic parameters TLV is used to signal the values of the traffic parameters that characterize the CR-LSP that is being established. This TLV will be discussed in detail
in Section 7.2.4.
7.2.3 The Label Mapping Message
The label mapping message is shown in Figure 7.14. The U bit is set to 0, and the message type set to label mapping 0x0400. The FEC and LSPID TLVs are the same as in the
CR-LDP label request message. The label TLV is the same as in LDP see Figure 7.8. The label request message id TLV is used as follows. If this label mapping message is
a response to a label request message, then it must include the label request message id parameter. This parameter is carried in the label request message id TLV. The traffic
parameters TLV is described in the next section.
7.2.4 The Traffic Parameters TLV
The traffic parameters TLV is used in the label request and label mapping messages. It is used to describe the traffic parameters of the CR-LSP that is being established. The traffic
parameters TLV is shown in Figure 7.15. The traffic parameters TLV type is 0x0810, and the length of the value field is 24 bytes. The following fields have been defined:
flags, frequency, weight, peak data rate PDR, peak burst size PBS, committed data rate
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
3 4 5 6 7 8 9 1
Label mapping 0x0400 Message length
Message id FEC TLV
Label TLV Label request message id TLV
LSPID TLV optional Traffic parameters TLV optional
Figure 7.14 The label mapping message.
162 LABEL DISTRIBUTION PROTOCOLS
0 0
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
1
Flags Frequency
Reserved Weight
Peak data rate PDR Peak burst size PBS
Committed data rate CDR Committed burst size CBS
Excess burst size EBS Type 0x0810
Length
Figure 7.15 The traffic parameters TLV.
CDR , committed burst size CBS and excess burst size EBS. The PDR and the PBS
parameters are used to define the traffic sent to the CR-LSP. The parameters CDR, CBS, and EBS, are used to specify how the network will police the traffic submitted to the
CD-LSP. Finally, the flags, frequency, and weight fields are used to provide additional information as will seen below.
Peak data rate PDR and peak burst size PBS The peak rate is the maximum rate at which traffic is sent to the CR-LDP, and is expressed
in bytessec. The equivalent parameter in ATM is the peak cell rate PCR. Unlike the PCR, which is specified by a single value, the peak rate in CR-LDP is specified in terms
of token bucket P . The maximum token bucket size of P is set equal to the peak burst size PBS
, expressed in bytes, and the token bucket is replenished at the peak data rate PDR
, expressed in bytessec. The PBS defines the maximum packet size that can be sent to the CR-LSP, and the PDR gives the maximum rate at which traffic is transmitted
by the user. The peak rate, is the output from the token bucket P , which is sent to the CR-LSP.
The token bucket operates as follows: •
Initially, the token count i.e., the number of tokens in the token bucket is T
P
= PBS
. •
Let PDR = N bytessec. Then, if T
P
≤ PBS
, the token count T
P
is incremented every second by N it should not exceed PBS .
• When a packet of size B bytes arrives, if T
P
− B ≥
0, then the packet is not in excess of the peak rate, and T
P
= T
P
− B
. •
Otherwise, it is in excess of the peak rate, and T
P
is not decreased. The packet is a violating packet
and it can be marked or dropped. Note that a positive infinite value of either PBS or MBS implies that arriving packets
are never in excess of the peak rate. An example of the peak rate token bucket operation is given in Figure 7.16. The thick
line at the top indicates the value of T
P
, and the thin line below indicates the arrival of
