Subject: RE: LCAS and GMPLS

From: 김영화 <[email-masked]>
Date: Wed, 1 Jun 2005 09:39:07 +0900

Hi,

Thank you that you remind me the contribution.

Maybe I think that the contribution was submitted to the Seoul meeting.

My contribution (draft-kim-ccamp-intercaction-grsvpte-lcas) didn't get a chance to present at that time.

It is completely said that LCAS is controled by EMS. But, my contribution was written down to reduce the EMS overhead.

Could you happen to tell me your interesting points about my contribution ?

ASAP, I'd like to modify and re-submit the contribution after adding your comments.

-----원본 메시지-----
보낸 사람: "Diego Caviglia" <[email-masked]>
보낸 날짜: 2005-05-31 오후 10:45:11
받는 사람: "[email-masked]" <[email-masked]>
참조:
제목: LCAS and GMPLS

Hi all,
I'd like to ask what is the statuts of the interworking between
LCAS and GMPLS.  Surfing the net I've found a couple of ID about that
subject (draft-kim-ccamp-intercaction-grsvpte-lcas and
draft-mannie-ccamp-gmpls-tdm-lbm) but both of them seems to be expired,
I've also found some interesting discussion on this matter on the ccamp
mail archive.

Is interwoking between LCAS and GMPLS outside the scope of CCAMP?

IMHO that is not and should be addressed.

What is the feeling of the rest of the group?

Best regards

Diego

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 10 Jun 2005 08:37:00 -0700 (PDT)

Hi Diego et. al. agree that this is part of the
important topic on control of VCAT groups but I can't
remember why this didn't go further.  Is the
identification of separately routed VCAT components
resolved? I.e., those belonging to the same group but
disjointly routed. (We needed an identifier for the
VCAT group somewhere in the signaling message).

Adrian or Lyndon do you recall?

Greg B.

> What is the feeling of the rest of the group?

__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 14 Jun 2005 23:50:05 -0400

Hi Adrian,

Just a couple of comments:

---------------------------------------------

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of
the ITU-T (probably Study Group 15) and not here. A consequence of the
use of the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function

[LYO] This is not necessary, IMHO, the Call_ID is really part of
G.7713.2, 
which could be used as UNI or E-NNI.

--------------------------------------

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS. This is relatively easy to perform if we have
to. I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

[LYO] This seems like a useful addition, also information such as the
initial
size of the LCAS group, as this is not immediately obvious unless you
can
guarantee that setup of the group members is always done in correct
sequence.

-------------------------------------------------------

But as with the previous question, I wonder whether you really want to
use GMPLS signaling to carry LCAS commands, or whether you want to run
LCAS between the end points and have them trigger GMPLS. I suspect that
Neil would say that this is a layering question!

[LYO] I don't think you actually need to use GMPLS to carry LCAS
commands,
since these will already be carried in the overhead.   

Cheers,

Lyndon

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 15 Jun 2005 10:23:53 +0200

Hi Adrian,
                  please find my comments in line.

I cut the agreed part.

Regards

Diego

Please respond to "Adrian Farrel" <[email-masked]>
Sent by:        [email-masked]
To:     "Greg Bernstein <gregbern", "Diego Caviglia" <[email-masked]>
cc:     "yhwkim" <[email-masked]>, "ccamp" <[email-masked]> 

Subject:        Re: LCAS and GMPLS

Hi Diego, Greg,
[CUT]
>  Why?  (a) To more be able to full "extract
> bandwidth from a mesh" via inverse multiplexing. (b)
> To provide for graceful degradation in the case of
> failure, e.g., one of the disjointly routed components
> fails.
> [dc] Agreed

> --> I hear now that Call_ID isn't appropriate (thanks
> Jonathan and Hi!),
> [dc] This is not clear to me, so what is supposed to be the purpose of
the
> Call_ID? Can someone clarify this better?

I, too, think that the Call_ID object (RFC3474) is not appropriate for
this task.

RFC3474 is informational. It documents code point assignments for the
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the
UNI and E-NNI reference points.

If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of the
ITU-T (probably Study Group 15) and not here. A consequence of the use of
the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function
[dc] Actually you can use Call_Id also for SPC circuits, usage of Call_Id 
is not restricted to to UNI.

b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.
[dc] My view of the Call concept is something that bundle a set of 
connections (LSPs) into a service. This seems to fit to the VCAT/LCAS 
scenario.

On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.
[dc] Ok I see your point, and even if for me the Call_ID is a good choice 
for this job, I don't want to start an holy war for this.

> but that there is an Association object (thanks Adrian) of
> some sort that might be appropriate.
> [dc] hmmm I need some time to read the RFC 2746 at a first glance seems
> that the RFC address different problems.

Whoah Diego, I don't mean the Session_Association object of RFC 2746. That
mechanism is applicable to RSVP over tunnels and is, I think, not relevant
here.
[dc] ah ah ah ah this is very funny I've looked to the IANA and I've find 
that object. 

I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
[dc] Ok this sounds more in the scope of the discussion ;-)

In order to solve the problem at hand (which seems quite simply to be that
we wish to be able to associate two or more LSPs that have the same
ingress and egress) we need first to answer the question: why is it not
enough to rely on the fact that the LSPs all come from the same Session?

In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a
requirement to associate a subset of the LSPs that support a service by
coming from the same Session. This is so that a service may be supported
by more than one working LSP, and each working LSP may be protected by one
or more backup LSPs. The association is between a working LSP and its
backups.

But, for your requirement, it may be enough simply to use the Session to
identify all of the LSPs in the same VCAT group. if it is not enough, then
the Association object gives you the function you need.

> (2) LCAS can be used to add disjointly routed
> components to a group in a hitless fashion after it
> has been set up via GMPLS.  Initiation of the LCAS
> "add" procedure requires some type of management
> command.
> --> I'm not sure if I have a requirement here since I
> could default my end system behavior to automatically
> issue the "add" LCAS commands from both ends after the
> GMPLS procedure completes.  Diego or Jonathan, are
> their other situations where this wouldn't be
> appropriate?
> [dc] Yes but how you know that you have to enable LCAS?
> The LSP could be part of a 'simple' VCAT.

I'm also not sure that there is a GMPLS requirement here.
How do you know to use LCAS in management-established LSPs? Or any other
type of connection? Seems like this is a generic LCAS propblem.

So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS.
[dc] Yes that was what I meant.

This is relatively easy to perform if we have to.
I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

[CUT]

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?
[dc] I would like to triger it via GMPLS signalling.

b) Do the LCAS components converse through GMPLS signaling
   or by other (existing?) means?
[dc] Hmmm not sure that LCAS needs to be aware of the GMPLS.

> [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.
[dc] Yes you are right.

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.
[dc] Ok no problem for me.  May I ask to Greg to be the editor of this? 
For sure his english is better than mine.  I promise that next time we 
have to write a doc in Italian I'll be the editor ;-)

I would be very happy to discuss the solutions component with you before
publication so that we avoid thrashing.
[dc] Of course will be a pleasure, as usual, to discuss this with you.

Anyone who is interested in this topic should contact Diego and Greg to
offer help.

Thanks,
Adrian

> --- Adrian Farrel <[email-masked]> wrote:
>
> > Hi Greg,
> >
> > Let me come in a bit heavy here, please.
> >
> >
> > > Hi all, thanks for the update Diego and Adrian.
> > Where
> > > we stand seems to be:
> > > (1) We've got an agreed method using the Call_ID
> > to
> > > identify (VC-3/VC-4) component belonging to a VCAT
> > > group. In particular, the Call_ID along with
> > source
> > > and destination addresses uniquely identifies the
> > VCAT
> > > group in the network?
> >
> > No. We do not have agreement on this.
> > We have a vague statement of requirements that a
> > group of LSPs need to be
> > associated. Until we see the requirements fleshed
> > out and written up it
> > would be wrong to pick one solution. For example, we
> > have an Association
> > object that is part of mainstream GMPLS that could
> > be used for this
> > purpose.
> >
> > So, let's see the requirements written up, please.
> >
> > > (2) I can use GMPLS to setup/tear down one or more
> > > VCAT group components at a time. (we've had this
> > for a
> > > while).
> > > (3) Once we set up via GMPLS a new component
> > > (VC-3/VC-4) of a VCAT group we want LCAS to
> > hitlessly
> > > add the new component to the group.
> > > (4) To remove (hitlessly) the component from the
> > VCAT
> > > group we need  LCAS to remove it before we
> > actually
> > > tear down the component connection via GMPLS.
> >
> > So it seems to me that you have decided that LCAS is
> > a GMPLS application.
> > That is, LCAS is an end-to-end protocol that
> > triggers the establishment of
> > LSPs by making requests to GMPLS.
> >
> > This sounds reasonable, but please write it up.
> >
> > > Now the thing that seems a bit tricky to me about
> > (3)
> > > and (4) is that LCAS does things unidirectionally,
> > in
> > > the sense of adding/removing components, (not in
> > the
> > > sense of a protocol which has a handshake
> > mechanism).
> > > All add or remove commands come from the source
> > end
> > > and since we generally setup/teardown
> > bi-directional
> > > connections that would leave us with a bit of
> > > coordination.  Is this what you are thinking
> > Diego?
> > > LCAS experts chime in too :-)
> >
> > Nothing to stop you having unidirectional LSPs if
> > you need to support a
> > service that controls LSPs in a unidirectional way.
> >
> > Cheers,
> > Adrian
> >
> >
>
>
>
>
> Get on-the-go sports scores, stock quotes, news and more. Check it out!
> http://discover.yahoo.com/mobile.html
>
>
>
>
>
>
>
>
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 15 Jun 2005 10:36:50 +0200

Hi Stephen,
                    good to hear you on this.

I agree on all of your points.

Regards

Diego

Sent by:        [email-masked]
To:     ccamp <[email-masked]>
cc: 

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel 
> Sent: Tuesday, June 14, 2005 14:48 
> To: Greg Bernstein <gregbern; Diego Caviglia 
> Cc: yhwkim; ccamp 
<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: 
> 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: 
> 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.

---

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 15 Jun 2005 14:42:12 +0200

Adrian,
              some comments in line.

Regards

Diego

Please respond to "Adrian Farrel" <[email-masked]>
Sent by:        [email-masked]
To:     "Stephen Shew" <[email-masked]>, "ccamp" <[email-masked]>
cc: 

[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" <[email-masked]>
To: "ccamp" <[email-masked]>
Sent: Tuesday, June 14, 2005 10:10 PM
Subject: RE: LCAS and GMPLS

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

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 15 Jun 2005 15:34:26 -0500

Couple of comments:
- 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. 
 
Deborah

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Shew
Sent: Wednesday, June 15, 2005 1:17 PM
To: ccamp
Subject: RE: LCAS and GMPLS

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Wednesday, June 15, 2005 08:22 
> To: Shew, Stephen [CAR:QT30:EXCH]; ccamp 
> 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 

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: "Diego Caviglia" <[email-masked]>
Date: Mon, 20 Jun 2005 15:26:31 +0200

Adrian,

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

Yes this is also my view.  That is consistent with ITU-T Call_ID (sorry for
quoting again ITU-T here ;-))

Regards

Diego

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 20 Jun 2005 15:28:37 +0200

Hi Adrian,
           again agreed.

Diego

"Adrian Farrel" <[email-masked]> on 20/06/2005 15.25.06

To:    "Wataru Imajuku <imajuku.wataru", "Diego Caviglia"
       <[email-masked]>
cc:    "ccamp  <ccamp"

Hi Diego,

> If I've correctly understood the ASSOCIATION obj it should work in the
> same way as the Call_ID (operator spec) obj.

If you MUST make the comparison :-)

> Wataru if you're familiar with ITU I'll try to make a corrispondence
> between the two objects.
> The corrispondeces are the following:
> Call_ID (RCF 3473)    ASSOCIATION
(draft-ietf-ccamp-gmpls-recovery-e2e-signaling)
> Source LSR Address <--> IPv4 Association Source
> Type 1 = 4 bytes        Type 1 = 4 bytes
> Type 2 = 16 bytes       Type 2 = 16 bytes
> Type 3 = 30 bytes       na
> Type 4 = 6 bytes        na
>
> Local Identifier   <--> Association ID
> 8 bytes                 2 bytes
>
> So apart from the maximum number of associations/Calls that a source can
> originate seems to me that the two objects solve well the problem.
>
> IMHO Call_ID is better but I'm not going to stress this point, if the
> feeling of the group is to use ASSOCIATION obj for me it is fine.
So, something that might be useful would be if the requirements I-D made
some statement about the number of VCAT groups likely to be originated by a
single sender.

It is my *guess* that the number of such groups is likely to be smaller
than the number of LSPs associated by the same sender. Thus, the size of
the group ID does not need to be larger than the size of the LSP-ID.

If there is a need to overload the semanitc of the group ID for correlation
with LCAS or something, then we should discuss the point, but so far we
have only discussed it in the context of grouping together a set of LSPs.

Cheers,
Adrian