Hi, I am looking for both the solutions.
But lets take the simpler case first, "single DS for each set of selectors". In this simple case as well, the DS should be negotiated (communicated ) from UE to Network Element and back from Network Element to UE before using the DS. Is it possible some way ? My requirement is that both the end points agree on the DS before it is getting used. Thanks, Paul On Tue, Nov 5, 2013 at 12:15 PM, Yoav Nir <y...@checkpoint.com> wrote: > Is what you're looking for multiple DS for the same selectors, or just a > single DS for each set of selectors, that is determined by the AC? > > On Nov 4, 2013, at 10:34 PM, Paul Simon <paulsimo...@gmail.com> wrote: > > > As indicated by Richardson [ The "network" (i.e. the access > concentrator) needs to tell the UE located at the client/device what DS to > use on that network. ] > > This is exactly I need. The UE tells the network element what is the > desired Qos that UE is willing to use for an SA and Network in turn replies > to UE what Qos can really be used. (because finally it is the network which > decides what characteristics the traffic can hold). > > So as I understand currently Qos cannot be indicated through IKE messages > and it has to be done through some application level protocols. > > But since the Qos based traffic is gaining more importance these days, it > would be better if we can accommodate Qos as one of the parameter in IKE > negotiation messages. > > Thanks, > Paul > > > > On Tue, Nov 5, 2013 at 5:04 AM, Yoav Nir <y...@checkpoint.com> wrote: > >> Like I said, Paul can submit an I-D. >> >> But if the UE applies the diffserv to the clear packet, 4301 says that >> these attributes are copied to the ESP packet. There has to be some >> handshake at the application layer to pass this information, no? And you >> really need to do this for the clear packet anyways, because it needs to be >> handled with QoS at the provider network too. If you do it in the app >> layer, it doesn't require any modifications to IKE. >> >> Yoav >> >> On Nov 4, 2013, at 3:18 PM, Michael Richardson <mcr+i...@sandelman.ca> >> wrote: >> >> > >> > Yoav Nir <y...@checkpoint.com> wrote: >> >> There are currently no attributes in IKE to negotiate QoS. >> > >> >> The reason for that text in 5996 is the issue of IPsec packet >> >> re-ordering. If we use the same SA for packets with different QoS >> >> characteristics, then the QoS could then re-order them. This means that >> >> replay protection would drop legitimate packets simply because they >> >> arrived late. To avoid this, the sender may use several SAs so as to >> >> send packets with different QoS characteristics in different >> >> tunnels. This requires no negotiation of QoS characteristics between >> >> the peers, only negotiation of enough SAs for all the different QoS >> >> classes. >> > >> >> If I'm missing something, and there is a need to negotiate this, you >> >> can always submit an I-D. >> > >> > I think you are missing the point. >> > >> > Paul said: >> >> We are having a requirement to have Qos per CHILD SA inside one IKE SA >> or to >> >> have Qos per IKE SA. Is it possible to communicate the Qos in IKE >> handshake ? >> >> Or else how can we achieve to use different Qos, atleast per IKE SA. >> > >> > so, you'd see that actually he wants to have multiple CHILD SAs already. >> > The point is that the packets coming into the tunnel may not be marked >> in any >> > particular way, and the "network" (as Paul calls it. I assume he means >> > some more specific LTE element) needs to inform the UE what markings to >> use. >> > >> > 4301, section 5.1.2 includes: >> >> Another will allow the outer DS field to be mapped to a >> >> fixed value, which MAY be configured on a per-SA basis. (The value >> >> might really be fixed for all traffic outbound from a device, but >> >> per-SA granularity allows that as well.) This configuration option >> > >> > and this is what Paul wants to do. The "network" (i.e. the access >> > concentrator) needs to tell the UE located at the client/device what DS >> to >> > use on that network. >> > >> > My suggestion is, since this is not something is subject to >> negotiation, that >> > simply defining a new notification value. >> > >> > -- >> > ] Never tell me the odds! | ipv6 mesh >> networks [ >> > ] Michael Richardson, Sandelman Software Works | network >> architect [ >> > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on >> rails [ >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
