> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: Wednesday, June 15, 2005 08:22
> To: Shew, Stephen [CAR:QT30:EXCH]; ccamp
> 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.
Correct. What I mean precisely is that a GMPLS signaling application (something that knows to initiate/remove LSPs) would have understanding of LCAS and can trigger it. However, GMPLS signaling is not the means to carry 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.
Correct.
> 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.
Yes. Knowledge of whether LCAS capability is present or not only has to be known by something at the endpoint of an LSP. There may be need to exchange LCAS endpoint capability via GMPLS signaling but that is arguably an application level exchange. I'm not presuming that GMPLS signaling has to carry application level information.
> 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.
I think so too. As with LCAS knowledge, there may be other application level information that needs to be exchanged for VCAT, but again I'm not presuming that GMPLS signaling has to carry this.
> 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).
I think VCAT is special in that it involves an adaptation (actually two if you include GFP), which requires constituent LSPs to all be at the same layer. Other services that use multiple LSPs (e.g., 1:1 restoration) don't have an adaptation that is applied to the collective group of LSPs.
> All that remains is to pick a way of associating the LSPs.
> Will Session do, or do we need to use the Association object?
I'm not sure if the requirements are complete enough for me to have an opinion on the mechanism. A key point to decide is whether it needs to be known at a transit node that an LSP is part of an application that uses more than one LSP. If so, then we'd want this information to survive crossing domains and cases where LSPs are concatentated/stitched.
Another requirement to consider is whether the associating the LSPs needs to be recursive. For example, consider an STS-3c-2v where one of the STS-3c is a real contiguously concatenated LSP, and the other is actually an STS-1-3v (three STS-1 LSPs). From a bearer plane point of view, this is possible. Does the service maintain the two STS-3c LSP association and the three STS-1 LSP association?
I suggest that there be a requirement for recursive association.
Stephen