Subject: [Capwap] 回复:Re: Keepalive on data channel

From: zhaoyujin 31390 <[email-masked]>
Date: Wed, 05 Jul 2006 20:01:35 +0500

Dear all:

  Frankly, I think if data tunnel need keepalive should be discussed.
  
  Normally, our Capwap data tunnel will be controlled to create or delete by control tunnel, so that data tunnel keepalive may be repeated. And this will affect the performance of data transmission.

  But for NAT Traversal, maybe CAPWAP can send one no-used packet to maintain the NAT entry for capwap data tunnel. But before this, capwap need decide which device is inside of NAT with control tunnel.

Best regards
Michael

----- 原邮件 -----
发件人: "Mani, Mahalingam (Mani)" <[email-masked]>
日期: 星期三, 六月 28日, 2006 上午10:02
主题: Re: [Capwap] Keepalive on data channel

> Pat,
> 
> The relevance of the 'Then' preceding the recommendation is not clear.
> 
> This is merely an observation of the implication of the behavior 
> on this
> given network policy instance. We expect the relevant areas to respond
> when ADs take this up with them.
> 
> -mani
> -----Original Message-----
> From: Pat Calhoun (pacalhou) [[email-masked]] 
> Sent: Monday, June 26, 2006 6:27 PM
> To: Mani, Mahalingam (Mani); [email-masked]
> Subject: RE: [Capwap] Keepalive on data channel
> 
> Mani,
> 
> Then I would recommend that you include folks from the Internet 
> Area in
> your discussions, as they have a number of tunneling standards efforts
> underway, as well as operational experience.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
> 
> 
> > -----Original Message-----
> > From: Mani, Mahalingam (Mani) [[email-masked]] 
> > Sent: Monday, June 26, 2006 5:22 PM
> > To: Pat Calhoun (pacalhou); [email-masked]
> > Subject: RE: [Capwap] Keepalive on data channel
> > 
> > It appears that in such a network - all flows marked for DSCP 
> > -based QoS are at a diagnostic peril - each of a different 
> > kind - in such a failure scenario.
> > 
> > -mani
> > -----Original Message-----
> > From: Pat Calhoun (pacalhou) [[email-masked]]
> > Sent: Monday, June 26, 2006 7:09 AM
> > To: [email-masked]
> > Subject: [Capwap] Keepalive on data channel
> > 
> > All,
> >  
> > In a conversation with some of the L2TP folks, they have 
> > experience an operational problem that we need to keep in 
> > mind. Basically, they multiplex their control and data frames 
> > through their own header, and mark their packets priorities 
> > based on control vs. data.
> > 
> > What they have found is that networks do route path selection 
> > based on DSCP/ToS values, meaning that they send higher 
> > priority (control) frames over different links than data 
> > frames. The network is not designed to perform this solely 
> > for L2TP, as this is something they do for all of their 
> > applications. The issue is that their protocol relies on a 
> > keepalive frame that runs over the control channel, 
> > identically to CAPWAP. However, the operational issue that 
> > they've found is that if the path taken by the data channel 
> > is broken, and these frames are never delivered.
> > 
> > The L2TP folks have found that the lack of a keepalive 
> > mechanism makes it impossible to diagnose such an issue. When 
> > it occurs, the administrator first has to figure out it is 
> > occurring, because the protocol does not, and then needs to 
> > manually follow the path to find the failure.
> > 
> > As far as I can tell, Scott's two primary issues with not 
> > wanting to support UDP ports were:
> > 1. NAT Traversal will require a keepalive on the data 
> > channel. As noted above, we need to add a keepalive on the 
> > data channel in order to be able to detect network routing failures.
> > 2. Modifications to the state machine to handle data channel 
> failure.> Given that such failures can occur, we need to be able 
> to 
> > recover, if possible.
> > 
> > I wanted to raise these issues as they are real, and actually 
> > experienced in L2TP deployments. I believe we need to address 
> > these, and if so, then I believe the complexity associated 
> > with the dual UDP port ends up being resolved.
> > 
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > 
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap