|
Previous
|
Content
|
Next
|
|
|
2.2. Labels |
|
 |
|
|
A label is a short, fixed length, locally significant identifier which is
used to identify a FEC. The label which is put on a particular packet
represents the Forwarding Equivalence Class to which that packet is
assigned. Most commonly, a packet is assigned to a FEC based on its
network layer destination address, but the label is never an encoding
of that address. |
| Two Label Switched Routers (LSRs), Ru and Rd can agree to a binding between
label L and FEC F for packets moving from Ru to Rd.
Then L becomes Ru's outgoing label representing FEC F,
and L becomes Rd's incoming label representing FEC F. L
is an arbitrary value whose binding to F is local to Ru and
Rd. Packets imply either, those originated at Ru, or those
traveling from Ru to Rd, that their destination is Rd. |
| |
|
The binding agreement is unique or one-to-one. That is,
Rd MUST NOT agree with Ru1 to bind L to FEC F1,
while also agreeing with some other LSR Ru2 to bind the same
L to a different FEC F2, UNLESS Rd can always tell, when
it receives a packet with incoming label L, wheather the label was
put on the packet by Ru1 or the label was put on the packet by Ru2.
(This can be done if Ru1 and Ru2 are connected to Rd using different
interfaces. LB). Each LSR is responsible to ensure it can uniquely interpret its
incoming labels. |
| |
| Note that L does not necessarily represent FEC F for any
packet other than those which are being sent from Ru to Rd.
L is an arbitrary value whose binding to F is local to
Ru and Rd. |
| |
|
It is very important to insist that binding between L and FEC is a
local matter to Ru and Rd. LB. |
| |
| When the binding agreement is done, with respect to this binding, Ru
is the upstream LSR and Rd the downstream LSR. |
| |
|
It's very important to note that Ru and Rd don't have to be (necessarely) direct
neighbors. LB. |
| |
| A labeled packet is a packet into which a label has been
encoded. The label can reside in an encapsulation header which
exists specifically for this purpose or it can reside in an existing data
link or network layer header, as long as there is a field
available for that purpose. The encoding technique must be agreed by
the entities that encode and decode the label. |
| |
| In the MPLS architecture, the decision to bind a particular label
L and FEC F is made by the LSR which is DOWNSTREAM
with respect to that binding. The downstream LSR then informs the
upstream LSR of the binding. Labels are "downstream-assigned" and
binding are distributed in the "downstream to upstream" direction. |
| |
|
The binding agreement L-F
is unique and local between routers Ru and Rd. Then, the binding is done
by the downstream router Rd, which in fact, distributes this to its upstream
neighbor Ru. LB. |
|
|
|
|
|
A particular binding L-F distributed Rd
> Ru may have associated "attributes".
If Ru acting as a downstream LSR distributes binding L-F too, then under certain conditions, it may be required to also distribute
the corresponding attributes that it receives from Rd. (In this
case Ru acts as Rd for another Ru which is its upstream neighbor and
attributes propagate upstream. LB). |
|
Label Distribution Protocol (LDP) |
|
LDP is a set of procedures by which one
LSR informs another of the L-F bindings it has made. Two
LSRs that exchange label/FEC binding information are known as "label
distribution peers". If two LSRs are "label distribution peers"
then we will say that there being a "label distribution adjacency"
between them. (MPLS peer routers exchange routing information just as OSPF
neighbor routers do. LB). |
|
Two LSRs may be label distribution
peers with respect to some set of binding, but not with respect to some
other set of bindings. |
|
THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS
ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. In fact, there are several
(MPLS-LDP, CR-LDP, RSVP-TE, MPLS-BGP). In this specification LDP
refers to the protocol defined in [MPLS-LDP] specification. This
is just the LDP protocol defined in RFC 3036. LB. |
|
How bindings are distributed |
| |
|
"Downstream on-demand" is when an
(upstream) LSR
explicitly requests, from its next (downstream) hop for a particular FEC, a
label binding for that FEC. "Unsolicited downstream" is when
an (downstream) LSR distributes binding to other (upstream) LSRs that have not
explicitly requested them. Both of these label distribution techniques
may be used in the same network at the same time. On any given label
distribution adjacency the LSRs must agree on which technique
is to be used. |
| |
|
Label Retention Mode |
| |
|
When an LSR supports "Liberal Label
Retention Mode", it maintains the binding between a label and a FEC
which are received from LSRs which are not its next hop for that
FEC (the label adjacency was already broken). When an LSR
supports "Conservative Label Retention Mode", it discards such
bindings. Liberal label retention mode allows for quicker
adaptation to routing changes (because the upstream LSR may
immediately begin using the binding again if the downstream LSR
eventually becomes its next hop for the FEC in question).
Conservative label retention mode instead requires an LSR to
maintain many fewer labels. |
| |
|
Important keywords to understand and remember |
| |
| |
LSR
upstream
downstream
(un) labeled packet
encapsulation header
encapsulated header
network layer header
LDP
Label distribution peers
Label distribution adjacency
Downstream-on-demand
Unsolicited downstream
Liberal Label Retention Mode
Conservative Label Retention Mode |
|
|
|
|
|
|
|
|
|
|
Previous
|
Content
|
Next
|
