RE: about QoS context
"Pat R. Calhoun" <[email protected]> Tue, 20 Jul 2004 05:25:11 -0700
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0960618410== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46E54.BB6D6D87" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46E54.BB6D6D87 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While DiffServ does not maintain state, the QoS policy associated with a = mobile node is itself a policy. So I could easily envision a QoS context = transfer that would include the user (or device's) permissions. PatC -----Original Message----- From: [email protected] on behalf of [email protected] Sent: Tue 7/20/2004 12:09 AM To: [email protected] Subject: [Seamoby] about QoS context =20 Hi everybody, I'm sorry for my intervention. I'm currently studying the context = transfer=20 approach; I find that in most of the literature, QoS is mentioned as a=20 potential candidate service. As you know there are two well known = different=20 approaches: Diffserv and Intserv, but neither of them seems to match the = idea=20 of the control transfer protocol. Diffserv doesn't keep any information=20 specifically related to the MN, on the other hand, Intserv does keep = state=20 information but not only in the access routers but in the entire path. I'd like to know if I'm missing or misunderstanding something. (or if = I'm=20 totally lost) I'll appreciate your comments. Thanks a lot in advance for your time. Christian G. _______________________________________________ Seamoby mailing list [email protected] https://www1.ietf.org/mailman/listinfo/seamoby ------_=_NextPart_001_01C46E54.BB6D6D87 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.6944.0"> <TITLE>RE: [Seamoby] about QoS context</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=3D2>While DiffServ does not maintain state, the QoS policy = associated with a mobile node is itself a policy. So I could easily = envision a QoS context transfer that would include the user (or = device's) permissions.<BR> <BR> PatC<BR> <BR> <BR> -----Original Message-----<BR> From: [email protected] on behalf of [email protected]<BR> Sent: Tue 7/20/2004 12:09 AM<BR> To: [email protected]<BR> Subject: [Seamoby] about QoS context<BR> <BR> <BR> <BR> Hi everybody,<BR> <BR> I'm sorry for my intervention. I'm currently studying the context = transfer<BR> approach; I find that in most of the literature, QoS is mentioned as = a<BR> potential candidate service. As you know there are two well known = different<BR> approaches: Diffserv and Intserv, but neither of them seems to match the = idea<BR> of the control transfer protocol. Diffserv doesn't keep any = information<BR> specifically related to the MN, on the other hand, Intserv does keep = state<BR> information but not only in the access routers but in the entire = path.<BR> I'd like to know if I'm missing or misunderstanding something. (or if = I'm<BR> totally lost)<BR> I'll appreciate your comments.<BR> Thanks a lot in advance for your time.<BR> <BR> Christian G.<BR> <BR> _______________________________________________<BR> Seamoby mailing list<BR> [email protected]<BR> <A = HREF=3D"https://www1.ietf.org/mailman/listinfo/seamoby">https://www1.ietf= .org/mailman/listinfo/seamoby</A><BR> <BR> <BR> </FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C46E54.BB6D6D87-- --===============0960618410== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Seamoby mailing list [email protected] https://www1.ietf.org/mailman/listinfo/seamoby --===============0960618410==--