Please respond to "Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
To: "Stephen Shew" <sdshew@nortel.com>, "ccamp" <ccamp@ops.ietf.org>
cc:
Subject: Re: LCAS and GMPLS
[CUT]
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.
[dc] This sound strange to be because almost everything of what you can do with GMPLS can be done via NMS.
Circuit provisioning can be done via ENS so I'm sure I've got your point here.
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.
>