RE: Question: purpose of LMP ChannelActive message (was relations hip of RSVP-TE and LMP)

Jonathan Lang <jplang@calient.net> Tue, 25 September 2001 16:07 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 25 Sep 2001 09:29:15 -0700
Message-ID: <C12BBE1C7A8F7344808CD8C2A345DFB8455779@pulsar.chromisys.com>
From: Jonathan Lang <jplang@calient.net>
To: 'George Young' <george.young@edgeflow.com>
Cc: ccamp@ops.ietf.org
Subject: RE: Question: purpose of LMP ChannelActive message (was relations hip of RSVP-TE and LMP)
Date: Tue, 25 Sep 2001 09:07:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

George,
 Sorry for the delayed response.  Please see inline.

Thanks,
Jonathan

> -----Original Message-----
> From: George Young [mailto:george.young@edgeflow.com]
> Sent: Thursday, September 20, 2001 5:52 AM
> To: Jonathan Lang
> Cc: ccamp@ops.ietf.org
> Subject: RE: Question: purpose of LMP ChannelActive message (was
> relationship of RSVP-TE and LMP)
> 
> 
> Hello Jonathan,
> 
> Thanks again for the clarification. There's something that still
> troubles me.
> 
> I can see that if there's signalling involved (e.g. RSVP), then the
> signalling  indicates whether monitoring is necessary along the path
> (e.g. with  a couple of bits in the Admin Status object) and the LMP
> ChannelActive message is superfluous.
> 
> If there's no signalling involved, then the LMP ChannelActive message
> could be used to indicate monitoring should take place (e.g. for span
> protection). The trouble is that when monitoring finds that a channel
> has failed and sends a ChannelFail message, the transmit end knows to
> switch over, but without the ChannelFailNack message, the receive end of
> the link doesn't know to switch over.
> 
> Am I missing something here?
One thing we're doing for the next rev of LMP is combining the ChannelFail,
ChannelActive, ChannelDeactive messages into a single ChannelStatus message
(as discussed in LMP-WDM).  With this in place, you could send a
ChannelStatus (fail) message to indicate the failure.

> 
> Regards,
> George.
> edgeflow Inc.
> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> phone: +1 613-270-9279 Ext 287
> fax: +1 613-270-9268
> 
> 
> >-----Original Message-----
> >From: Jonathan Lang [mailto:jplang@calient.net]
> >Sent: Wednesday, September 19, 2001 1:38 PM
> >To: George Young; ccamp@ops.ietf.org
> >Subject: RE: Question: purpose of LMP ChannelActive message (was
> >relationship of RSVP-TE and LMP)
> >
> >
> >George,
> >  see inline.
> >
> >Thanks,
> >Jonathan
> >
> >> -----Original Message-----
> >> From: George Young [mailto:george.young@edgeflow.com]
> >> Sent: Wednesday, September 19, 2001 8:42 AM
> >> To: Jonathan Lang; ccamp@ops.ietf.org
> >> Subject: RE: Question: purpose of LMP ChannelActive message (was
> >> relationship of RSVP-TE and LMP)
> >> 
> >> 
> >> Thanks for the clarification, Jonathan.
> >> 
> >> To see if I understand, the active call and the backup call are
> >> separately established by something like RSVP-TE. These 
> two calls are
> >> established by PATH going from head to tail, RESV going 
> from tail to
> >> head. Then for the active call ONLY, the head sends a ChannelActive
> >> which propagates to the tail, and then the tail sends a 
> ChannelActive
> >> which propagates to the head.
> >> 
> >> When failure is noted by monitoring the active call, the 
> head and the
> >> tail of the call are notified, and each switches over to the backup
> >> call. The head sends a ChannelActive message downstream 
> and the tail
> >> sends a ChannelActive message upstream, and they're each 
> >propagated to
> >> the other end.
> >> 
> >> Right?
> >not quite right.  I think you're confusing the ChannelActive 
> >message with
> >the Administrative Status object in GMPLS.  The ChannelActive 
> >message is
> >used between a pair of nodes to indicate that the data channel 
> >is now active
> >and should be monitored.  This is useful for span level protection or
> >between devices where GMPLS signaling (RSVP) isn't used.
> >
> >> 
> >> Regards,
> >> George.
> >> edgeflow Inc.
> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> phone: +1 613-270-9279 Ext 287
> >> fax: +1 613-270-9268
> >> 
> >> 
> >> >-----Original Message-----
> >> >From: Jonathan Lang [mailto:jplang@calient.net]
> >> >Sent: Tuesday, September 18, 2001 12:24 PM
> >> >To: George Young; ccamp@ops.ietf.org
> >> >Subject: RE: Question: purpose of LMP ChannelActive message (was
> >> >relationship of RSVP-TE and LMP)
> >> >
> >> >
> >> >George,
> >> >  Sorry, I missed this one.  See inline.
> >> >
> >> >-Jonathan
> >> >
> >> >> -----Original Message-----
> >> >> From: George Young [mailto:george.young@edgeflow.com]
> >> >> Sent: Tuesday, September 18, 2001 6:05 AM
> >> >> To: ccamp@ops.ietf.org
> >> >> Subject: Question: purpose of LMP ChannelActive message (was
> >> >> relationship of RSVP-TE and LMP)
> >> >> 
> >> >> 
> >> >> Didn't see any answers to this question, so I'll try to 
> >> rephrase and
> >> >> make it more focused.
> >> >> 
> >> >> What is the purpose of the LMP ChannelActive message?
> >> >The ChannelActive message is used to indicate that the channel 
> >> >status is
> >> >active and should be monitored.
> >> >
> >> >> 
> >> >> I'm assuming a call is set up through an optical cross 
> >> connect (OXC),
> >> >> either in response to control plane signalling (e.g. 
> RSVP-TE) or 
> >> >> management plane input.
> >> >> The OXC has knowledge of which optical links are involved 
> >> >> with the call for failure monitoring purposes.
> >> >> 
> >> >> What additional information would the receipt of a 
> >> >> ChannelActive message convey?
> >> >This is useful when paths are pre-established (e.g., for path 
> >> >protection).
> >> >Although signaling is used to setup the resource reservation, 
> >> >on switchover
> >> >you need a mechanism to trigger monitoring of the data channel.
> >> >
> >> >> 
> >> >> Regards,
> >> >> George.
> >> >> edgeflow Inc.
> >> >> 329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> >> phone: +1 613-270-9279 Ext 287
> >> >> fax: +1 613-270-9268
> >> >> 
> >> >> 
> >> >> >-----Original Message-----
> >> >> >From: George Young 
> >> >> >Sent: Friday, September 07, 2001 3:47 PM
> >> >> >To: ccamp@ops.ietf.org
> >> >> >Subject: relationship of RSVP-TE and LMP
> >> >> >
> >> >> >
> >> >> >I have two questions about the relationship of RSVP-TE
> >> >> >(draft-ietf-mpls-generalized-rsvp-te-03.txt) and LMP
> >> >> >(draft-ietf-ccamp-lmp-00.txt).
> >> >> >
> >> >> >First of all, my understanding of the LMP ChannelActive 
> >> >> message is that
> >> >> >it is used to indicate to the downstream (relative to data flow
> >> >> >direction) node that monitoring should be used.
> >> >> >
> >> >> >The scenario I have in mind is an RSVP call setup 
> consisting of a
> >> >> >bidirectional optical path.  Presumably a switching node has 
> >> >> to reserve
> >> >> >data channels and associate them with the optical path when an 
> >> >> >RSVP PATH
> >> >> >message arrives.
> >> >> >
> >> >> >1) My first question is what is the timing of LMP 
> >> >> >ChannelActive messages
> >> >> >relative to RSVP messages.
> >> >> >
> >> >> >Do ChannelActive messages flow downstream (relative to call
> >> >> >establishment direction) more-or-less in phase with PATH 
> >> >> messages, and
> >> >> >upstream (relative to call establishment direction) 
> >> more-or-less in
> >> >> >phase with RESV messages?
> >> >> >
> >> >> >2) My second question is what addtional information 
> >information do
> >> >> >ChannelActive messages provide?
> >> >> >
> >> >> >If a link is to be monitored when associated with an 
> >> active call, it
> >> >> >appears the node already has this information.
> >> >> >
> >> >> >Regards,
> >> >> >George.
> >> >> >edgeflow Inc.
> >> >> >329 March Rd., Kanata, ON, Canada, K2K 2E1
> >> >> >phone: +1 613-270-9279 Ext 287
> >> >> >fax: +1 613-270-9268
> >> >> >
> >> >> >
> >> >> >
> >> >> 
> >> >
> >> 
> >
>