Re: LCAS and GMPLS

["Igor Bryskin" <ibryskin@movaz.com>]

Hi,

I'd like to put my 50c into this discussion.

1. I don't think that just using the same Session object for all VCAT
component LSPs will work. Why ? If you signal them with the SE reservation
style they will share resources on common links and you don't want this to
happen. If you signal them with the FF reservation style you will not be
able to do make-before-break.

2. Association object seems to be a good solution. Today we have the
Association object of two types:

a) Protection: allows to associate protecting and protected LSPs;
b) Resource sharing: allows to associate groups of LSPs with different
Session IDs, so that one can perform make-before-break procedures for entire
group.

You can put any number of Association objects into the same Path message.

I think for the purpose of VCAT we need to introduce an Association object
of the third type (let's call it VCAT Association object): generally
speaking, it will allow associating LSPs with different Sessions IDs that
are used as a single unit from the user perspective. My understanding is
that this object will be useful only on the egress of all of the
LPS-components: ingress node knows the association anyway, transit nodes do
not care (am I right ?). All LSP-components will have distinct Session IDs,
will be signaled with SE reservation style and include this new (identical)
Association object. This would allow managing each component individually
(including individual make-before-break operations). It will be also
possible to perform "global" make-before-break for entire VCAT group. This
could be easily achieved by signaling in each of new components an
Association object of Resource sharing type (in addition to Association
object of VCAT type) which will be a copy of Association object of VCAT type
of the existing group.

I guess I've lost everybody by now :=)

Igor

----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Stephen Shew" <sdshew@nortel.com>; "ccamp" <ccamp@ops.ietf.org>
Sent: Wednesday, June 15, 2005 8:22 AM
Subject: Re: LCAS and GMPLS


> Thanks Stephen,
>
> Helpful input.
>
> So if I read you right, GMPLS does not need to be aware of or help with
> LCAS signaling.
>
> This means that we do not need to worry about mechanisms for removing an
> LSP without disrupting the service, because LCAS will be used to negotiate
> the correct behavior at the end points before the LSP teardown is
> triggered.
>
> We still have the question about deciding whether LCAS is in use at all.
> But I assume that there are already mechanisms for handling this in the
> absence of GMPLS signaling (for example, in manually provisioned
> connections) so that extensions to GMPLS are also not required.
>
> I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to
> a way of identifying that a set of LSPs apply to a single VCAT group. As
> you point out, grouping of LSPs are needed for a variety of reasons when
> providing a service. Nothing special about VCAT here as far as I can tell
> (but it would be good to confirm that).
>
> All that remains is to pick a way of associating the LSPs. Will Session
> do, or do we need to use the Association object?
>
> Cheers,
> Adrian
>
>
> ----- Original Message ----- 
> From: "Stephen Shew" <sdshew@nortel.com>
> To: "ccamp" <ccamp@ops.ietf.org>
> Sent: Tuesday, June 14, 2005 10:10 PM
> Subject: RE: LCAS and GMPLS
>
>
> > In considering the use of LCAS, it is important to note that there are
> > separate requirements here:
> > 1. Having multiple LSPs participate in a single service.   This is not
> just
> > limited to virtual concatenation but is also useful for 1:1 and other
> > restoration mechanisms.
> >
> > 2. If LSPs can be added/removed from a common service after they have
> been
> > set up.
> >
> > 3. What effects LSP addition/removal are allowed to have on the common
> > service.
> >
> > Putting these together, one could envision a requirement to offer a
> service
> > whose bandwidth requirements are met with a service in a transport
> network
> > that uses multiple LSPs for bandwidth efficiency.  Further this service
> > allows changes to be signalled and the bandwidth change is to be
> > non-disruptive.
> >
> > Mechanisms to accomplish such a service could consist of VCAT and LCAS.
> > Note that LCAS has its own "in-band" signalling.  I think that the
> service
> > associated with the VCAT adaptation is the one that should be LCAS
> aware,
> > not the individual LSPs.
> >
> > Stephen
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, June 14, 2005 14:48
> > > To: Greg Bernstein <gregbern; Diego Caviglia
> > > Cc: yhwkim; ccamp
> > > Subject: Re: LCAS and GMPLS
> > >
> > <snip>
> >
> > > Nevertheless, before completing on the solutions discussion,
> > > we still have to sort out the issues above. I am most
> > > concerned about the "layering" issue. That is:
> > > a) Is the LCAS component on the egress started by management,
> > >    by a trigger in some communication between LCAS components,
> > >    or by a trigger in GMPLS signaling?
> > > b) Do the LCAS components converse through GMPLS signaling
> > >    or by other (existing?) means?
> > >
> > > > [dc] My initial idea was to use Call_ID to identify the LSP that are
> > > part of the
> > > > same VCAT/LCAS set and a bit in the profile filed to inform
> > > the other
> > > and
> > > > that LCAS protcol has bo enabled.
> > >
> > > Understood. I think we have moved on a little from that
> > > suggestion. Presumably you will not be unhappy with any
> > > solution that is functional and not over-complex.
> > >
> > > I would suggest that Greg and Diego start an I-D. Call it
> > > something like "Applicability Statement for Operating LCAS
> > > and VCAT with GMPLS LSPs".
> > > Include:
> > > - Simple overview of VCAT and LCAS (no more than a page, please)
> > > - Simple statement of how LSPs fit into the picture (about
> > > half a page)
> > > - Statement of the requirements on GMPLS signaling (about a page)
> > > - Mechanisms and procedures (two or three pages)
> > >
> > > It may be that we need to define a new bit somewhere in which
> > > case we will drop "Applicability Statement for" from the name
> > > of the I-D.
> > >
> > > I would be very happy to discuss the solutions component with
> > > you before publication so that we avoid thrashing.
> > >
> > >
> > > Anyone who is interested in this topic should contact Diego
> > > and Greg to offer help.
> >
>
>