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

RE: QoS and IKEv2



> It seems to me it may be easier to explicitly include this (ToS)
> information in the TS payload.

Actually, it should be PHB information.  For more discussion of QoS
and tunnels, see RFC 2983.  RFC 3308 contains a worked solution to
this sort of problem for L2TP.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Jesse Alpert [mailto:jalpert@CheckPoint.com]
> Sent: Wednesday, March 05, 2003 4:36 AM
> To: ipsec@lists.tislabs.com
> Subject: QoS and IKEv2
> 
> 
> Hi,
> 
> If I understood correctly one of the reasons for supporting "fast"
creation
> of multiple SAs between a single pair of entities (via the CREATE_CHILD_SA
> exchange) was to allow support for QoS. The theory was that data streams
> requiring different QoS levels are to be sent over separate tunnels to
avoid
> problems with the replay counter which arise when some packets are
tunneled
> faster than others.
> 
> The original requirements document 
> (draft-ietf-ipsec-sonofike-rqts-00.txt)
> stated that:
>   "negotiation of IPsec tunnels needs to accommodate QoS
>    information, predominantly in the set of selectors used to identify
>    the contents of any particular IPsec tunnel"
> 
> I can not find any reference to this in the current IKEv2 draft
(ikev2-05).
> A peer may need to create multiple tunnels with the exact same traffic
> selectors but with different QoS levels (ToS). How does one peer inform
the
> other what type of traffic is to pass in each tunnel.  Theoretically this
> information does not have to be negotiated as the initiator can establish
a
> few tunnels and send the data over them any way he wishes, but the
responder
> should at least expect this behavior and be willing to keep multiple
> identical SAs for an extended period of time (the draft currently states
> that "An endpoint SHOULD wait a random amount of time before closing a
> redundant SA to prevent cycling"). In addition if the traffic is
> bi-directional, the responder will have to somehow select a different
tunnel
> for every different QoS level of the packets it is sending.  It seems to
me
> it may be easier to explicitly include this (ToS) information in the TS
> payload.
> 
> Am I missing something?
> 
> Jesse
>