[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] arguments for map and encap



Dave, 

>-----Original Message-----
>From: David R Oran [mailto:oran@cisco.com] 
>Sent: Wednesday, May 21, 2008 1:12 PM
>To: Christian Vogt
>Cc: Michael Meisel; Dan Jen; Routing Research Group Mailing List
>Subject: Re: [RRG] arguments for map and encap
>
>
>On May 21, 2008, at 3:34 PM, Christian Vogt wrote:
>
>> Hi David -
>>
>Snipping out the rest to answer your one question:
>>
>>>> (a)  the information needed to reestablish the original 
>appearance  
>>>> of
>>>>  an indirected packet is retrievable by any network entity that is
>>>>  to perform the reestablishment, independent of the route of the
>>>>  packet, and
>>>> (b)  the source of that information is trustworthy.
>>>>
>>>
>>> As long as there are no circular dependencies, and that you build  
>>> delay
>>> and possible quarantining complexities into the equation.
>>
>> By "quarantining", do you mean buffering?
>>
>Quarantining is a special form of buffering where you need to  
>rendezvous the buffered packet(s) with a particular set of 
>state which  
>arrives asynchronously and possibly delayed by a significant amount.  
>This is not nearly as simple as buffering for ARQ-like protocols, or  
>for QoS purposes. It's in the same class IP fragment reassembly in  
>that there is a whole class of state-based attacks that need to be  
>considered as well as the inability of any hardware-based forwarding  
>scheme I know of to handle this without punting to a control plane.  
>Some protocols, like ARP, ussually do quarantining in hosts, but  
>dropping in routers.

I'm not quite seeing this as in the same class as IP fragment
reassembly; IP reassembly is like putting together a patchwork
quilt based on whatever oddly-shaped scraps the network throws
at you. But, if every component is identically sized and shaped
its as easy as stacking coins. Routers have been doing that
in fast path since the ATM days, haven't they?

Thanks - Fred
fred.l.templin@boeing.com

>I suspect you and the rest of the folks on the list know this :-)
>I'm just emphasizing that when a scheme needs this, it is a whole lot  
>more complicated and expensive than simple buffering.
>
>DaveO.
>
>> - Christian
>>
>>
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg