Subject: Re: [NSIS] QoS NSLP Abstract API: feedback wanted

From: Hong Cheng <[email-masked]>
Date: Fri, 01 Jun 2007 13:18:33 +0800

Hi Jukka,

I have just browsed through the API definitions. It seems like a good
start. However, I have a few comments and questions:

- "filter" in both sendrmf() and recvrmf() is defined as "PACKET
CLASSIFIER" (defined in 5.1.3.5). But, the current definition for
"PACKET CLASSIFIER" only contains several flags. It obviously does not
provide the necessary filter information. Shouldn't this parameter also
includes the MRI information, or be the real filter (with addr, port, etc)?

- "Features_in" in sendrmf() includes a "synchronization_required"
trigger. Is this necessary, since all the information, e.g.
BOUND_SESSION_ID (and corresponding binding_code) is also passed in
sendrmf()?

- From the description of the recvrmf() at A.2, it seems that it is
always the RMF decide what messages to be sent out. Does the NSLP itself
has any state managed or capable of deciding what message to sent?

- Related to above, is there a way for the NSLP to influence/regulate
what to be returned by the RMF (i.e. what message in the recvrmf()
should follow a sendrmf())? From the API, it seem not. Or, this is
purely left to RMF to decide?

- Suggest to add a qne_type of "CRN" in config().

- Should the qne_type be configured from NSLP to RMF or from RMF to
NSLP? At least the QNR, QNE, and CRN discovery should be carried out at
NTLP or NSLP layer. If the config() is just one way, would it imply the
QNR/CRN discovery is carried out in RMF? And for QNI, QNI_Ingress or
QNI_Egress, they probably should be from RMF to NSLP.

- What is the use of state_type in the config()? Would the NSLP behavior
change because of this parameters? What kind of state if left for NSLP
to maintain, as from the recvrmf() definition, it seems all that will be
done at RMF, and NSLP is just to assemble/dissemble NSLP messages.

cheers

Cheng Hong

Jukka MJ Manner wrote:
> Dear all,
> 
> The last thing before a WGLC is to specify the abstract API for the QoS 
> NSLP. The current spec has our initial proposal, which after a fresh 
> re-read looks quite ok to me. Maybe some examples on the usage would help 
> clarify the operation but in general the API looks quite good.
> 
> What do people feel? Is the abstract and informational API good enough at 
> this stage to go for WGLC? Or do we want to change it in some way?
> 
> Regards,
> Jukka
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 
> 

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 1 Jun 2007 10:44:37 +0300 (EEST)

Hi,

thanks for the feedback. Some answers below.

> includes the MRI information, or be the real filter (with addr, port, etc)?

[JM]: Good point, will change to say in general "packet classifier" and 
not refer to the object itself, which is useless.

> BOUND_SESSION_ID (and corresponding binding_code) is also passed in

[JM]: Maybe you are right, sounds like the same information is passed 
twice.

> has any state managed or capable of deciding what message to sent?

[JM]: Well, let's think about it a while.
* QUERY is always forwarded when the QNE code gets an answer from the RMF. 
  So, this is RMF triggered.

* RESERVE: same thing for initial reservation. Refreshes are hop-by-hop, 
  so again, triggered by the RMF. A tearing RESERVE might be done with a 
  "fast path" where an incoming tear causes a notification to the RMF, and 
  simultaneously a QNE code builds a tear to be sent out. However, this 
  might be an optimzation. I think this could also be done based on a 
  trigger from the RMF saying "state removed successfully".

* NOTIFY and RESPONSE: these may be sent without consulting the RMF, if 
  the notification does not involve the RMF.

So, all messages that carry a QSPEC would in my mind be forwarded after 
the RMF has done some magic with the incoming message. And since this may 
take an unspecified time, an implementation should not try to block and 
wait for a message from the RMF, but rather be prepared to get 
asynchronous triggers causing NSLP messages to be sent out.

> purely left to RMF to decide?

[JM]: This depends heavily on the QoS Model. Say we have an RMD-like QOSM, 
then at ingress and egress we have different operation that elsewhere in 
the network, or outside the domain. Also, e.g. a RESERVE may cause a 
RESPONSE to be sent out, or a new RESERVE. I think this should be left to 
the RMF to decide.

[JM]: In general, I tend to view the RMF as a separate node to communicate 
with. Its like

[QI] --- [QNE1]-[RMF]-[QNE1] --- [QNE2]-[RMF]-[QNE2] --- ... 

When a QNE receives a packet, it usually "sends" it to the RMF, and 
forgets about it. Later, the RMF "sends" a message back to the QNE, 
instructing to send a message out.

> - Suggest to add a qne_type of "CRN" in config().

[JM]: Where and how would you use it? The config call is meant for setting 
static information at startup.

> QNI_Egress, they probably should be from RMF to NSLP.

[JM]: CRN discovery is carried at the NSLP level based on a trigger by the 
NTLP. Only the NSLP is able to figure out if the next hop has changed, but 
needs to hint from the NTLP to start looking at that. Maybe I don't follow 
your idea...?

> done at RMF, and NSLP is just to assemble/dissemble NSLP messages.

[JM]: the state is mainly used currently in RMD, but is a generic 
static functionality of a QNE.

BR, Jukka

---

From: Hong Cheng <[email-masked]>
Date: Fri, 01 Jun 2007 16:27:32 +0800

Hi Jukka,

Thanks for your answer. Some further comments inline.

<snip>
> instructing to send a message out.

If I understand this correctly, it means the NSLP layer would not need
to keep any state about the messages received (QNE1 before and after the
RMF does not need to related the two messages), and everything is kept
in the RMF. This would be OK. What you have described above probably
should be included into the draft also (as the suggested
example/explanation).

> static information at startup.

Sorry. Did not notice that the config() is meant for static info for
startup (only saw the text "the config() function is meant for
configuring per-session settings").

However, I am still a bit curious about the types like QNR/QNE/QNI.
Especially for the QNR, how could it be a static configuration
(considering the path extension in 3.2.11.1)?

> needs to hint from the NTLP to start looking at that. Maybe I don't follow 

Yes. That is what I thought the CRN discovery operation should be. But,
after the NSLP discovered the QNE is a CRN, shouldn't it inform the RMF
about it? The current API does not address this information. Or, by
saying "NSLP" you are really referring to RMF?

I was thinking maybe the config() could be used for that purpose (by
making it two-way, i.e. allow the NSLP to call it). But obviously it is
not meant for that use.

> static functionality of a QNE.

Meaning the NSLP will form different formats of the NSLP message (maybe
different flags set) based on this parameter (given the same recvrmf()
contents)? It sounds logical if that is the case.

cheers

Cheng Hong

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 1 Jun 2007 12:01:38 +0300 (EEST)

Hi,
some comments back inline.

> should be included into the draft also (as the suggested

Yes, and no. The NSLP layer must keep some NSLP state related to the 
session. But the main point is that the messaging with the RMF should be 
asynchronous, not synchronous. The NSLP stores state info based on the 
SID, and messages from the RMF should indicate which SID is being 
triggered for the NSLP to be able to send the correct message on the right 
direction.

> (considering the path extension in 3.2.11.1)?

You are right that the type may be a bit vague, and can change between 
sessions. Still, being a CRN is in mind a different issue.

> making it two-way, i.e. allow the NSLP to call it). But obviously it is

I don't think the RMF should be bothered by mobility in general. You only 
tell the RMF whether the interfaces for the session have changed, or 
whether a new reservation is needed, or an existing torn down. The RMF 
just sees those triggers from the NSLP code, and the reason doesn't need 
to be propagated, I think.

> contents)? It sounds logical if that is the case.

Yes, see Section 4.6 where aggregation is discussed. The stateless 
QNE is one specific type of QNE inside a certain domain, e.g., an RMD 
domain.

Jukka

---

From: Hong Cheng <[email-masked]>
Date: Fri, 01 Jun 2007 17:40:21 +0800

Hi Jukka,

Please see below one issue. Other than that, I don't have further
questions :)

> to be propagated, I think.

This might as well work. However, it would mean that the NSLP would
generate some messages by itself (instead of triggered by RMF).

For example, when receiving a new RESERVE message with the REPLACE flag,
a normal QNE and a CRN should behave differently. (The CRN should
generate another message to be sent to the old path). So, if RMF is not
aware of the difference, the NSLP at the CRN should be the one that
generates the extra messages towards the old path.

This might be a bit inconsistent in the operation description(though it
is not a bit problem for implementation).

cheers

Cheng Hong

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 1 Jun 2007 12:54:34 +0300 (EEST)

Hi,
A valid point. I haven't figured out all the usage examples of the API, in 
various complex cases. It might well be that there are cases, where the 
API is not enough.

I would propose that I make the small modifications we talked today, and 
we go with that version into the WGLC.

Jukka

---

From: Hong Cheng <[email-masked]>
Date: Fri, 01 Jun 2007 18:21:05 +0800

Hi,

I am OK with that. Let's see what others have to say about it.

cheers

Cheng Hong

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Fri, 1 Jun 2007 14:04:37 +0200

Dear all, 

from the minutes of the IETF in Prague I assumed the API would be split into a RMF API and an application API. Isnt this still planned?

Cornelia 

> -----Ursprüngliche Nachricht-----
> Von: ext Jukka MJ Manner [mailto:[email-masked]] 
> Gesendet: Donnerstag, 31. Mai 2007 21:37
> An: NSIS Working Group
> Betreff: [NSIS] QoS NSLP Abstract API: feedback wanted
> 
> 
> Dear all,
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 1 Jun 2007 15:45:02 +0300 (EEST)

Hi,

I don't know of any application API. The main point was to try to split 
the work into a simple and advanced RMF APIs, but looking at the current 
spec, it doesn't need to be split.

Jukka

---

From: Bernd Schloer <[email-masked]>
Date: Mon, 04 Jun 2007 20:00:01 +0200

Hi,

I have a proposal for an API between the QoS NSLP and the local application:

1. From local application to QoS NSLP:

    reserve_qos(tmod, dst-addr, [dst-port], [dst-prefix], [src-addr],
                [src-port], [src-prefix], [reservation-style],
                [authorization info]) -> SessionID

       The local application initiates a reservation by using the reserve_qos()
       command. It includes a traffic description represented by a TMOD parameter
       and the destination address.

       Optional parameters are destination port, destination prefix, source address,
       source port, source prefix, a boolean whether sender or receiver initiated
       reservation will be used and authorization info.

       If source and/or destination prefix are omitted default values will be used.
       The default reservation style is sender initiated reservation.

       If the source address is omitted the IP address from the outgoing interface
       is taken. This parameter is needed on a host with multiple interfaces.

       The QoS NSLP returns immediately the generated SessionID.

    teardown_qos(SessionID)

       This call removes the reservation state. The parameter is the SessionID.

2. From QoS NSLP to local application:

    recv_qos(SessionID, status)

       The QoS NSLP provides status information to the client using the command
       recv_qos(). The status information is taken from the InfoSpec object and
       informs the local application about the success of the requested reservation
       or teardown.

What do you think of it?

Best regards,
Bernd

Jukka MJ Manner wrote:
>>------------------------------------------------------------------------
>>

---

From: Hong Cheng <[email-masked]>
Date: Tue, 05 Jun 2007 17:19:07 +0800

Hi Bernd,

Based on the Figure 2 of the QoS NSLP draft, the Local Application is
interfacing with the Resource Management instead of the QoS NSLP block.
So, is this API proposed for that interface?

cheers

Cheng Hong

Bernd Schloer wrote:
>> I don't know of any application API. The main point was to try to
>> split the work into a simple and advanced RMF APIs, but looking at the
>> current spec, it doesn't need to be split.
>>
>> Jukka
>>
>>> from the minutes of the IETF in Prague I assumed the API would be
>>> split into a RMF API and an application API. Isnt this still planned?
>>>
>>> Cornelia
>>>
>>>> Von: ext Jukka MJ Manner [mailto:[email-masked]] Gesendet:
>>>> Donnerstag, 31. Mai 2007 21:37
>>>> An: NSIS Working Group
>>>> The last thing before a WGLC is to specify the abstract API for the
>>>> QoS NSLP. The current spec has our initial proposal, which after a
>>>> fresh re-read looks quite ok to me. Maybe some examples on the usage
>>>> would help clarify the operation but in general the API looks quite
>>>> good.
>>>>
>>>> What do people feel? Is the abstract and informational API good
>>>> enough at this stage to go for WGLC? Or do we want to change it in
>>>> some way?
>>>>
>>>> Regards,
>>>> Jukka
>>>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 5 Jun 2007 11:36:51 +0200

Hi Bernd

I think that your proposal is already covered by the current API!

Is it really needed to split the API in:

API for RMF <---> QoS-NSLP
And
API for Application <------> QoS-NSLP

Or is it enough to just change the name of the current 
version of the API as follows:

From: Appendix A. Abstract NSLP-RMF API

Into: Appendix A. Abstract NSLP-RMF/Application  API

And also change:

From: A.1 Triggers from QOS-NSLP towards RMF 

INTO: A.1 Triggers from QOS-NSLP towards RMF/Application

And also change:

From:

A.2 Triggers from RMF/QOSM towards QOS-NSLP

INTO:

A.2 Triggers from RMF/application towards QOS-NSLP

Best regards,
Georgios

> -----Original Message-----
> From: Hong Cheng [mailto:[email-masked]] 
> Sent: dinsdag 5 juni 2007 11:19
> To: Bernd Schloer
> Cc: Kappler, Cornelia; Jukka MJ Manner; NSIS Working Group
> Subject: Re: AW: [NSIS] QoS NSLP Abstract API: feedback wanted
> 
> Hi Bernd,
> 
> Based on the Figure 2 of the QoS NSLP draft, the Local 
> Application is interfacing with the Resource Management 
> instead of the QoS NSLP block.
> >       command. It includes a traffic description 
> represented by a TMOD 
> > parameter
> >       source port, source prefix, a boolean whether sender 
> or receiver 
> > initiated
> >       If source and/or destination prefix are omitted 
> default values 
> > will be used.
> >       The QoS NSLP provides status information to the 
> client using the 
> > command
> >       informs the local application about the success of 
> the requested 
> > reservation
> >       or teardown.
> > 
> > 
> > What do you think of it?
> > 
> > Best regards,
> > Bernd
> > 
> > 
> > Jukka MJ Manner wrote:
> >> Hi,
> >>
> >> split the work into a simple and advanced RMF APIs, but looking at 
> >> the current spec, it doesn't need to be split.
> >>
> >> Jukka
> >>
> >>>> fresh re-read looks quite ok to me. Maybe some examples on the 
> >>>> usage would help clarify the operation but in general 
> the API looks 
> >>>> quite good.
> >>>>

---

From: Bernd Schloer <[email-masked]>
Date: Tue, 05 Jun 2007 18:54:16 +0200

Hi,

yes, this API is proposed for the Resource Management.

Best regards,
Bernd

---

From: Bernd Schloer <[email-masked]>
Date: Tue, 05 Jun 2007 21:51:20 +0200

Hi,

for network management (e.g. initiating a tunnel, handle aggregate reservations)
it is useful to have full control about the message types, objects and flags. For
a local application that just wants to make a reservation, a subset of theese
features would be enough. But it's not really needed to split the API since the
current one covers all functionality.

Best regards,
Bernd

Georgios Karagiannis wrote:
>>>>>split into a RMF API and an application API. Isnt this 
>>
>>still planned?
>>
>>>>>Cornelia
>>>>>
>>>>>
>>Gesendet:
>>>>>>The last thing before a WGLC is to specify the abstract 
>>
>>API for the 
>>
>>>>>>QoS NSLP. The current spec has our initial proposal, 
>>
>>which after a 
>>
>>>>>>enough at this stage to go for WGLC? Or do we want to 
>>
>>change it in 
>>
>>>>>>some way?
>>>>>>
>>>>>>Regards,
>>>>>>Jukka
>>>>>>
>>--------------------------------------------------------------------
>>
>>>>>----
>>>>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 6 Jun 2007 10:42:31 +0200

Hi Bernd

Okay, but does this mean that you are satisfied with the current version of
the API, or 
would you like to see an additional section into the draft that describes
the 
API between user application and QoS-NSLP?

Best Regards,
Georgios

> From: Bernd Schloer [mailto:[email-masked]] 
> Sent: dinsdag 5 juni 2007 21:51
> To: Georgios Karagiannis
> Cc: 'Hong Cheng'; 'Kappler, Cornelia'; 'Jukka MJ Manner'; 
> 'NSIS Working Group'
> for network management (e.g. initiating a tunnel, handle 
> aggregate reservations) it is useful to have full control 
> about the message types, objects and flags. For a local 
> application that just wants to make a reservation, a subset 
> of theese features would be enough. But it's not really 
> needed to split the API since the current one covers all 
> functionality.
> 
> Best regards,
> Bernd
> 
> 
> Application is 
> >>>      Optional parameters are destination port, 
> destination prefix, 
> >>>source address,
> >>>      This call removes the reservation state. The 
> parameter is the 
> >>>SessionID.
> >>>
> >>>
> >>>      recv_qos(). The status information is taken from the 
> InfoSpec 
> >>>object and

---

From: Andrew McDonald <[email-masked]>
Date: Wed, 06 Jun 2007 17:34:53 +0100

Hi Jukka,

> spec, it doesn't need to be split.

It was a proposal we discussed, and you presented in the slides at 
Prague. Some discussion is also mentioned in the meeting minutes.
See the last couple of slides of:
http://www3.ietf.org/proceedings/07mar/slides/nsis-0.pdf
The minutes say:
> api:
> probably needs to parts
> rmf api
> application api
> 
> dave oran:
> this is one way to look at it
> the direction is different for the two
> appplication to nslp
> nslp to rmf
> key point is that there are two parts and the directions are different

There were two general ideas we discussed (I think we discussed (a) more 
off-line than in the WG meeting):
a) simple + complex (rich) API - provide an API to do basic things, and 
then extra bits to do clever things
b) RMF + application APIs - replace the current API proposal to change 
from the model of application/NSLP interaction being done purely via the RMF

I don't think (a) is particularly helpful in simplifying things overall. 
In particular, it doesn't help in more precisely defining the interface 
between the NSLP and RMF (which is one of the main points of the 
abstract API). The problem is that application/NSLP interactions that 
really have nothing to do with the RMF are all being done via the RMF.

(b) provides a more logical structure since it makes it clear whether 
the RMF is really involved or not. (In the (a) case it often has to 
forward opaque data between the application and NSLP.)

Andrew

---

From: Hong Cheng <[email-masked]>
Date: Thu, 07 Jun 2007 10:06:41 +0800

Hi Andrew,

> from the model of application/NSLP interaction being done purely via the

Does this mean a (RMF-NSLP API) + a (Application-NSLP API), or a
(RMF/Application-NSLP API) as mentioned by Georgios earlier?

> forward opaque data between the application and NSLP.)

In the b) case, does the Application still have an interface to the RMF,
or  must it go via the NSLP now? Maybe a new architecture diagram will
help to understand the proposal better (obviously, it is different from
Figure 2 in the draft now).

Also, would like to know in the proposal what would be the
states/information managed by the NSLP. Jukka provided an operation
model for the current API and that seems OK. Similar explanation would
be helpful. For example, would the NSLP now need to forward opaque data
between Application and RMF?

cheers

Cheng Hong

---

From: Bernd Schloer <[email-masked]>
Date: Thu, 07 Jun 2007 12:49:16 +0200

Hi,

please see inline.

regards,
Bernd

> (RMF/Application-NSLP API) as mentioned by Georgios earlier?

 From my understanding the b) case means a (RMF-NSLP API) + a
(Application-NSLP API).

> Figure 2 in the draft now).

In the b) case triggers from the client application could be treated like
incoming messages over the network. The architecture diagram would look
like

   Local Appl.            Network
      ^                 Management
      I                     ^
      I                     I
      v                     v
   QoS NSLP <---------> Resource
      ^                Management
      I
      v
    NTLP
  processing

---

From: Andrew McDonald <[email-masked]>
Date: Fri, 08 Jun 2007 17:49:37 +0100

>  From my understanding the b) case means a (RMF-NSLP API) + a

Yes.

>   QoS NSLP <---------> Resource

Yes. (And, yes, I agree this deviates from the 'model' in fig 2. 
However, I don't believe this involves any changes outside the API. i.e. 
no protocol changes.)

Andrew

---

From: David Palma <[email-masked]>
Date: Sun, 10 Jun 2007 21:23:02 +0100

Hi all,

I'm from the University of
Coimbra and I agree with the several APIs approach.
In our current implementation , the architecture is defined as shown
bellow:

+---------------+

|     Local     |

|Applications or|

|Management (e.g|

|for aggregates)|

+---------------+

^

V

V

+---------+
+----------+             +----------+

| Policy
|               | QoS NSLP |             | Resource |

| Control
|<<<<<<<<>>>>>>>|Processing|<<<<<<>>>>>>>|Management|

+---------+               +----------+             +----------+

.  ^   |

|  V   .

+----------+

|   NTLP   |

|Processing|

+----------+

(theres' a third API between
QoS NSLP and the Policy
Control)

Best Regards,

David Palma

UoCoimbra

PS: sorry for the late contribution

Andrew McDonald wrote:

Bernd
Schloer wrote:

Hong Cheng wrote:

Regarding the proposal:

b) RMF + application APIs - replace the
current API proposal to change

from the model of application/NSLP interaction being done purely via
the

RMF

(Application-NSLP API).

Yes.

(b) provides a more logical structure
since it makes it clear whether

In the b) case, does the Application still have an interface to the
RMF,

In the b) case triggers from the client application could be treated
like

like

Local Appl.            Network

^                 Management

I                     ^

I                     I

v                     v

^                Management

I

v

NTLP

processing

Yes. (And, yes, I agree this deviates from the 'model' in fig 2.
However, I don't believe this involves any changes outside the API.
i.e. no protocol changes.)

Andrew

nsis mailing list

[email-masked]

---

From: Bernd Schloer <[email-masked]>
Date: Wed, 13 Jun 2007 21:03:22 +0200

Hi,

> model for the current API and that seems OK.

I also think that the current API is ok and I withdraw my proposal.

Best regards,
Bernd