[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-----