Re: LCAS and GMPLS

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Diego, Greg,
> Hi Adrian, not heavy at all. This helps me see what's
> up. Let me recast as informal requirements with
> justification and of course a bit of solution
> pondering.
>
> (1) I (as an individual) really want to be able to use
> GMPLS to set up disjointly routed components of a VCAT
> group.

Good. That is really clear.
This maps, I believe, into the need to be able to group together multiple
LSPs that support the same service.

>  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
b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.

On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.

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

I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt

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. This is relatively easy to perform if we have
to. I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.

> (3) LCAS can be used to delete disjointly routed
> components in a hitless fashion prior to removal of
> the component connection via GMPLS. Initiation of the
> LCAS "delete" procedure requires some type of
> management command. My requirement here would be to
> have a way to communicate via the end systems that I'm
> going to take down the connection and to have LCAS
> first do its hitless deletion.
> --> Now at the end that initiating the removal of the
> component alerting LCAS to "delete" shouldn't be a
> problem. Its the far end we'd want to communicated
> something to...  Now didn't we (way back) add
> something to RSVP GMPLS extensions to kind of anounce
> the release of the connection prior to tear down so
> that we could turn off SONET/SDH alarms (and couldn't
> we use that to trigger the "reverse LCAS delete").

Yes, indeed. We have "alarm free teardown" using the Administrative Status
object [RFC 3473]. And this could be used to trigger actions.

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!

> So Adrian, it seems like LCAS isn't so much as a GMPLS
> application but a helper application enabling the
> hitless addition and deletion of VCAT components.
> Also we may be very close to having all the facilities
> we need to automatically enable its "co-use" with
> GMPLS. Hence we could be talking about an "Application
> Note" rather than extension.  I need to review some of
> the ITU VCAT management models to make sure I haven't
> glossed over things too much.
> [dc] I agree that LCAS is an helper and we almost have all we
> need to use it via GMPLS.  We need to agree on how.

Yes. We seem to be in violent agreement that we need to end up with an
Applicability Statement.

We are making good progress on drilling down to the requirements (don't
throw away these emails, you will need them for you I-D!).

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?
b) Do the LCAS components converse through GMPLS signaling
   or by other (existing?) means?

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

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.

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.

Thanks,
Adrian


> --- Adrian Farrel <adrian@olddog.co.uk> 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
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news and more. Check it out!
> http://discover.yahoo.com/mobile.html
>
>
>
>
>
>
>
>
>