RE: LCAS and GMPLS

- while the requirement for recursive association may/may not be interesting, from a VCAT point of view it is not needed (by ITU standards). All members of the VCAT group are defined as of one type "X".

- VCAT and LCAS have been defined specifically so as not to require transit node "awareness" or operational impacts.

- LCAS, itself, provides a mechanism for interworking LCAS-nonLCAS. And it will depend on the service if LCAS is appropriate. VCAT does not require LCAS.

- VCAT and LCAS can be used asymmetrically, VCAT can be unidirectional, though LCAS does require one "return" member.

Suggest first scoping to data plane requirements/terminology to avoid confusion with control plane requirements and also to allow liaisoning with ITU early in the development.

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Stephen Shew
Sent: Wednesday, June 15, 2005 1:17 PM
To: ccamp
Subject: RE: LCAS and GMPLS

> -----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.

> 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?