Subject: RE: [NSIS] Plans for the protocol drafts

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Mon, 29 Mar 2004 11:31:59 +0200

Hi Sven, 

If WG decides that we need reservation priority, I think, it is common feature for QoS models, so it should be defined in QoS NSLP.

Best regards, Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, March 26, 2004 3:42 PM
To: Ash, Gerald R (Jerry), ALABS
Cc: [email-masked]; Ash, Gerald R (Jerry), ALABS
Subject: RE: [NSIS] Plans for the protocol drafts

Hi Jerry,

Sorry for the delayed reply. Please find some comments inline.

Best regards,
Sven

"Ash, Gerald R (Jerry), ALABS" <[email-masked]> on 24/03/2004 16:17:07

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, <[email-masked]>
cc:    "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Subject:    RE: [NSIS] Plans for the protocol drafts

Hi Sven,

Dave> 6. Reservation priority is declared out of scope
Dave> but is critically important. We can't just punt
Dave> this. One thought is to have it be part of a set
Dave> of "common facilities" that go across all the
Dave> GIMPS applications. I bet there are a number of
Dave> such common things which are not part of the
Dave> transport but aren't specific to a particular
Dave> signaling application.

Sven> We would like to receive input on this from the
Sven> WG. Why do they think it is needed, what are the
Sven> requirements, ...

I agree with Dave that 'reservation priority' is critically important to
add.  IMO there should be a requirement for reservation priority (i.e., for
emergency services/ETS/E911, etc.) for the NSLP QoS signaling.  The
'standard Qspec' being worked now by the QoS model draft teams can be the
vehicle to introduce this.  As requested by John (and the WG), we will work
out a common Qspec across models, and maximize commonality.

To maximize commonality, I think it preferable to make reservation priority
a part of the common QoS NSLP rather than part of the individual QoS model
(opaque to QoS NSLP).

As discussed in 'NSIS Network Service Layer Protocol QoS Signaling
Proof-of-Concept'
http://www.ietf.org/internet-drafts/draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt
, reservation priority is a way to differentiate emergency services flows,
and assign them a higher priority than normal or best-effort priority
flows.  Requirements for reservation priority are suggested in Section B.4
'Support of Priority & Reliability Attributes':
a. Reliability can be requested in the form of a Priority Class for a
specific network function, such as CAC priority.
b. There are a limited number of Priority Classes to ensure scalability
(e.g., 3 classes), such as:
- CAC Priority Class: The urgency with which a service connection is
desired (e.g., High, Normal, Best Effort).
- Restoration Priority Class: The urgency with which a service requires
successful restoration under failure conditions (e.g., High, Normal, Best
Effort).

Sven>> I agree with you that reservation priority is needed and I believe
that the proposals that you mention are probably a good way of implementing
it if you want to support it. What I am not sure about is whether it should
be part of the QoS NSLP. Even if it is common to multiple QoS models, it
still would only affect the Resource Management Function (RMF) (unlike the
message priority) which makes it outside of the QoS NSLP scope in my
opinion. Anyway, I think it is good that the concept and the potential
solution matures in the QoS model draft team. We can decide when we see
what it turned out to be whether we still want to put it in the QoS NSLP
spec.

Regards,
Jerry

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 31 Mar 2004 15:47:15 +0200

Hi all

I agree with Attila on this!

best regards,
Georgios

----- Original Message ----- 
From: "Attila Báder (IJ/ETH)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Sent: Monday, March 29, 2004 11:31 AM
Subject: RE: [NSIS] Plans for the protocol drafts

> Hi Sven,
>
> If WG decides that we need reservation priority, I think, it is common
feature for QoS models, so it should be defined in QoS NSLP.
> This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the
message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any such
corruption, interception, amendment, tampering or viruses or any
consequences thereof.