Re: LCAS and GMPLS

[Greg Bernstein <gregbern@yahoo.com>]

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.  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.
--> I hear now that Call_ID isn't appropriate (thanks
Jonathan and Hi!), but that there is an Association
object (thanks Adrian) of some sort that might be
appropriate.

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

(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").

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.

Greg B.

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