Subject: RE: LCAS and GMPLS

From: "Stephen Shew" <[email-masked]>
Date: Wed, 15 Jun 2005 13:16:59 -0400

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> 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

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 15 Jun 2005 13:37:07 -0400

RE: LCAS and GMPLSStephen,

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

  IB>> This is an interesting requirement. Fortunately, it is possible to realize this requirement via GMPLS signaling by including several ASSOCIATION objects of the same type into the same Path message. For instance, one of them will indicate that the signalled LSP belongs to the nested VCAT group, while another -to the nesting VCAT group.

  Cheers,

  Igor

  Stephen

---

From: Wataru Imajuku <[email-masked]>
Date: Thu, 16 Jun 2005 06:18:22 +0900

Hi, Stephen

>Stephen,
>
>
> > 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?
>IB>> This is an interesting requirement. Fortunately, it is possible to 
>realize this requirement via GMPLS signaling by including several 
>ASSOCIATION objects of the same type into the same Path message. For 
>instance, one of them will indicate that the signalled LSP belongs to the 
>nested VCAT group, while another -to the nesting VCAT group.

  Current ASSOCIATION objects relates only two connections.
  I think that introducing the concept of virtual connection indicating 
the group of VCAT is good idea.
  Use of Call ID object （assigning VCAT Group) and Assosiation object
(indicating VCAT group in Call ID) may be one of solution.

Best Regards,
Wataru

---------------------------------
Wataru Imajuku
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Jun 2005 23:32:13 +0100

Hi Wataru,

> Current ASSOCIATION objects relates only two connections.

Can you say why you think this is so?
Looking at draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt I do not
see anything that forces this limitation. In fact, it would be hard to
offer 1:n protection with such a scheme.

Thanks,
Adrian

---

From: [email-masked]
Date: Thu, 16 Jun 2005 10:25:26 +0200

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" <[email-masked]>
Sent by: [email-masked]
15-06-2005 19:16
 
        To:     ccamp <[email-masked]>
        cc: 
        Subject:        RE: LCAS and GMPLS

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

---

From: Wataru Imajuku <[email-masked]>
Date: Fri, 17 Jun 2005 09:35:40 +0900

Hi, Adrian

>offer 1:n protection with such a scheme.

  In my understanding, the ASSOCIATION ID of ASSOCIATION Object only 
relates protected LSP and protecting LSPs.
  It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.

  Now, consider the LCAS.
  Does the LCAS define or have primary connetion ?
  I think all of conections in LCAS should be equivalent.

Wataru

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Jun 2005 11:34:44 +0100

Hi again Wataru,

> > > >instance, one of them will indicate that the signalled LSP belongs
to
> > > >the nested VCAT group, while another -to the nesting VCAT group.
> > >

Then I am sorry to say that your understanding is wrong.

The Association object is used to associate LSPs.
Clearly, in its use in a protection ID it describes the association for
the purposes of protection. However, the text is carefully worded to
ensure that the object is more widely applicable.
To quote from section 16...
   The ASSOCIATION object is used to associate LSPs with each other.

You originally said...
> > > Current ASSOCIATION objects relates only two connections.
...but you now seem to accept that the Association object can relate more
than one LSP since you say...
> It's OK adoptation of ASSOCIATION Object and ID for 1:n protection.

Thus, I presume that you accept that the Association object could handle
VCAT groups with more than two LSPs.

>   I think all of conections in LCAS should be equivalent.

Why is primary conneciton valid? LCAS has nothing to do with protection.
The Association object provides an *arbitrary* association ID that is
common across all LSPs in the same group, and unique within the context of
the association source. There is no concept of a primary connection in the
process of association.

I hope this clarifies that the Association object is suitable for
identifying the LSPs in VCAT groups. (Pending the documentation of the
real requirements.)

Thanks,
Adrian

---

From: Wataru Imajuku <[email-masked]>
Date: Mon, 20 Jun 2005 09:52:41 +0900

Hi, Adrian

  Thank you for your comment.
  I should have explain my thought more in detail.

>VCAT groups with more than two LSPs.

  Yes.
  In the case of 1:n protection scheme, all of n back up paths set the 
primary LSP ID
for their Association IDs.  It seems OK the use of association ID.

>the association source. There is no concept of a primary connection in the

  But, my concern is the value of Association ID in VCAT.
  Different from 1:n protection, generic VCAT group does not have primary 
connection.
  In the case of 1:n protection, we define "primary" connection.

  But, in the case of generic VCAT, the Association ID of second and third 
connection
should be first connection of LSP ID ?
  My answer is no.

  The first connection in VCAT group can be torn down before the tear down 
of secondary or third connection.
  If the second and third connection use LSP ID of first connection for 
their Association ID,
the second and third connection of the VCAT group use non-existing LSP ID 
for their Association ID
in some state.
  Do we accept this kind of state ?

Thanks,
Wataru

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Jun 2005 14:19:59 +0100

>   In the case of 1:n protection, we define "primary" connection.

Wataru,

draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt introduces the
Association object and describes its use for protection. It is not
surprising that it does not include its use for VCAT. We need to define
that use now.

When draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt says to use an
LSP-ID in the Association ID field, it is describing how you associate
LSPs for protection.

We need to write down how to use the Association ID for VCAT grouping.
That is, we must explain that the Association ID value should be an
arbitrary value unique within the scope of the Association Sourse address
and common to all members of the group.

> connection should be first connection of LSP ID ?
>   My answer is no.

The only person to suggest doing this is you. Everyone agrees with you
that the answer is no.

>   their Association ID, the second and third connection of the VCAT
group
>   use non-existing LSP ID for their Association ID in some state.

No, we don't. And we do not suggest it.

Adrian