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

["George Young" <[e-mail]>]

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?

Regards,
George.
edgeflow Inc.
329 March Rd., Kanata, ON, Canada, K2K 2E1
phone: [phone] Ext 287
fax: [phone]


>-----Original Message-----
>From: Jonathan Lang [mailto:[e-mail]]
>Sent: Wednesday, September 19, 2001 1:38 PM
>To: George Young; [e-mail]
>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:[e-mail]]
>> Sent: Wednesday, September 19, 2001 8:42 AM
>> To: Jonathan Lang; [e-mail]
>> 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: [phone] Ext 287
>> fax: [phone]
>> 
>> 
>> >-----Original Message-----
>> >From: Jonathan Lang [mailto:[e-mail]]
>> >Sent: Tuesday, September 18, 2001 12:24 PM
>> >To: George Young; [e-mail]
>> >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:[e-mail]]
>> >> Sent: Tuesday, September 18, 2001 6:05 AM
>> >> To: [e-mail]
>> >> 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: [phone] Ext 287
>> >> fax: [phone]
>> >> 
>> >> 
>> >> >-----Original Message-----
>> >> >From: George Young 
>> >> >Sent: Friday, September 07, 2001 3:47 PM
>> >> >To: [e-mail]
>> >> >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: [phone] Ext 287
>> >> >fax: [phone]
>> >> >
>> >> >
>> >> >
>> >> 
>> >
>> 
>