[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 transport concerns
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Black" == Black David <Black_David@emc.com> writes:
>> Are you telling me that, if a gateway system is aware of QoS that was
>> requested by an end system, that it can never inform the other gateway of
>> this fact?
Black> No - it's welcome to inform the other gateway, just not via IKEv2.
>> Clearly, a gateway system that knows of a QoS requested by an end system
>> (whether via RSVP or other) could easily present appropriate signaling for
>> the resulting tunnel.
Black> Yes, via an appropriate QoS signaling protocol, which is *not* IKEv2, IMHO.
okay.
Are signaling protocols supposed to be forwarded through the tunnel?
Are there signaling protocols which an end systems can use to control QoS
*towards* them? If so, how does the end system have the return stream of the
tunnel properly signaled?
Other than RSVP, what else is there at present? (I'm certainly out of
touch).
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPe1eIYqHRg3pndX9AQEBwwQAggW2fm1R48mDJXeQ1Cp9guHhxVRQrL79
+gQJQIT21I2o0wbRZBRvS0RHxn4IXcHBYFvlvodhqmWqqIHg3eEco4yx5HUkUk0d
ApwcvcIKsDcyeR1Z+2xbjcPTU4A/uGTWGA4Y8o4i6INf44COpezHV3rHxNuaKiQ0
f+s/ID5IB3w=
=qrNZ
-----END PGP SIGNATURE-----