Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft

From: Martin Stiemerling <[email-masked]>
Date: Fri, 9 Mar 2007 11:55:10 +0100

[writing with chair's hat off]

Hi all,

I'm starting a new email thread for the QOSM-ID / QSPEC-Type issue  
which came up during the WGLC for the QSPEC draft.

The current QSPEC draft (draft-ietf-nsis-qspec-15.txt) defines the  
QSPEC-Type is
- initiator QSPEC or
- local QSPEC.

When reading the text first I thought that is fine, but given all  
discussions afterwards and reading again the QPSEC I have now some  
doubts. I assume two approaches here how to deal with identifying  
QOSMs on a QNE.

1. Roland's approach with QSPEC-Type identifying the type of QSPEC  
signalled for (e.g., RMD, Y.1541. etc) (also favoured by Georgios)
2. The current QSPEC approach with QSPEC-Type just saying initiator  
or local QSPEC.

With approach 1. it is straight forward how to identify to which  
local RMF to forward the received QSPEC.

With approach 2 I assume only RMF per QNE. The RMF on the node then  
automatically knows what the possible local QOSM can be (and  
remembers this). I one of my past emails I wrote this

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

What is not clear for approach 2 for me: How does a RMF on a QNE  
distinguish between the possible available QOSMs? Does the QSPEC  
assume that the RMFs in one part of a network do know which QOSM is  
used by heart?

Thanks in advance,

   Martin

[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

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Sat, 10 Mar 2007 17:42:47 -0600

Hi Martin,

Please see below. 

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]] 
> Sent: Friday, March 09, 2007 5:55 AM
> To: nsis
> Subject: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft
> 
> discussions afterwards and reading again the QSPEC I have now some  

I don't think there are 2 approaches.  

The QSPEC Type has so far been defined with 2 values assigned in the
IANA section, but an IANA registry is defined so that more QSPEC Types
can be defined, satisfying approach #1.  I don't think there is an
approach #2 with only 2 values defined.

If the intent is to make QSPEC Type equivalent to QOSM ID (as defined in
the QSPEC-12 draft), as I infer from the discussion, then I think we
need to:
- redefine QSPEC Type 0 = no QOSM supported by QNE (it is allowed to not
support any QOSM)
- define additional QSPEC Types as specified in the IANA registry, and
- use a separate bit to identify the initiator/local QSPEC (as proposed
by Georgios).

However, what isn't clear in the discussion so far is exactly how the
QSPEC Type/QOSM ID information would be used by a QNE.  For example,
suppose the QNI supports CL-QSPEC Type and signals that.  Suppose also
that a downstream QNE supports the following:
Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what does the QNE
do with the CL-QSPEC Type information from the QNI, exactly how is the
information used by the QNE?
Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does the
QNE do with the CL-QSPEC Type information from the QNI, exactly how is
the information used by the QNE?
Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with the
CL-QSPEC Type information from the QNI, exactly how is the information
used by the QNE?
Case 4: QNE support no QSPEC Types, Case 3: QNE supports CL-QSPEC-Type
and RMD-QSPEC Type, what does the QNE do with the CL-QSPEC-Type
information from the QNI, exactly how is the information used by the
QNE?

We could define another 4 cases where the QNI signals QSPEC Type = no
QOSM supported.  What are the corresponding answers to the above
questions for those scenarios?

It would be very helpful IMO if this was clarified in more detail than
it has been so far.

> local RMF to forward the received QSPEC.

Is it, I haven't seen yet how it is 'straightforward to identify which
'local RMF' to forward the received QSPEC?  Please see the above
examples and let us know how it works for those 8 cases.

> assume that the RMFs in one part of a network do know which QOSM is  

Well, of course not.  See the above comments, I don't think there is an
approach #2 with only 2 QSPEC Type values, more can be defined as
described. 

Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 Mar 2007 11:09:13 +0100

Hi Jerry

Please see in line!

> From: ASH, GERALD R, ATTLABS [mailto:[email-masked]] 
> Sent: zondag 11 maart 2007 0:43
> To: Martin Stiemerling; nsis
> Cc: ASH, GERALD R, ATTLABS
> Subject: RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft
> 
> Hi Martin,
> 
> Please see below. 
> 
> > signalled for (e.g., RMD, Y.1541. etc) (also favoured by 
> Georgios) 2. 
> > The current QSPEC approach with QSPEC-Type just saying initiator or 
> > local QSPEC.
> 
> The QSPEC Type has so far been defined with 2 values assigned 
> in the IANA section, but an IANA registry is defined so that 
> more QSPEC Types can be defined, satisfying approach #1.  I 
> don't think there is an approach #2 with only 2 values defined.
> 
> If the intent is to make QSPEC Type equivalent to QOSM ID (as 
> defined in the QSPEC-12 draft), as I infer from the 
> discussion, then I think we need to:
> - redefine QSPEC Type 0 = no QOSM supported by QNE (it is 
> allowed to not support any QOSM)

Georgios: I think that according to the QSPEC template draft, this is not
possible.
A QNE will have to at least support the mandatory parameters.
Thus a QNI will include the QOSM ID in the QSPEC object. If a downstream 
QNE cannot support the QOSM then it will only process the mandatory
parameter and if needed 
mark with N the parameters that are not understood.
I think it is good to have the additional bit that specifies that a QOSM is
initial or local.
In this way the received QSPEC will be processed, depending on what was
specified by the QNI, 
by an initial or local QOSM. In the situation that the QNE that receives the
QSPEC is not supporting the
QOSM associated with the received QSPEC, then the QNE has to decide to be
processed by a default initial 
QOSM (if it the included QSPEC is initial QSPEC) or by a default local QOSM
(if it the included 
QSPEC is local QSPEC).

> - define additional QSPEC Types as specified in the IANA registry, and

Georgios: yes, I agree

> - use a separate bit to identify the initiator/local QSPEC 
> (as proposed by Georgios).

Georgios: Yes I agree, see above!
I think it is good to have the additional bit that specifies that a QOSM is
initial or local.
In this way the received QSPEC will be processed, depending on what was
specified by the QNI, 
by an initial or local QOSM. In the situation that the QNE that receives the
QSPEC is not supporting the
QOSM associated with the received QSPEC, then the QNE has to decide to be
processed by a default initial 
QOSM (if it the included QSPEC is initial QSPEC) or by a default local QOSM
(if it the included 
QSPEC is local QSPEC).

> 
> However, what isn't clear in the discussion so far is exactly 
> how the QSPEC Type/QOSM ID information would be used by a 
> QNE.  For example, suppose the QNI supports CL-QSPEC Type and 
> signals that.  Suppose also that a downstream QNE supports 
> the following:
> Case 1: QNE supports CL-QSPEC Type and RMD-QSPEC Type, what 
> does the QNE do with the CL-QSPEC Type information from the 
> QNI, exactly how is the information used by the QNE?

Georgios: By using the additional bit, the QNE will know 
that the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local 
QSPEC. In this way the QNE wil know how to handle the CL-QSPEC and 
how to handle the RMD-QSPEC.

> Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, 
> what does the QNE do with the CL-QSPEC Type information from 
> the QNI, exactly how is the information used by the QNE?

Georgios: Again, by using the additional bit the CL-QSPEC will be identified

as initial QSPEC and the RMD-QSPEC Type, Y1541-QSPEC as local.
The QNE then should use an internal policy that for example 
says RMD-QSPEC is used on interface 1 and that the Y1541-QSPEC is used 
on interface 2. 

> Case 3: QNE only supports RMD-QSPEC Type, what does the QNE 
> do with the CL-QSPEC Type information from the QNI, exactly 
> how is the information used by the QNE?

Georgios: By using the additional bit, the QNE will know 
that the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local 
QSPEC. In this way the QNE wil know how to handle the CL-QSPEC and 
How to handle the RMD-QSPEC.

> Case 4: QNE support no QSPEC Types, Case 3: QNE supports 
> CL-QSPEC-Type and RMD-QSPEC Type, what does the QNE do with 
> the CL-QSPEC-Type information from the QNI, exactly how is 

Note that a QNE even if it does not support any QOSM, according to the 
QSPEC template, it has to support the mandatory parameters 
and mark with N the optional parameters. 

> 
> We could define another 4 cases where the QNI signals QSPEC 
> Type = no QOSM supported.  What are the corresponding answers 
> to the above questions for those scenarios?

Georgios: According to the QSPEC template, I think that this is not
possible!

> 
> It would be very helpful IMO if this was clarified in more 
> detail than it has been so far.
> 
> > With approach 1. it is straight forward how to identify to 
> which local 
> > RMF to forward the received QSPEC.
> 
> Is it, I haven't seen yet how it is 'straightforward to 
> identify which 'local RMF' to forward the received QSPEC?  
> Please see the above examples and let us know how it works 
> for those 8 cases.
> 
> > automatically knows what the possible local QOSM can be 
> (and remembers 
> > this). I one of my past emails I wrote this
> > 
> > >
> Well, of course not.  See the above comments, I don't think 
> there is an approach #2 with only 2 QSPEC Type values, more 
> can be defined as described. 

Georgios: Agree, so we have to provide a solution for approach 1.

Best regards,
Georgios

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 13 Mar 2007 14:33:52 +0100

Hi Georgios,

> A QNE will have to at least support the mandatory parameters.

QSPEC Type 0 means no QOSM supported but would anyway require the  
mandatory parameters, isn't it. I assume this means Type set to 0?

> I think it is good to have the additional bit that specifies that a  

I see this also a good approach, i.e., having the QSPEC Type and a  
bit saying local/initiator.

Thanks,

   Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 13 Mar 2007 14:33:51 +0100

Hi all,

I would like to encourage people to check the initial version of the =20
NSLP-RMF API.

Note that the API is informational only and should just give hints to =20=

the implementers.

Thanks,

   Martin

Am 09.03.2007 um 11:50 schrieb Jukka MJ Manner:

>
> A diff of the changes since -12 is at:
> http://tools.ietf.org/wg/nsis/draft-ietf-nsis-qos-nslp/draft-ietf-=20
> nsis-qos-nslp-13-from-12.diff.html
>
> Main changes:
> - Reduced refreshes are the default mechanism for refreshing sessions
> - RSN needs to be taken into account when a node receives a tear
> - Summary refresh and summary tear introduced (incl. objects and =20
> message
>   processing)
> - QSPEC staking removed
> - ACK-REQ flag introduced for diagnostics purposes
> - Some changes to the INFO_SPEC codes (see the diff)
> - (very) Initial version of NSLP-RMF API
>
>
> Jukka
>
> On Fri, 9 Mar 2007, Martin Stiemerling wrote:
>
>> Please take a look and review the new version of the QoS NSLP draft.
>>
>> There have been some changes in the main part, plus a new appendix =20=

>> with the
>> NSLP-RMF API.
>>
>> Thanks,
>>
>>  Martin
>>
>> Anfang der weitergeleiteten E-Mail:
>>
>>> Von: <[email-masked]>
>>> Datum: 8. M=E4rz 2007 21:50:03 MEZ
>>> An: <[email-masked]>
>>> Kopie: <[email-masked]>
>>> Betreff: [NSIS] I-D ACTION:draft-ietf-nsis-qos-nslp-13.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 =20
>>> Group of
>>> the IETF.
>>>
>>> Title		: NSLP for Quality-of-Service Signaling
>>> Author(s)	: J. Manner, et al.
>>> Filename	: draft-ietf-nsis-qos-nslp-13.txt
>>> Pages		: 85
>>> Date		: 2007-3-8
>>>
>>> This specification describes the NSIS Signaling Layer Protocol =20
>>> (NSLP)
>>>   for signaling QoS reservations in the Internet. It is in =20
>>> accordance
>>>   with the framework and requirements developed in NSIS. Together =20=

>>> with
>>>   GIST, it provides functionality similar to RSVP and extends it. =20=

>>> The
>>>   QoS NSLP is independent of the undext Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi Jerry,

Thanks for the response. The issue gets much clearer with this email  
for me.
Please see below.

Am 11.03.2007 um 00:42 schrieb ASH, GERALD R, ATTLABS:

> defined in

Fine with me. That does make sense to me and clarifies the issue.

> It would be very helpful IMO if this was clarified in more detail than

Yes, I see the point. This basically boils down to which incoming  
QOSM is mapped to which outgoing QOSM, i.e., if a mapping is required  
or desired on how to map initiator to local QOSM.

I suppose (also from reading Georgios' email) that this choice is  
depending on the outgoing interface, better outgoing/local domain.  
Again, correct me if I'm wrong!

Taking, for instance, case 1: An ingress QNE for a domain supports CL- 
QSPEC erlying QoS specification or
>>>   architecture and provides support for different reservation =20
>>> models.
>>>   It is simplified by the elimination of support for multicast =20
>>> flows.
>>>   This specification explains the overall protocol approach, design
>>>   decisions made and provides examples. It specifies object, message
>>>   formats and processing rules.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-13.txt
>>>
>>> To remove yourself from the I-D Announcement list, send a message to
>>> [email-masked] with the word unsubscribe in the =20
>>> body of
>>> the message.
>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20
>>> 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-qos-nslp-13.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-qos-nslp-13.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.

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 13 Mar 2007 14:33:51 +0100

If the traffic stays within the CL-QSPEC Type domain, CL-QSPEC Type  
is chosen/kept.  If the traffic leaves the  CL-QSPEC Type domain,  
e.g., the RMD QSPEC Type is chosen. I assume this is depending on the  
outgoing interface/domain and is locally configured my a human.

For case (QNE only supports RMD-QSPEC Type), the local configuration  
(again manually) says use RMD-QSPEC Type for outgoing on each  
interface other than the receiving.

> examples and let us know how it works for those 8 cases.

I hope to have solved this with the two examples. (keeping fingers  
crossed that I have brought my thoughts to this email :-)

> approach #2 with only 2 QSPEC Type values, more can be defined as

Ok, then we are both on the same side.

Thanks a lot!

   Martin

ext Steps in Signaling <nsis.ietf.org>

Hi Jerry,

Taking, for instance, case 1: An ingress QNE for a domain supports CL- 
QSPEC Type and RMD QSPEC Type; the received Type is CL-QSPEC Type.   
If the traffic stays within the CL-QSPEC Type domain, CL-QSPEC Type  
is chosen/kept.  If the traffic leaves the  CL-QSPEC Type domain,  
e.g., the RMD QSPEC Type is chosen. I assume this is depending on the  
outgoing interface/domain and is locally configured my a human.

For case (QNE only supports RMD-QSPEC Type), the local configuration  
(again manually) says use RMD-QSPEC Type for outgoing on each  
interface other than the receiving.

> examples and let us know how it works for those 8 cases.

I hope to have solved this with the two examples. (keeping fingers  
crossed that I have brought my thoughts to this email :-)

> approach #2 with only 2 QSPEC Type values, more can be defined as

Ok, then we are both on the same side.

Thanks a lot!

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 13 Mar 2007 16:14:09 +0100

Hi Martin

Regarding the following paragraph:

 > QSPEC Type 0 means no QOSM supported but would anyway require 
> the mandatory parameters, isn't it. I assume this means Type set to 0?

I think that this situation does not make sense to me!
The mandatory parameters are signaled for a certain 
QoS goal, which is very much associated with a certain RMF.

Best Regards,
Georgios

> Sent: dinsdag 13 maart 2007 14:34
> To: Georgios Karagiannis
> Cc: 'ASH, GERALD R, ATTLABS'; 'nsis'
> Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft
> 
> Hi Georgios,
> 
> 
> >> IANA section, but an IANA registry is defined so that more QSPEC 
> >> Types can be defined, satisfying approach #1.  I don't 
> think there is 
> >> an approach #2 with only 2 values defined.
> >>
> >> If the intent is to make QSPEC Type equivalent to QOSM ID 
> (as defined 
> >> in the QSPEC-12 draft), as I infer from the discussion, 
> then I think 
> >> we need to:
> > Georgios: I think that according to the QSPEC template 
> draft, this is 
> > not possible.
> QSPEC Type 0 means no QOSM supported but would anyway require 
> the mandatory parameters, isn't it. I assume this means Type set to 0?
> 
> > Thus a QNI will include the QOSM ID in the QSPEC object. If a 
> > downstream QNE cannot support the QOSM then it will only 
> process the 
> > mandatory parameter and if needed mark with N the 
> parameters that are 
> > not understood.
> > I think it is good to have the additional bit that specifies that a 
> > QOSM is initial or local.
> 
> I see this also a good approach, i.e., having the QSPEC Type 
> and a bit saying local/initiator.
> 
> Thanks,
> 
>    Martin
> 
> 
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL 
> | Registered in England 2832014
> 
> 
>

---

From: "ASH, GERALD R, ATTLABS" <[email-masked]>
Date: Tue, 13 Mar 2007 11:46:25 -0500

Martin,

I agree with your comments, and have these additional comments based on
the thread:

1. I've still not seen a clear illustration of how QSPEC Type is used,
*at the bit level*.  IMO one possible use is that the QNI can signal
QSPEC Type to indicate its intent (along with QSPEC parameters, M flags,
etc.), which should help a downstream QNE decide how to process the
QSPEC in the case where a downstream QNE supports multiple QOSMs.

But in the example I posed this doesn't seem to be the case:

"Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC Type and
RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type information
from the QNI, exactly how is the information used by the QNE?

Georgios: By using the additional bit, the QNE will know that the
CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a local QSPEC. In
this way the QNE will know how to handle the CL-QSPEC and how to handle
the RMD-QSPEC."

Since the QNI signals its intent is CL-QSPEC, and that is in fact the
QSPEC that the QNI signals, why would a QNE then chose the RMD-QSPEC
when it supports the CL-QSPEC and that is the QNI's intent?

I would still like to see a clear bit level example of how QSPEC Type is
used.

2. It is not required for a QNI/QNE to support any QOSM.  This is
independent of the mandatory requirement for QNEs to signal and
interpret the TMOD parameter and for QNEs to interpret QSPEC parameters
for which the M flag has been set.

3. It isn't clear to me that the proposed bit to indicate
Initiator/Local QSPEC is absolutely required.  It would seem that from
the syntax of encapsulating the Initiator QSPEC within the Local QSPEC
that the QNE could determine which QSPEC is where without these bits.
While specifying such a bit isn't a big deal, it would be useful if some
implementer could clarify why this bit is needed.

Thanks,
Jerry

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]] 
Sent: Tuesday, March 13, 2007 9:34 AM
To: ASH, GERALD R, ATTLABS
Cc: nsis
Subject: Re: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft

Hi Jerry,

Thanks a lot!

   Martin

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 14 Mar 2007 11:42:03 +0100

Hi Jerry

Please see in line!

> Sent: dinsdag 13 maart 2007 17:46
> To: Martin Stiemerling
> Cc: ASH, GERALD R, ATTLABS; nsis
> I agree with your comments, and have these additional 
> comments based on the thread:
> 
> 1. I've still not seen a clear illustration of how QSPEC Type 
> is used, *at the bit level*.  IMO one possible use is that 
> the QNI can signal QSPEC Type to indicate its intent (along 
> with QSPEC parameters, M flags, etc.), which should help a 
> downstream QNE decide how to process the QSPEC in the case 
> where a downstream QNE supports multiple QOSMs.
> 
> "Case 1: QNI sends CL-QSPEC Type and QNE supports CL-QSPEC 
> Type and RMD-QSPEC Type, what does the QNE do with the 
> CL-QSPEC Type information from the QNI, exactly how is the 
> Georgios: By using the additional bit, the QNE will know that 
> the CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a 
> local QSPEC. In this way the QNE will know how to handle the 
> CL-QSPEC and how to handle the RMD-QSPEC."
> 
> Jerry: Since the QNI signals its intent is CL-QSPEC, and that is in 
> fact the QSPEC that the QNI signals, why would a QNE then 
> chose the RMD-QSPEC when it supports the CL-QSPEC and that is 
> the QNI's intent?
> 
> I would still like to see a clear bit level example of how 
> QSPEC Type is used.

Georgios: Note that in the situation that a combination of a bound 
End-to-end scenario is used that uses in this case the CL-QSpec and 
an edge-to-edge scenario that in this case uses the RMD-QSpec.
Furthermore, note that the Ingress node is a QNI and the Egress is a QNR 
for the edge-to-edge scenario.
In this scenario the QNE can be configured to use the CL-QSPEC only
by the Ingress and Egress nodes and use the RMD-QOSM at the Ingress, Egress 
and all Interior nodes.
 
Please noet that the same situation occurs when the 
Inserv Controlled Load (end-to-end to end TSpec) model used by RSVP 
is combined with the RSVP aggegation QoS model (RFC3175).

> 
> 2. It is not required for a QNI/QNE to support any QOSM.  
> This is independent of the mandatory requirement for QNEs to 
> signal and interpret the TMOD parameter and for QNEs to 
> interpret QSPEC parameters for which the M flag has been set.

Georgios: If a QOSM is not supported by the QNI, then why it should send a
QSpec?
A QSpec is only sent to achieve a certain QoS provisioning that is
associated with a RMF.
We of course can define a default QOSM, that can be used by a QNI to just
send the 
default mandatory parameters. But all QNEs will have to know that the
recived QSPEC 
is belonging to this default QOSM.

> Initiator/Local QSPEC is absolutely required.  It would seem 
> that from the syntax of encapsulating the Initiator QSPEC 
> within the Local QSPEC that the QNE could determine which 
> QSPEC is where without these bits.
> While specifying such a bit isn't a big deal, it would be 
> useful if some implementer could clarify why this bit is needed.

Georgios: No the initial QNI will be configured to set the bit to "Initial"
value included in the 
Initial QSpec and the Ingress/Egress QNI (in case of a local QOSM) will be
configured 
to set the bit "Local" in the local QSpec.

Best regards,
Georgios

> Thanks for the response. The issue gets much clearer with 
> this email for me.
> Please see below.
> 
> > - use a separate bit to identify the initiator/local QSPEC (as 
> > proposed by Georgios).
> 
> does the 
> > Case 2: QNE supports RMD-QSPEC Type and Y1541-QSPEC Type, what does 
> > the QNE do with the CL-QSPEC Type information from the QNI, exactly 
> > Case 3: QNE only supports RMD-QSPEC Type, what does the QNE do with 
> > the CL-QSPEC Type information from the QNI, exactly how is the 
> CL-QSPEC-Type 
> Type = no 
> Yes, I see the point. This basically boils down to which 
> incoming QOSM is mapped to which outgoing QOSM, i.e., if a 
> mapping is required or desired on how to map initiator to local QOSM.
> 
> I suppose (also from reading Georgios' email) that this 
> choice is depending on the outgoing interface, better 
> outgoing/local domain.  
> If the traffic stays within the CL-QSPEC Type domain, 
> CL-QSPEC Type is chosen/kept.  If the traffic leaves the  
> CL-QSPEC Type domain, e.g., the RMD QSPEC Type is chosen. I 
> assume this is depending on the outgoing interface/domain and 
> is locally configured my a human.
> 
> For case (QNE only supports RMD-QSPEC Type), the local 
> configuration (again manually) says use RMD-QSPEC Type for 
> outgoing on each interface other than the receiving.
> 
> 
> >
> identify which 
> I hope to have solved this with the two examples. (keeping 
> fingers crossed that I have brought my thoughts to this email :-)
> 
> >

---

From: <[email-masked]>
Date: Wed, 14 Mar 2007 23:55:11 -0500

Hi Georgios,

>> QSPEC Type to indicate its intent (along with QSPEC parameters, M 
>> flags, etc.), which should help a downstream QNE decide how 
>to process 
>> the QSPEC in the case where a downstream QNE supports multiple QOSMs.
>> 
>> RMD-QSPEC Type, what does the QNE do with the CL-QSPEC Type 
>> CL-QSPEC is an initial QSPEC and that the RMD-QSPEC is a 
>local QSPEC. 
>> In this way the QNE will know how to handle the CL-QSPEC and how to 
>> handle the RMD-QSPEC."
>> 
>> fact the QSPEC that the QNI signals, why would a QNE then chose the 
>> RMD-QSPEC when it supports the CL-QSPEC and that is the QNI's intent?
>> 
>QSPEC Type 
>> is used.
>Georgios: Note that in the situation that a combination of a 
>bound End-to-end scenario is used that uses in this case the 
>CL-QSpec and an edge-to-edge scenario that in this case uses 
>the RMD-QSpec.
>In this scenario the QNE can be configured to use the CL-QSPEC 
>only by the Ingress and Egress nodes and use the RMD-QOSM at 
>the Ingress, Egress and all Interior nodes.
> 
>Please noet that the same situation occurs when the Inserv 
>Controlled Load (end-to-end to end TSpec) model used by RSVP 

I think I still don't fully see how this works in practice. I don't
know if any other QoSMs are supporting this functionality, nor
have I seen other people explain that is something that the need.
It could be that I don't exactly see what you are proposing.
In generally, I would like to know what is needed, not what is possible.

thanks,
John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Mar 2007 12:49:30 +0100

Hi John

What I have explained is something that is needed to support
the following bound and combined session signaling scenarios:

* End-to-end session and edge-to-edge (local) session 
* End-to-end session and end-to-edge session 

In NSIS the end-to-end and edge-to-edge situation can occur 
When:
* the end-to-end CL-QOSM is bound and combined with 
  an edge-to-edge (local) Y.1541
* the end-to-end CL-QOSM is bound and combined with 
  an edge-to-edge (local) RMD-QOSM

In the RSVP context this occurs when the 
end-to-end RSVP session is combined with the 
edge-to-edge local RSVP aggregation session

Best regards, 
Georgios

> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 15 maart 2007 5:55
> To: [email-masked]
> Subject: RE: [OFF-LIST] RE: [NSIS] QOSM-ID / QSPEC-Type in QSPEC draft
> 
> Hi Georgios,
> 
> 
> Type and 
> chose the 
> >End-to-end scenario is used that uses in this case the 
> CL-QSpec and an 
> >edge-to-edge scenario that in this case uses the RMD-QSpec.
> >In this scenario the QNE can be configured to use the 
> CL-QSPEC only by 
> >the Ingress and Egress nodes and use the RMD-QOSM at the Ingress, 
> >Egress and all Interior nodes.
> > 
> Controlled 
> >Load (end-to-end to end TSpec) model used by RSVP is 
> combined with the 
> >RSVP aggegation QoS model (RFC3175).
> 
> I think I still don't fully see how this works in practice. I 
> don't know if any other QoSMs are supporting this 
> functionality, nor have I seen other people explain that is 
> something that the need.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 15 Mar 2007 14:21:10 +0100

Hi John

An example of how the explained operation can work 
is described in the RMD-QOSM.
Please check for example Sections:
  * 4.6.1.1.1. Operation in Ingress node
  * 4.6.1.1.2 Operation in the Interior nodes
  * 4.6.1.1.3 Operation in the Egress node   
In
 http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-09.txt
 
 Best Regards,
 Georgios
 
> > >From: ext Georgios Karagiannis [mailto:[email-masked]]
> > >Sent: 15 March, 2007 04:50
> > >To: Loughney John (Nokia-NRC/PaloAlto); [email-masked]
> > >What I have explained is something that is needed to support the 
> > >following bound and combined session signaling scenarios:
> > >
> > >In the RSVP context this occurs when the end-to-end RSVP 
> session is 
> > >combined with the edge-to-edge local RSVP aggregation session
> > >
> > >
> > >Best regards,
> > >Georgios
> > >
> > >
> > >
> > >> >Furthermore, note that the Ingress node is a QNI and the
> > >Egress is a
> > >> >QNR
> > >> >
> > >> know if any other QoSMs are supporting this 
> functionality, nor have 
> > >> I seen other people explain that is something that the need.