Subject: [ANCP] ANCP Multicast Capability Negotiation

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Fri, 7 Nov 2008 16:12:47 +0100

Hi,

<ietf-ancp-protocol-04> defines one multicast related Capability Type:
	* Transactional-Multicast = 0x003

<draft-lefaucheur-ancp-mc-extensions-00> defines two new multicast  
related Capability Types:
	* Multicast Admission Control without Bandwidth Delegation = 0x05
	* Multicast Admission Control without and with Bandwidth Delegation =  
0x06

Philippe correctly pointed out that the relationship between the 2 new  
Capability Types and the existing one needs clarification. Here are  
some clarifications:

* "the Multicast Admission Control without Bandwidth Delegation" has  
been built on top of the "Transactional Multicast". Indeed, the  
Multicast Admission Control message flows is a strict superset of the  
Transactional Multicast message flow (eg uses same Multicast  
Replication Control message from NAS to AN + response).

* To make this clearer I would propose that :

	o the three multicast related capabilities are renamed into something  
like:

			* Multicast Capability Set 1 = 0x03
				--> supports Transactional Multicast
				--> supports Multicast Replication Message + Multicast Status  
message

			* Multicast Capability Set 2 = 0x05
				--> supports Transactional Multicast & Admission Control Without  
Bandwidth Delegation
				--> supports Multicast Replication Message + Multicast Status  
message + Multicast Admission Control message

			* Multicast Capability Set 3 = 0x06
				--> supports Transactional Multicast & Admission Control Without  
Bandwidth Delegation & Admission Control With Bandwidth Delegation
				--> supports Multicast Replication Message + Multicast Status  
message + Multicast Admission Control message + TBD messages related  
to Bandwidth Delegation

  	o Since the capability negotiation mechanism defined in ietf ancp- 
protocol-operates by elimination of capabilities not supported by one  
of the two ANCP ends, we need to specify that an ANCP node advertising  
a Multicast Capability Set N, MUST also advertise  Multicast  
Capability Set M (where M < N). For example:
		* a node supporting Transactional Multicast & Admission Control  
Without Bandwidth Delegation, will advertise Multicast Capability Set  
1 and Multicast Capability Set 2
		*  node supporting Transactional Multicast, will advertise Multicast  
Capability Set 1
this way the two nodes will eventually agree on Multicast Capability  
Set 1.

Comments welcome.

Francois

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 13 Nov 2008 11:23:25 +0100

Hi Francois and All,
     your proposal for the different sets of capabilities and dependencies makes sense to me in principle, but I think there is an additional point to be clarified as far as capability value to be used for multicast use-case.
The ancp protocol draft currently specifies Capability Type 0x03 for Transactional-Multicast, but I am afraid that this value still refers to some pre-standard implementations of ancp protocol for multicast.

My question for the WG is: should we use  Capability Type 0x03 for the multicast extensions defined in draft-ancp-mc-extensions-00.txt and now integrated in section 5.4.5 or do we need to define a new Capability Type for these extensions and leave 0x03 for pre-standard multicast implementantions?

Thanks,
Regards,
Roberta

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Friday, November 07, 2008 4:13 PM
To: [email-masked]
Cc: Francois Le Faucheur IMAP; Philippe (pchamp) Champagne; Maglione Roberta; Tom Taylor
Subject: ANCP Multicast Capability Negotiation

Hi,

Comments welcome.

Francois

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Sat, 15 Nov 2008 19:12:29 -0500

We may want to consider the option of defining capability types only for
the main use-cases and then defining sub-capabilities for each use-case.
The sub-capabilities could be a bit-vector contained in the data (value)
portion of the capability TLV. This ensures if a top level capability
(such as transactional multicast) is not advertised, then dependent
capability (such as CAC or bandwidth delegation) are automatically
precluded.

-Sanjay

-----Original Message-----
From: Maglione Roberta [mailto:[email-masked]] 
Sent: Thursday, November 13, 2008 5:23 AM
To: 'Francois Le Faucheur IMAP'; [email-masked]; Sanjay Wadhwa
Cc: Philippe (pchamp) Champagne; Tom Taylor; 'Wojciech Dec (wdec)'
Subject: RE: ANCP Multicast Capability Negotiation

Hi Francois and All,
     your proposal for the different sets of capabilities and
dependencies makes sense to me in principle, but I think there is an
additional point to be clarified as far as capability value to be used
for multicast use-case.
The ancp protocol draft currently specifies Capability Type 0x03 for
Transactional-Multicast, but I am afraid that this value still refers to
some pre-standard implementations of ancp protocol for multicast.

My question for the WG is: should we use  Capability Type 0x03 for the
multicast extensions defined in draft-ancp-mc-extensions-00.txt and now
integrated in section 5.4.5 or do we need to define a new Capability
Type for these extensions and leave 0x03 for pre-standard multicast
implementantions?

Thanks,
Regards,
Roberta

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Friday, November 07, 2008 4:13 PM
To: [email-masked]
Cc: Francois Le Faucheur IMAP; Philippe (pchamp) Champagne; Maglione
Roberta; Tom Taylor

Hi,

<draft-lefaucheur-ancp-mc-extensions-00> defines two new multicast
related Capability Types:
        * Multicast Admission Control without Bandwidth Delegation =
0x05
        * Multicast Admission Control without and with Bandwidth
Delegation =
0x06

        o the three multicast related capabilities are renamed into
something
like:

                        * Multicast Capability Set 1 = 0x03
                                --> supports Transactional Multicast
                                --> supports Multicast Replication
Message + Multicast Status
message

                        * Multicast Capability Set 2 = 0x05
                                --> supports Transactional Multicast &
Admission Control Without
Bandwidth Delegation
                                --> supports Multicast Replication
Message + Multicast Status
message + Multicast Admission Control message

                        * Multicast Capability Set 3 = 0x06
                                --> supports Transactional Multicast &
Admission Control Without
Bandwidth Delegation & Admission Control With Bandwidth Delegation
                                --> supports Multicast Replication
Message + Multicast Status
message + Multicast Admission Control message + TBD messages related
to Bandwidth Delegation

        o Since the capability negotiation mechanism defined in ietf
ancp-
protocol-operates by elimination of capabilities not supported by one
of the two ANCP ends, we need to specify that an ANCP node advertising
a Multicast Capability Set N, MUST also advertise  Multicast
Capability Set M (where M < N). For example:
                * a node supporting Transactional Multicast & Admission
Control
Without Bandwidth Delegation, will advertise Multicast Capability Set
1 and Multicast Capability Set 2
                *  node supporting Transactional Multicast, will
advertise Multicast
Capability Set 1
this way the two nodes will eventually agree on Multicast Capability
Set 1.

Comments welcome.

Francois

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received the
message in error, be informed that any use of the content hereof is
prohibited. Please return it immediately to the sender and delete the
message. Should you have any questions, please contact us by replying to
[email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: "Philippe Champagne (pchamp)" <[email-masked]>
Date: Mon, 17 Nov 2008 05:37:19 -0800

That's also an idea a brought up to Francois in a private exchange.
Francois noticed that this might get complicated for the 2 peers to
negotiate a common support. Perhaps evaluating this against a few worst
case scenarios could give us clues if a sub-capability could be
considered.
I would imagine the best negotiation method would be to have this
sub-capability run in parallel with the main one (well as long as the
main one still contains multicast).  And if the 2 peers cannot get on a
common ground on sub capability, then the multicast top level capability
is also removed (getting back to what you said in the last sentence).

>From: Sanjay Wadhwa [mailto:[email-masked]] 
>Sent: Saturday, November 15, 2008 7:12 PM
>To: Maglione Roberta; Francois Le Faucheur (flefauch); [email-masked]
>Cc: Philippe Champagne (pchamp); Tom Taylor; Wojciech Dec (wdec)
>We may want to consider the option of defining capability 
>types only for the main use-cases and then defining 
>sub-capabilities for each use-case.
>The sub-capabilities could be a bit-vector contained in the 
>data (value) portion of the capability TLV. This ensures if a 
>top level capability (such as transactional multicast) is not 
>advertised, then dependent capability (such as CAC or 
>bandwidth delegation) are automatically precluded.
>
>-Sanjay
>