The MPLS WG Archive

["Prabakaran T Sampath" <prabakarts@future.futsoft.com>]

Hi Alok,

Yes, what ever you say is correct.  I meant for "n" no. of incoming
flows sending on the same outgoing interface with a single
label(we got to take care of all the h/w limitations, Traffic
engineering parameters if required like BW, cell interleave problem
in case of ATM, etc.,).  If your hardware supports LSP stitching
you can do so, but I guess, there is no Label merging concept
involved in LSP stitching.

In my understanding, a typical example for LSP stitching is,
when 2 LSPs fall in two different TED areas then we can stitch
the 2 different LSPs using cross-connect in the intermediate
router, so that from the ingress end if we do encapsulation,
we can do the decaptulation at the egress end.

For eg:
                                           |       |
        Traffic engineering domain 1       |       |         Traffic
engineering domain 2
                                           |       |
                 ----LSP 1-------------->  |       |----LSP 1--------->
        Router A ------------------------- Router B ------------------
Router C
                 ------Stitched LSP ---------------------------------->
                                           |       |
                                           |       |

In the above example, if we do not have LSP stitching means,
If we sending packet from Router A to Router C is encapsulated
on Router A (the ingress router for the first LSP), decapsulated
on Router B (the egress router), and then re-encapsulated on
Router B (the ingress router for the second LSP). With LSP stitching,
we connect LSP1 and LSP2 into a single, stitched LSP,
which means that the packet is encapsulated once (on Router A)
and decapsulated once (on Router C).

Juniper supports Circuit Cross Connections using which
you can stitch 2 LSPs. See more info at

https://www.juniper.net/techpubs/software/junos/junos57/swconfig57-mpls-apps
/html/ccc-tcc-config12.html

I hope this helps..!

Thanks and regards,
Prabakaran T.S.
Future Software Limited,
480-481, Anna Salai,
Chennai - 600035, India.
Web: www.futsoft.com
email: prabakarts@future.futsoft.com
Off Phone: 91-44-24330550 - Extn: 337
-------------------------------------


-----Original Message-----
From: Alok Dube [mailto:alokdube1978@rediffmail.com]
Sent: Tuesday, 2 September 2003 8:58 PM
To: Prabakaran T Sampath
Cc: bhavesh_modi@da-iict.org; mpls-ops@mplsrc.com
Subject: Re: RE: [MPLS-OPS]: Why Merging?



just a general question,


On Tue, 02 Sep 2003 Prabakaran T Sampath wrote :
>Hi Bhavesh Modi,
>
>Whether we are distributing same Labels or different Labels to
>its upstream
>LSRs,
>if the LSR is merge capable and if the outgoing interface is same
>for the
>upstream Labels(same or different) then as per RFC 3031, Section
>3.26 - we
>do merging (If there is any Hardware limitation exists then we
>got to
>consider that too while doing merging).


====> does this mean that where one can merge Labels (I assume you
mean no stacking but aggregating 10 flows into 1 flow kinds) one
can also "stitch LSPS?

-thanks
Alok

___________________________________________________
Medicine meets Marketing; Dr. Swati Weds Jayaram.
Rediff Matchmaker strikes another interesting match !!
Visit http://rediff.com/matchmaker?2



***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************