LSR
Click on the red underlined text to get to the source
...
LSR
A Label Switching Router ...
...
A Label Switching Router (LSR) is a device which implements the
label switching control and forwarding components described in
...
... A FR-LSR is an LSR with one or more LC-FR interfaces which
forwards frames between two such interfaces ...
... Frame
Relay, ATM, Generic) of a packet when that packet is received on
an LSR's interface, or the network layer ...
... Frame
Relay, ATM, Generic) of a packet when that packet is transmitted
on an LSR's interface, or the network layer ...
... MPLS TTL of the top of the stack when a
labeled packet is received on an LSR interface, or the network
...
... MPLS TTL of the top of the stack when a
labeled packet is transmitted on an LSR interface, or the network
...
... label switching architecture permits considerable
flexibility in LSR implementation, a FR-LSR is constrained by the
...
... flexibility in LSR implementation, a FR-LSR is constrained by the
capabilities of the (possibly pre-existing) hardware and the
...
... ARCH] for further details. In
a FR-LSR, the top (current) MPLS label is carried in the DLCI field
...
... different label stack encodings on different hops. When a labeled
packet is received, the LSR must decode it to determine the current
value of the label stack, then must operate on the label stack to
determine the new label value of the stack, and then encode the new
...
... Frame Relay switches operating as LSRs, and other LSRs, which operate
using other MPLS encapsulations ...
... encapsulation. In such networks there may be some
LSRs, which have Frame Relay interfaces as well as MPLS ...
... ("MPLS Shim") interfaces. This is one example of an LSR with
different label stack encodings on different hops of the same LSP ...
... label stack encodings on different hops of the same LSP.
Such an LSR may swap off a Frame Relay encoded label on an incoming
interface ...
... segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use
loop prevention mechanisms as described in [ARCH], and [LDP ...
... routers without having been label switched. If the
packet travels along a hierarchy of LSPs, the total number of LSR-
hops traversed should be reflected in its TTL value when it emerges
...
... LSP segment", it should however
reflect in the TTL the number of LSR-hops it traversed. In the
unicast case, this can be achieved by propagating a meaningful LSP ...
... Frame Relay segment length to the FR-LSR ingress nodes,
enabling the ingress to decrement the TTL value ...
... TTL LSP segment", the FR-LSR MUST not label switch
the packet, but rather follow the specifications in [STACK ...
... LSP segment length
is propagated to the FR-LSR egress node, enabling the egress to
decrement the TTL value ...
... Frame Relay
MPLS, referring to an LSR interface with the abbreviation "i" if the
input or output encapsulation ...
... Frame Relay, "a" when it is ATM, and furthermore considering
the symbols "iIf", "gGf", "fFf", etc... as LSRs with input,
forwarding and output encapsulations as referred above, the following
...
... n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR ...
... LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR" from Generic MPLS segment, and
...
... Frame Relay segment and calculates: mpls_ttl=n-6
"fGa" "egress LSR" from Frame Relay segment, and
...
... ATM segment and calculates: mpls_ttl=n-9
"gGf" is "egress LSR" from Generic MPLS segment, and
...
... Frame Relay segment and calculates: mpls_ttl=n-13
"fGg" is "egress LSR" from Frame Relay segment, and
...
... MPLS segment and calculates: mpls_ttl=n-14
"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
...
... TTL calculated at ingress
(ingress LSR) 1 2 3 4
x--->---+--->---+--->>--+-->>---x (egress LSR)
...
... hops 1|
|
x (ingress LSR)
o.ttl=i.ttl-3
...
... LSP
SHOULD pass meaningful information to the ingress FR-LSR regarding
the number of hops of the "non-TTL segment ...
... LSP SHOULD pass meaningful information to the
egress FR-LSR regarding the number of hops of the "non-TTL segment".
...
... Frame Relay LSP, the FR-LSR pops the label
stack [ARCH]. If the label popped is the last label, it is necessary
...
... the LSP SHOULD pass meaningful information to the egress FR-LSR
regarding the number of hops of the FR "non-TTL ...
... distribute label bindings. In these cases, a Frame Relay LSR should
participate in these protocols.
...
... transmitting, and congestion
control MAY be passed to the FR-LSRs through RSVP, or can be
statically configured. It is also assumed that congestion control ...
... congestion, would be
done by the FR-LSRs in a similar fashion as for traditional Frame
Relay circuits. With the goal of emulating a best-effort router ...
... allocation and maintenance mechanism discussed in this section MUST
be used by FR-LSRs that do not support VC merging, and it MAY also be
used by FR ...
... VC merging, and it MAY also be
used by FR-LSRs that do support VC merging (note that this mechanism
applies to hop-by-hop ...
... dge LSR Behavior ...
... Consider a member of the Edge Set of a FR-LSR domain. Assume that,
as a result of its routing ...
... as a result of its routing calculations, it selects a FR-LSR as the
next hop of a certain route ...
... Edge LSR receives in response from the downstream LSR the label
binding information in an LDP ...
... hop count" object, which
represents the number of hops a packet will take to cross the FR-LSR
domain to the Egress FR ...
... domain to the Egress FR-LSR when using this label. This information
may be stored for TTL calculation. Once this is done, the LSR ...
... LSR when using this label. This information
may be stored for TTL calculation. Once this is done, the LSR may
use MPLS forwarding to transmit packets in that FEC ...
... FEC, it means it is the
Egress-FR-LSR. It allocates a label, creates a new entry in its
Label Information Base ...
... In the "ordered control" mode [ARCH], the FR-LSR will wait for its
"request" to be responded from downstream with a "mapping" message
...
... ("ordered control" approach [ARCH]). In this case, the FR-LSR
increments the hop count it received from downstream ...
... FEC) from
the same FR-LSR. It must generate a new "mapping" for each "request"
(assuming adequate resources to do so), and retain any existing
mapping(s). For each "request" received, a FR ...
... (assuming adequate resources to do so), and retain any existing
mapping(s). For each "request" received, a FR-LSR should also
generate a new binding "request" toward the next hop ...
... particular label binding is
no longer needed, the LSR may deallocate the label associated with
the binding, and destroy the binding ...
... label retention mode" [ARCH]. In the case where a FR-LSR receives
such notification and destroys the binding ...
... route that the label binding is no longer needed. If a
LSR does not destroy the binding (the FR-LSR ...
... LSR does not destroy the binding (the FR-LSR is configured in
"liberal label retention mode" [ARCH]), it may re-use the binding ...
... point where the route diverges from the previous route. LSRs
upstream of that point are (with one exception, noted below)
...
... upstream of that point are (with one exception, noted below)
oblivious to the change. Whenever a LSR changes its next hop for a
particular route ...
... interface, then for each entry in its
LIB associated with the route the LSR should request (via LDP) a
binding ...
... binding request to its next hop
LSR as a result of receiving a label binding request from another
...
... binding request from another
(upstream) LSR, and the request to the next hop LSR is not satisfied,
...
... receiving label binding requests from the peer, the LSR may
destroy these bindings (and deallocate labels associated with
...
... The above discussion assumes that an edge LSR will request one label
for each prefix in its routing table ...
... next hop in the FR-
LSR domain. In fact, it is possible to significantly reduce the
number of labels needed by having the edge ...
... domain. In fact, it is possible to significantly reduce the
number of labels needed by having the edge LSR request instead one
label for several routes. Use of many-to-one mappings between routes
(address prefixes ...
... interleaved. If the
fragmenting FR-LSR ensures the transmission in sequence of all
fragments of a frame, without interleaving with fragments ...
... binding
request from an upstream LSR for a certain FEC, and it does already
have an outgoing label binding ...
... existing outgoing label for that FEC. If the FR-LSR does not have an
outgoing label binding for that FEC ...
... request for one, it need not issue another request. This means that
in a label conservation case, a FR-LSR must respond with a new
binding for every upstream ...
... from that of the old binding, the FR-LSR must process the new hop
count: increment by 1, if different than "unknown", and notify the
upstream ...
... DLCIs) that is
supported by the originating FR-LSR. The Minimum DLCI should be
right justified in this field and the preceding bits ...
... DLCIs) that is
supported by the originating FR-LSR. The Maximum DLCI should be
right justified in this field and the preceding bits ...
...
A FR-LSR that supports VC merging MUST ensure that fragmented
frames from distinct incoming DLCIs ...
... MPLS protocol has no mechanisms of its own to protect against
misdirection of packets or the impersonation of an LSR by accident or
malicious intent.
...