|
Previous
|
Content
|
Next
|
|
|
|
|
Label Merging is the capability of forwarding two different packets
belonging to the same FEC, but arriving with different labels,
with the same outgoing label. |
|
An LSR is label merging capable if it can receive two packets
from different incoming interfaces, and/or with different labels, and send
both packets out the same outpoing interface with the same label. Once
transmitted, the information that they arrive from different interfaces
and/or with different labels is lost. |
| An LSR is not merging label capable if, for any two packets
arriving from different interfaces and/or with different labels, the packets
must either be transmitted out using different interfaces, or having
different labels. ATM-LSRs using SVC or SVP encoding
are not label merging capable. In a not merging label capable LSR,
two packets in the same FEC arriving with different labels, must be
forwarded with different outgoing labels. With merging, the number of
outgoing labels per FEC need only to be 1; without merging, the number
of outgoing labels per FEC could be as large as the number of nodes
in the network. |
|
|
The MPLS architecture accommodate both merging and non-merging LSRs; this
lead to the issue of ensuring correct interoperation between merging and
non-merging LSRs. |
|
Non-merging LSRs |
| |
|
MPLS, ATM and FR use very similar forwarding
procedures. A unit of data arrives, a label (MPLS label or
ATM VPI/VCI or FR DLCI) is looked up in a "cross-connect table",
from where an output port is chosen and a new label value is rewritten.
Unfortunately, ATM and FR * do not necessarely support the
label merging capability. MPLS proposes two solutions to this
problem: |
| |
- MPLS will contain procedures which allow the use of
non-merging LSRs.
- MPLS will support procedures which allow the use certain
ATM switches to function as merging LSRs.
|
| * Problem with ATM & FR switches is that if one attempts to
perform label merging, the result may be the interleaving of cells from
various packets; then, it will be impossible to reassemble the packets. |
| |
|
Labels from Merging and Non-Merging LSRs |
| |
| An upstream LSR which support label merging needs to send only
one label per FEC. When it doesn't support merging, it needs to send
multiple labels per FEC. There is no way to know how many labels it
needs, because it depends on how many LSRs are upstream of it with
respect to the FEC in question. |
| |
| In the MPLS architecture, if a particular upstream LSR does
not support merging, then it has to ask to one downstream neighbor
explicitily for a label for that FEC. It can make multiple requests,
and a new label will be given each time. When a downstream LSR
receives such a request and it does not itself support merging, then it must
in turn ask its downstream neighbor for the label for the FEC
in question. |
| |
| If one LSR supports limited number of label merging
capability, then it may merge the incoming labels into two or more
outgoing labels. |
| |
|
Merge over ATM |
|
|
|
|
|
There are two methods to eliminate cell interleaving in ATM,
thereby allowing ATM switches to support stream merge: |
- VP merge, using the SVP Multipoint Encoding: with this,
multiple virtual path are merged into a single virtual path,
but packets from different sources are distinguished by using different
VCIs within the VP.
- VC merge: this case, switches are required to buffer calls from
one packet until the entire packet is received (by looking for the
AAL5 end of frame indicator).
|
|
VP merge has the advantage that it is compatible with a higher
percentage of existing ATM switch implementations; also, does not
incur in any delay at the merge points and does not impose any buffer
requeriment. However, it requires coordination of the VCI space
within each VP. |
|
MPLS protocol sopports both, VP and VC merge; then,
each ATM switch participating in MPLS needs to know whether
its immediate ATM neighbors perform VP merge, VC merge,
or no merge. |
|
Interoperation between merge nodes |
|
VC merge and non-merge: for this case, forwarding of cells is based
on a VC (concatenation of the VPI and VCI). If an
upstream neighbor is doing VC merge, it requires only a single
VPI/VCI for a particular stream. If an upstream neighbor is not
doing merge it will require a single VPI/VCI for stream for itself,
plus enough VPI/VCIs to pass to its upstream neighbors. |
|
VP merge and non-merge: The VP merge node, rather that
requesting a single VPI/VCI or a number of VPI/VCIs from its
downstream neighbor, it requests a single VP (identified by a
VPI) but several VCIs within the VP. If a non-merge
node is downstream from two different VP merge nodes, it may need
to request one VPI/VCI for its own traffic, plus two VPs (one
for each upstream node), each associated with a specified set of VCIs. |
|
Summarizing, to support merging, each VP merge node would request one
VP, with a contained VCI for traffic that it originates, plus
a VCI for each VC requested from above. VC merge node
would request only a single VCI/VPI, since they can merge all
upstream traffic into a single VCI. Non-merge node would pass
on any request that they get from above, plus requests a VPI/VCI for
traffic it originates. |
|
Important keywords to understand and remember |
| |
Label merging
Label merging capable
Not label merging capable
VP merge
VC merge |
|
|
|
|
|
|
|
Previous
|
Content
|
Next
|
