[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LCAS and GMPLS
Stephen,
A VCAT group is defined to contain only a single type of VC-n signals;
e.g. all VC-n signals in the group are VC-4 (STS-3c), or all signals in
the group or VC-3 (STS-1), or all signals in the group are VC-12 (VT-2) or
all signals in the group are VC-11 (VT-1.5).
A mixture of two or more VC-n types within one VCAT group is not defined.
Note that a VC-3-3v (STS-1-3v) is not the same as a VC-4 (STS-3c).
And a VC-4 (STS-3c) can not be carried over a VC-3-3v (STS-1-3v).
So the bearer plane doesn't support a VCAT group including one VC-4
(STS-3c) and 3 VC-3s (STS-1s), and the contorl plane (ASON/GMPLS) doesn't
need to take such undefined combinations into consideration.
Regards,
Maarten
"Stephen Shew" <sdshew@nortel.com>
Sent by: owner-ccamp@ops.ietf.org
15-06-2005 19:16
To: ccamp <ccamp@ops.ietf.org>
cc:
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.
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