Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft

From: "Loughney John \(Nokia-NRC/PaloAlto\)" <[email-masked]>
Date: Wed, 7 Mar 2007 23:08:09 -0800

Martin

That is my understanding as well. If there is some other use and/or issue, it would be good to get a very precise statement on what is needed and why.

John
sent from my Nokia E90.

--- original message ---
From: "ext Martin Stiemerling" <[email-masked]>
Subject: Re: [NSIS] comment on reintroduction of QOSM-ID in qspec draft
Date: 7th March 2007
Time: 2:45:59 pm

Hi Georgios and Jerry,

I'm trying to understand what the issue is, so please correct me when  
I'm wrong!

I believe that the QOSM ID is not needed as there is only one local  
RMF per QNE. This local RMF can actually support multiple QOSMs but  
this is opaque to the QoS NSLP. I.e., the QoS NSLP has only the  
chance to pass the QSPEC in a single piece to a single RMF.
The mapping between the different initiator QOSM and the local QOSM  
is solely happening within the RMF.

Thanks,

   Martin

Am 02.03.2007 um 11:19 schrieb Georgios Karagiannis:

> Hi Jerry
>
> The main goal of using the QOS-NSLP messages is to
> carry a QSPEC object and deliver it to the right QOSM/RMF.
>
> If a QNE will support simultaneously more than one QOS models, say  
> QOSM-I1,
> QOSM-I2,
> and a QoS-NSLP message, which carries a QSPEC that is say  
> associated with
> QOSM-I1,
> arrives at a QNE, then the QNE must be able to deliver
> the received QSPEC to the right RMF/QOSM, i.e., QOSM-I1.
>
>  How the QNE will know to which RMF it should deliver the received  
> QSPEC?
>
> Best regards,
> Georgios
>
>
>
>
>> -----Original Message-----
>> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]]
>> Sent: donderdag 1 maart 2007 23:49
>> To: Georgios Karagiannis; Martin Stiemerling; nsis
>> Cc: ASH, GERALD R, ATTLABS
>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in
>> qspec draft
>>
>> Georgios,
>>
>> Your examples don't illustrate how and why a QOSM ID field is
>> needed and used.
>>
>> Perhaps you are saying that QoS NSLP and RMF communicate with
>> messages and that the I-QOSM ID and L-QOSM ID need to be
>> included in those messages so that the QoS NSLP can react
>> differently based on which L-QOSM is being used by the RMF?
>>
>> If so, then this interaction suffers from the problems
>> identified in Cornelia's slide (attached) discussed on our
>> conference call on 31 January.
>>
>> If not, please give a more detailed example of how and why a
>> QOSM ID field is needed and used.
>>
>> Jerry
>>
>> -----Original Message-----
>> From: Georgios Karagiannis [mailto:[email-masked]]
>> Sent: Thursday, March 01, 2007 11:11 AM
>> To: ASH, GERALD R, ATTLABS; 'Martin Stiemerling'; 'nsis'
>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in
>> qspec draft
>>
>> Hi Jerry
>>
>> The need for the QOSM ID can be seen probably seen in the
>> below e-mail:
>>
>> Suppose that:
>>
>>  A QNE supports the following:
>>
>>  * end-to-end QOS Models:
>>     QOSMI-1, QOSMI-2, QOSMI-3
>>
>> * local QoS Models:
>>     QOSML-1, QOSML-2, QOSML-3
>>
>> Suppose now that the operator of such a QNE wants to use the follwing
>> combinations:
>>
>> * QOSMI-1 with QOSML-3.
>>
>> Meaning that end-to-end sessions and QOS-NSLP messages that
>> are carrying
>>
>> initial QSPEC of QOSM-I1 should be bound with local sessions
>> and local QOS-NSLP messages that are carying local QSPEC of QOSM-L3
>>
>> * QOSMI-2 with QOSML-3
>>
>> Meaning that end-to-end sessions and QOS-NSLP messages that
>> are carrying
>>
>> initial QSPEC of QOSMI-2 should be bound with local sessions
>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-3
>>
>> * QOSMI-3 with QOSML-1
>>
>> initial QSPEC of QOSMI-3 should be bound with local sessions
>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-1
>>
>> * QOSMI-3 with QOSML-2
>>
>> initial QSPEC of QOSMI-3 should be bound with local sessions
>> and local QOS-NSLP messages that are carying local QSPEC of QOSML-2
>> --
>>
>>
>> If the QOSM ID will not be supported these combinations will
>> not beable
>> to
>> be made meaning that
>> A QNE will be able to support only one initial (end-to-end) QOSM with
>> only
>> one local QOSM at a time.
>>
>> Best Regards,
>> Georgios
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]]
>>> Sent: woensdag 28 februari 2007 14:43
>>> To: Georgios Karagiannis; Martin Stiemerling; nsis
>>> Cc: ASH, GERALD R, ATTLABS
>>> Subject: RE: [NSIS] comment on reintroduction of QOSM-ID in
>>> qspec draft
>>>
>>> Georgios, All,
>>>
>>>> -----Original Message-----
>>>> From: Georgios Karagiannis [mailto:[email-masked]]
>>>> Sent: Wednesday, February 28, 2007 12:37 AM
>>>> To: Martin Stiemerling; nsis
>>>> Subject: [NSIS] comment on reintroduction of QOSM-ID in
>> qspec draft
>>>>
>>>> Hi
>>>>
>>>> I was busy updating some of the QOSM drafts and I have seen that
>>>> starting from version 13 of the QSPEC draft, the QOSM ID
>> field  is
>>>> removed form the common header of a QSPEC object and
>>> instead of this,
>>>> the field QSPEC type is used.
>>>
>>> The QSPEC Type was introduced to support Roland's QSPEC
>>> stacking/encapsulation method (see
>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07183.ht
>>> ml), it does not replace QOSM ID.
>>>
>>> The QOSM ID was removed in the discussion around the QSPEC-13
>>> draft update, see the post on 1 November 2006
>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07084.ht
>>> ml, where it says "A QOSM ID need not be defined or signaled
>>> and a QNE need not support any particular QOSM".  Slide 3 of
>>> the QSPEC presentation at IETF-67 makes the same point.  The
>>> same point is made again in the announcement of the draft to
>>> the NSIS list at
>>> http://www1.ietf.org/mail-archive/web/nsis/current/msg07325.ht
>>> ml and the point is also made in Appendix A of the QSPEC
>>> draft itself.  There were no objections to this point.
>>>
>>>> I agree that QSPEC type (shows if the QSPEC object is
>> initial or a
>>>> local) is useful and it should be used, but by removing
>> the QOSM ID
>>>> field it will mean that a QNE can always support only one type of
>>>> initial
>>>> (end-to-end) QOSM and one type of local QOSM.
>>>> That is not reasonable. A QNE should be able to support
>>> many QOSMs and
>>>> it should be able to distinguish and associate a QSPEC
>>> object with a
>>>> certain QOSM.
>>>
>>> There is no mention in any QSPEC draft as to how or why a
>>> QOSM ID field is needed or used.  A QNE can support any QOSM
>>> it wants, it does not depend on a QOSM ID field from the QNI
>>> to determine which one.
>>>
>>> At a minimum, we would need to have a bit-level example of
>>> how/why such a field is needed to justify reintroducing the
>>> QOSM ID field.
>>>
>>>> Therefore, I think that it is required that the QOSM ID
>>> field should
>>>> be reintroduced in the QSPEC common header. The field
>> QSPEC type is
>>>> also useful ant it should be kept.
>>>
>>> We need clear justification to reintroduce the complexity of
>>> having the QOSM ID field and the IANA registry to maintain
>>> the parameter.
>>>
>>> Jerry
>>>
>>>>
>>>> Best regards,
>>>> Georgios
>>>>
>>>>
>>>> On 2/20/2007, "Martin Stiemerling"
>>> <[email-masked]> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I would like to start the working group last call for the
>>> QSPEC draft
>>>>
>>> (http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt).
>>>>>
>>>>> The WGLC is starting today and will run for two weeks
>>> until Tuesday
>>>>> Feb 6th.
>>>>>
>>>>> Please send your comments to the NSIS WG list.
>>>>>
>>>>>   Martin
>>>>>
>>>>> Anfang der weitergeleiteten E-Mail:
>>>>>
>>>>>> Von: <[email-masked]>
>>>>>> Datum: 16. Februar 2007 21:50:02 MEZ
>>>>>> An: <[email-masked]>
>>>>>> Kopie: <[email-masked]>
>>>>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-15.txt
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts
>>>>>> directories.
>>>>>> This draft is a work item of the Next Steps in
>> Signaling Working
>>>>>> Group of the IETF.
>>>>>>
>>>>>> 	Title		: QoS NSLP QSPEC Template
>>>>>> 	Author(s)	: J. Ash, et al.
>>>>>> 	Filename	: draft-ietf-nsis-qspec-15.txt
>>>>>> 	Pages		: 54
>>>>>> 	Date		: 2007-2-16
>>>>>>
>>>>>> The QoS NSLP protocol is used to signal QoS reservations and is
>>>>>>    independent of a specific QoS model (QOSM) such as
>> IntServ or
>>>>>>    DiffServ.  Rather, all information specific to a QOSM is
>>>>>> encapsulated
>>>>>>    in a separate object, the QSPEC.  This document defines
>>>> a template
>>>>>>    for the QSPEC including a number of QSPEC parameters.
>>>  The QSPEC
>>>>>>    parameters provide a common language to be re-used in
>>>> several QOSMs
>>>>>>    and thereby aim to ensure the extensibility and
>>>> interoperability of
>>>>>>    QoS NSLP.  The node initiating the NSIS signaling adds
>>>> an initiator
>>>>>>    QSPEC, which indicates the QSPEC parameters that must be
>>>>>> interpreted
>>>>>>    by the downstream nodes less the reservation fails, thereby
>>>>>> ensuring
>>>>>>    the intention of the NSIS initiator is preserved along the
>>>>>> signaling
>>>>>>    path.
>>>>>>
>>>>>> A URL for this Internet-Draft is:
>>>>>>
>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-15.txt
>>>>>>
>>>>>> To remove yourself from the I-D Announcement list, send a
>>>> message to
>>>>>> [email-masked] with the word unsubscribe in
>>>> the body of
>>>>>> the message.
>>>>>> You can also visit
>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>>>>>> to change your subscription settings.
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP.
>>> Login with the
>>>>>> username "anonymous" and a password of your e-mail
>>> address. After
>>>>>> logging in, type "cd internet-drafts" and then "get
>>>>>> draft-ietf-nsis-qspec-15.txt".
>>>>>>
>>>>>> A list of Internet-Drafts directories can be found in
>>>>>> http://www.ietf.org/shadow.html or
>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>
>>>>>> Internet-Drafts can also be obtained by e-mail.
>>>>>>
>>>>>> Send a message to:
>>>>>> 	[email-masked].
>>>>>> In the body type:
>>>>>> 	"FILE /internet-drafts/draft-ietf-nsis-qspec-15.txt".
>>>>>>
>>>>>> NOTE:	The mail server at ietf.org can return the document in
>>>>>> 	MIME-encoded form by using the "mpack" utility.
>>  To use this
>>>>>> 	feature, insert the command "ENCODING mime"
>> before the "FILE"
>>>>>> 	command.  To decode the response(s), you will
>> need "munpack" or
>>>>>> 	a MIME-compliant mail reader.  Different MIME-compliant
>>>> mail readers
>>>>>> 	exhibit different behavior, especially when dealing with
>>>>>> 	"multipart" MIME messages (i.e. documents which
>> have been split
>>>>>> 	up into multiple messages), so check your local
>> documentation on
>>>>>> 	how to manipulate these messages.
>>>>>>
>>>>>> Below is the data which will enable a MIME compliant
>> mail reader
>>>>>> implementation to automatically retrieve the ASCII
>> version of the
>>>>>> Internet-Draft.)
>>>
>>> _______________________________________________
>>> nsis mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/nsis
>>>
>>
>>
>>
>
>

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis