Subject: Re: [ANCP] ANCP Multicast Admission Control

From: Tina TSOU <[email-masked]>
Date: Sun, 03 Feb 2008 18:59:39 +0800

Hi Sven, Francois et al,
Sorry not replying earlier. I was chairing ITU-T Q.5/11 meeting in Seoul last week, and am in Shenzhen now, and will spend my Spring Festival holidays in Korea next week without internet access. 

I would let Roberta to reply further if needed:)

We support Sven's texts. Minor refinement might be needed.

Thanks for all your good comments:) Please see my comments below in line demarked with [Tina: ...].

B. R.
Tina
  ----- Original Message ----- 
  From: OOGHE Sven 
  To: Francois Le Faucheur IMAP ; Tina TSOU ; Maglione Roberta 
  Cc: [email-masked] 
  Sent: Thursday, January 31, 2008 8:19 PM
  Subject: RE: [ANCP] ANCP Multicast Admission Control

  Hi Francois,

  For clarification: The text concerning PS-->AN and PS-->NAS-->AN
  interactions is based on the proposal sent by Tina and Roberta in
  http://www1.ietf.org/mail-archive/web/ancp/current/msg00446.html. At
  that point in time, there was no feedback on the proposal yet.

  I see you have concerns with the approach. Tina or Roberta, can you
  share your point of view?

  Regards,
  Sven

  -----Original Message-----
  From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
  Sent: donderdag 31 januari 2008 12:37
  To: DE CNODDER Stefaan
  Cc: Francois Le Faucheur IMAP; OOGHE Sven; [email-masked]
  Subject: Re: [ANCP] ANCP Multicast Admission Control

  Hi Stefaan,

  On 30 Jan 2008, at 18:32, Stefaan DE CNODDER wrote:

  >
  > Francois,
  >
  >> In addition, it is not clear to me how useful these additional models

  >> are. It also raises a number of questions. For example, if the Policy

  >> Server wants to query the AN, should it do so via the NAS instead of

  >> directly to AN?
  [Tina: Some slight preference is to via the NAS, as there are many ANs.
  Via NAS may reduce the connections. From the point of view of AN, it may 
  like single interface to NAS rather than one interface to NAS and the other
  interface to PS.]

  >
  > Both are possible, is there any preferred way according to you?
  >
  >  Also, to be able to perform complete Video CAC, the  AN
  >> would have to maintain user policy information (eg what is the   
  >> fraction of line bandwidth that can be used for Video for that   
  >> subscriber at that point in time considering the current DSL train  
  >> rate). Is this in line with current ANCP model? 
  [Tina: Raising this scenario is to implement unciast CAC through ANCP. 
  AN only maintains bandwidth information, no user policy information.]

  >> how is user info made available to AN?
  [Tina: In AN or PS, manually configure multicast and unicast user bandwidth.]

  >> What impact does all this have on ANCP?
  [Tina: No impact. It expand the ANCP scenario, ANCP can support
   unicast/multicast CAC.]

  >> While we can start discussing those questions and the usefulness of  
  >> such a model, IMHO this should not delay progress of current ANCP  
  >> documents.
  >> So in short, I do _not_ support the additional text below relating to

  >> the introduction of the new additional model (PS-->NAS-->AN) and  
  >> corresponding additional ANCP requirements.
  >
  > does this mean that you prefer PS-->AN?

  No.
  I am not expressing any preference for PS-->AN over PS-->NAS-->AN There
  seemed to be a lot of additional text proposed below relating to
  PS-->NAS-->AN as this involves ANCP more heavily. And I am simply
  stating that I do not support adding such text.

  The current framework defines PS-->AN and PS-->NAS-->AN as out of scope
  for now ("It is therefore beyond the scope of this document.") and I
  recommend we do not change scope at this stage if we want to have a
  first version of the ANCP protocol in the targeted timeframe.  
  Those can always be easily added to the scope/protocol once there is
  stronger consensus/understanding or their applicability in the group and
  when the WG has completed the first base protocol spec.

  Francois

  > To be honest, for me both options are valid.  Is there any specific 
  > reason why you would not like to have the request going to the NAS?
  >
  > regards,
  > Stefaan
  >
  >
  >> Cheers
  >> Francois
  >> On 28 Jan 2008, at 14:18, OOGHE Sven wrote:
  >>> Hi,
  >>>
  >>> Based on the discussion on the list, I have prepared the following  
  >>> text proposal concerning multicast conditional access. I tried to 
  >>> cover the different scenarios that were identified on the list. This

  >>> includes  the proposal from Tina and Roberta, and feedback from 
  >>> Stefaan.
  >>>
  >>> If nobody objects, I will use the text below to update the text in 
  >>> section 3.4.2 in the ANCP Framework. I will also add the 
  >>> corresponding requirements in section 4.2 (ANCP), 4.7.6 (Access 
  >>> Node) and
  >>> 4.8.6  (NAS).
  >>>
  >>> Regards,
  >>> Sven
  >>>
  >>> ---
  >>>
  >>> << Section 3.4.2 >>
  >>>
  >>> 3.4.2.  Multicast Admission Control
  >>>
  >>> << first part of the section remains unchanged. The text from the  
  >>> second bullet onward is updated with below text >>
  >>>
  >>>   o  Another approach is the reverse: it consists of the Policy 
  >>> Server
  >>>       querying the AN (either directly, or indirectly via the
  >>> NAS) so
  >>>       that both unicast and multicast CAC for the access line are
  >>>       performed by the AN.  In this case, a subscriber request for a
  >>>       unicast flow (e.g. a Video on Demand session) will trigger a
  >>>       resource request message towards a Policy Server; the latter  
  >>> will
  >>>       then query the AN, that in turn will perform unicast CAC for 
  >>> the
  >>>       access line and respond, indicating whether the unicast   
  >>> request is
  >>>       to be honored or denied.
  >>>
  >>>    The second scenario can be split in to cases:
  >>>
  >>>    o  In case the Policy Server queries the AN directly, the 
  >>> approach
  >>>       doesn't require the use of ANCP.  It is therefore beyond the  
  >>> scope
  >>>       of this document.
  >>>
  >>>    o  In case the Policy Server queries the AN indirectly via the 
  >>> NAS,
  >>>       the interaction can be handled as an ANCP transaction.   
  >>> When the
  >>>       Policy Server queries the NAS, the NAS can use ANCP to query 
  >>> the
  >>>       AN, specifying the Access-Loop-Circuit-ID and the required
  >>>       bandwidth for the requested unicast flow.  Upon receiving the
  >>>       query from the NAS, the AN then performs Admission Control and
  >>>       responds to the NAS, indicating if this unicast VoD request  
  >>> can be
  >>>       accepted or denied.
  >>>
  >>> 3.4.2.1.  When not to perform Admission Control
  >>>
  >>>    In general, the Access Node and NAS may not be aware of all   
  >>> possible
  >>>    multicast groups that will be streamed in the access network.   
  >>> For
  >>>    instance, it is likely that there will be multicast streams 
  >>> offered
  >>>    across the Internet.  For these unknown streams, performing   
  >>> bandwidth
  >>>    admission control may be challenging.
  >>>
  >>>    To solve this, these requests could be accepted without 
  >>> performing
  >>>    Admission Control.  This solution works, provided that the 
  >>> network
  >>>    handles the streams as best effort, so that other streams are not
  >>>    impacted at times of congestion.
  >>>
  >>>    Disabling Admission Control for unknown stream can be achieved by
  >>>    adding a "catch-all statement" in the Access Node white list or  
  >>> grey
  >>>    list.  In case the Access Node queries the NAS, the NAS on his 
  >>> turn
  >>>    will have to accept the request.  That way, the unknown streams 
  >>> are
  >>>    not blocked by default.
  >>>
  >>>    Next, in order to ensure that the streams are handled as best   
  >>> effort,
  >>>    the flow must be marked as such when entering the service 
  >>> provider
  >>>    network.  This way, whenever congestion occurs somewhere in the
  >>>    access/aggregation network, this stream will be kicked out   
  >>> before the
  >>>    access provider's own premium content.
  >>>
  >>>    The above concept is applicable beyond the notion of "Internet
  >>>    streams" or other unknown streams; it can applied to known   
  >>> multicast
  >>>    streams as well.  In this case, the Access Node or NAS will 
  >>> accept
  >>>    the stream even when bandwidth may not be sufficient to support 
  >>> the
  >>>    stream.  This again requires that the stream is marked as best  
  >>> effort
  >>>    traffic before entering the access/aggregation network.
  >>>
  >>> 3.4.2.2.  Multicast Admission Control and White Lists
  >>>
  >>>    As mentioned in section Section 3.4.1, conditional access to   
  >>> popular
  >>>    IPTV channels can be achieved by means of a White and Black list
  >>>    configured on the Access Node.  This method allows the Access   
  >>> Node to
  >>>    autonomously decide whether or not access can be granted to a
  >>>    multicast flow.
  >>>
  >>>    IPTV is an example of a service that will not be offered as best
  >>>    effort, but requires some level of guaranteed Quality of Service.
  >>>    This requires the use of Multicast Admission Control.  Hence, if

  >>> the
  >>>    Access Node wants to autonomously perform the admission process, 
  >>> it
  >>>    must be aware of the bandwidth characteristics of multicast 
  >>> flows.
  >>>    Otherwise, the Access Node would have to query the NAS for   
  >>> Multicast
  >>>    Admission Control; this would defeat the purpose of using a   
  >>> White and
  >>>    Black list.
  >>>
  >>>    Some network deployments may combine the use of White list, Black

  >>> list
  >>>    and Grey list.  In this case, the AN will be aware of the   
  >>> portion of
  >>>    the bandwidth used on the Access Port for flows matching an   
  >>> entry in
  >>>    the White list.  In order to perform Multicast Admission Control

  >>> for
  >>>    flows matching an entry in the Grey list, the NAS should add the
  >>>    bandwidth characteristics of the flow in the Admission Response
  >>>    message.  In this model, the AN would query the NAS for 
  >>> conditional
  >>>    access, and would then locally perform Multicast Conditional   
  >>> Access,
  >>>    using the bandwidth information retrieved from the NAS.
  >>>
  >>> << Section 4.2: add following requirements >>
  >>>
  >>>    o  The ANCP MUST support providing an Access Node with bandwidth
  >>>       information associated with multicast flows that are part of a
  >>>       White list.
  >>>
  >>>    o  The ANCP SHOULD allow the NAS to indicate the bandwidth
  >>>       information, associated with the requested multicast flows,  
  >>> in the
  >>>       admission decision sent to the AN.
  >>>
  >>>    o  In case a unicast and multicast stream share resources on an
  >>>       Access Port, the ANCP MUST allow the NAS to query the AN to
  >>>       request an admission decision for a unicast flow to be sent
  >>>       over that Port.
  >>>
  >>> << Section 4.7.6: add following requirements >>
  >>>
  >>>    o  The AN must be able to perform Admission Control for multicast
  >>>       streams, using the bandwith information of the requested   
  >>> multicast
  >>>       flow.  The information may be provisioned by a management 
  >>> system
  >>>       or by the NAS (using a Control Reqest message or an Admission
  >>>       Response message).
  >>>
  >>>    o  Upon receiving a query from the NAS to request an admission
  >>>       decision for a unicast flow to be sent over a particular 
  >>> Access
  >>>       Port, the AN must support using ANCP to reply to the NAS,
  >>>       indicating whether the request is to be honored or denied.
  >>>
  >>>
  >>> << Section 4.8.6: add following requirements >>
  >>>
  >>>    o  The NAS should support using ANCP to configure multicast
  >>>       admission control information to Access Ports on an Access 
  >>> Node.
  >>>
  >>>    o  Upon receiving a query from the AN for a request to replicate 
  >>> a
  >>>       multicast flow to a particular Access Port, the NAS should   
  >>> support
  >>>       using ANCP to reply to the AN indicating the bandwidth 
  >>> information,
  >>>       associated with the requested multicast flow.
  >>>
  >>>    o  Upon receiving a request from a Policy Server for a unicast 
  >>> flow
  >>>       to be sent over a particular Access Port, the NAS must support
  >>>       using ANCP to query the AN to receive a response indicating
  >>>       whether the request is to be honored or denied.
  >>>
  >>> ---
  >>>
  >>> Sven Ooghe
  >>> Alcatel-Lucent
  >>> CTO Office, Access Division
  >>> Copernicuslaan 50, 2018 Antwerp, Belgium
  >>> tel.: +32 3 240 42 26
  >>> fax: +32 3 240 40 73
  >>>
  >>> This message (including any attachments) contains confidential 
  >>> information intended for a specific individual and purpose, and is 
  >>> protected by law.  If you are not the intended recipient, you should

  >>> delete this message.  Any disclosure, copying, or distribution of 
  >>> this
  >>> message, or the taking of any action based on it, is strictly   
  >>> prohibited
  >>> without the prior consent of its author.
  >>>
  >>>
  >>>
  >>> _______________________________________________
  >>> ANCP mailing list
  >>> [email-masked]
  >>> https://www1.ietf.org/mailman/listinfo/ancp
  >> _______________________________________________
  >> ANCP mailing list
  >> [email-masked]
  >> https://www1.ietf.org/mailman/listinfo/ancp
  >
  >
  > _______________________________________________
  > ANCP mailing list
  > [email-masked]
  > https://www1.ietf.org/mailman/listinfo/ancp
_______________________________________________
ANCP mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/ancp

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 4 Feb 2008 18:11:03 +0100

Hi Tina,

> [Tina: No impact. It expand the ANCP scenario, ANCP can support

If this has no impact on ANCP, then the current text should be just  
fine. The current text:
	* (i) describes that there is another model for CAC ie PS-->AN or  
PS-->NAS-->AN,
	* (ii) clarifies that it does not require ANCP extensions (and thus  
is outside scope for ANCP).
Your description above seems to be in line with the text as it is  
today (which is fine by me too).

I think some have different ideas about how ANCP could play a role in  
the PS-->AN and PS-->NAS-->AN and therefore involve some specific  
ANCP extensions.
I recommend we do not try rush those in the first deliverables of  
ANCP WG. Once these additional models are understood and agreed, they  
can be added to the next version of ANCP deliverables.

Cheers

Francois

---

From: "Maglione Roberta" <[email-masked]>
Date: Wed, 6 Feb 2008 20:51:33 +0100

Hi Sven, Francois and All,
    sorry for my late reply.
As Tina and I wrote in the first email current ANCP framework draft in second bullet of 
section 3.4.2 already mentions the scenario where a Policy Server queries the AN directly 
or indirectly. As Tina said in some cases it could be more convenient for the PS to go 
through the NAS instead of querying the AN directly in order to reduce scalability issues 
because the NAS could be seen as an aggregation point for multiple Access nodes.  

As far as the impacts on ANCP I agree that in order to support the indirect scenario, 
PS->NAS->AN, with the interaction NAS->AN handled via ANCP some extensions are required to 
the ANCP protocol. I understand the concerns raised on mailing list about adding new 
requirement not fully agreed by the WG at this stage, in particular given the time 
constrains for the current ANCP protocol completion according to the scheduled milestones.
 
If the working group does not reach the consensus on this point IMHO 
one possibility could be to have an high level description of the depicted 
scenario in order to keep track of this use case and then to postpone the design 
of the protocol details required to fulfill this scenario in next phase of ANCP protocol.  
The intention is to make sure that the current protocol design does not prevent adding 
the additional scenario in next phase. 

What do you think?
Thanks and best regards,

Roberta 

-----Original Message-----
From: Francois Le Faucheur IMAP [mailto:[email-masked]]
Sent: Mon 2/4/2008 6:11 PM
To: Tina TSOU
Cc: Francois Le Faucheur IMAP; Maglione Roberta; OOGHE Sven; [email-masked]
Subject: Re: [ANCP] ANCP Multicast Admission Control
 
Hi Tina,

Cheers

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: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 13 Feb 2008 19:21:41 +0100

Folks,

given the latest batch of discussions we'd like to set a course for the
WG and design team regarding work on ANCP multicast control extensions,
if not also other extensions.

The latest proposals regarding multicast control put forward at least
two additional CAC deployment models to the one that is primarily
addressed by the current framework. The current framework text
represents a WG consensus arrived at after much discussion, and it is
our reasoned opinion that in attempting to adopt the proposals at this
stage (the framework document was supposedly ready for last-call) we
will run a serious risk of a prolonged discussions on the various models
leading to potentially derailing the consensus arrived at so far. All of
this will have a direct knock-on effect in delaying significantly the
chartered completion of the ANCP protocol spec, which happens to already
be behind schedule. At the same time it would be unfortunate to stop
such discussions if there continues to be interest in progressing the
proposals to a stage where they can be included in the framework.

As such, we would like to set the following direction which in our
opinion strikes a fair balance between the current work and future work
on ANCP:
- We would like to ask the WG to arrive at a high level text proposal
for the framework draft regarding protocol extensions in general,
amongst others to potentially address alternative CAC deployment models
at a later stage. It is too early to include detailed requirements as
proposed by some on these at this stage, however discussion can proceed
on the alias.
- The design team and WG will be asked to pursue at this stage towards a
protocol specification without explicitly realizing the mechanisms for
the alternative CAC models, but looking at extensibility in general.
Given a suitable message and TLV extension scheme there appears to be no
problem in having the protocol support new CAC models, or other ANCP
usage schemes in the future.
- When the frame-work draft reaches its Last-call I-D milestone, we'll
have a WG decision on re-chartering or adding new mile-stones protocol
specification/extension phases.

We trust that with the above direction in place we'll be able to obtain
rapid progress, without closing the door on extensions.

Regards,
Woj & Matthew.