Subject: [ANCP] Sub Capability Negotiation

From: "Aniruddha A (anira)" <[email-masked]>
Date: Tue, 28 Apr 2009 10:24:07 +0530

Hi All,
 
In draft-lefaucheur-ancp-mc-extensions-01, we have a non boolean
capability - Multicast
with sub-capability negotiation. The value of the TLV is 1 byte, so
there has to be padding
to align it to 32-bit boundary, in that case, I want to know how the
sub-capabilities are to be 
encoded, i.e., will we have the value in LSB (padding followed by value)
or MSB (value followed
By padding) ?

With sub-capabilities, I would like to propose that we use 1 bit for
each value, and change the
Length to 4 bytes to simplify encode/decode.

i.e, From draft-lefaucheur-ancp-mc-extensions-01, Section 5:

	Capability Data (1 byte): The following values are defined:
         +  0x00: Reserved
         +  0x01: "Transactional Multicast"
         +  0x02: "Transactional Multicast" and "Multicast Admission
            Control without Bandwidth Delegation"
         +  0x03: "Transactional Multicast", "Multicast Admission
            Control without Bandwidth Delegation" and "Multicast
            Admission Control with Bandwidth Delegation"
         +  other values: Reserved
 
 Instead, use:

         +  0x00: Reserved
         +  0x01: "Transactional Multicast"
         +  0x02: "Multicast Admission Control without Bandwidth
Delegation"
         +  0x04: "Multicast Admission Control with Bandwidth
Delegation"

 If the AN has all 3 Multicast sub-capabilities, then the sub-capability
value will be 0x07

--
Regards,
Aniruddha. A

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Apr 2009 09:34:47 -0400

That makes sense.

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 28 Apr 2009 16:03:01 +0200

Hi Aniruddha,

> If the AN has all 3 Multicast sub-capabilities, then the sub- 

This scheme would seem natural if the capabilities were independent.  
However, here the capabilities are natural supersets of each other. eg  
a device that supports "Multicast Admission Control with Bandwidth  
Delegation" ALWAYS also supports "Multicast Admission Control without  
bandwidth delegation". A device that supports "Multicast Admission  
Control without bandwidth delegation" ALWAYS also support  
"Transactional Multicast".
Going with a 1bit-per-subcapability scheme would mean we'd have to  
"deal" with all the invalid/undesired combinations eg 0x02 should  
actually be illegal, 0x04 and 0x06 also.
The only legal combinations would be 0x01, 0x03 and 0x07.

This seems to introduce unnecessary cases to deal with. No?
Do you see that it buys us anything?

Thanks
Francois

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Apr 2009 10:08:46 -0400

Could we not structure the capabilities to be more independent? I'm not sure the 
dependencies are as fixed as you see them.

Francois Le Faucheur IMAP wrote:
> However, here the capabilities are natural supersets of each other. eg a 
> device that supports "Multicast Admission Control with Bandwidth 
> Control without bandwidth delegation" ALWAYS also support "Transactional 
> Multicast".

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 28 Apr 2009 16:29:28 +0200

On 28 Apr 2009, at 16:08, Tom Taylor wrote:

> Could we not structure the capabilities to be more independent? I'm  
> not sure the dependencies are as fixed as you see them.

Can you picture an AN that can support "Multicast Admission Control"  
but cannot support "transactional Multicast" (considering the message  
flow of the latter is a subset of the former)?
Do you have in mind a specific use case for independent subcapabilities?

It seems to me that an ANCP peer (at least on NAS side) needs to  
implement a given behavior to react properly to each possible  
subcapability combination from its peer. So the more combinations, the  
more behaviors to implement. We can allow this if it buys us  
something, but at this stage I am not clear as to what it would achieve.

Francois

>> This scheme would seem natural if the capabilities were  
>> independent. However, here the capabilities are natural supersets  
>> of each other. eg a device that supports "Multicast Admission  
>> Control with Bandwidth Delegation" ALWAYS also supports "Multicast  
>> Admission Control without bandwidth delegation". A device that  
>> supports "Multicast Admission Control without bandwidth delegation"  
>> ALWAYS also support "Transactional Multicast".

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Apr 2009 10:49:09 -0400

I'll do an analysis and see what can be put together. I do realize there is 
reuse, but I don't think it is complete.

Francois Le Faucheur IMAP wrote:
> Can you picture an AN that can support "Multicast Admission Control" but 
> cannot support "transactional Multicast" (considering the message flow 
> of the latter is a subset of the former)?
> more behaviors to implement. We can allow this if it buys us something, 
> but at this stage I am not clear as to what it would achieve.
> 
> Francois
> 
>>
>>
>>> However, here the capabilities are natural supersets of each other. 
>>> eg a device that supports "Multicast Admission Control with Bandwidth