[ANCP] ANCP Multicast Admission Control

Sven, Francois, and All

We agreed in the attached thread below that the framework draft needs to cover the case where IGMP signaling from the subscriber terminates on the NAS, and the AN does not snoop IGMP joins. The NAS performs conditional access and admission control on the received IGMP joins, and controls the replication state on the AN using ANCP. However, this is not adequately reflected in the draft. The draft also does not consider the scenario where the bandwidth accounting and CAC function is completely contained within the NAS (and doesn’t require complex synchronization between NAS and AN). I am proposing the following additions (in blue) to sections 3.4 and 3.4.2.

Thanks

-Sanjay

3.4. Multicast

   With the rise of supporting IPTV services in a resource efficient

   way, multicast services are getting increasingly important.

   In case of an ATM access/aggregation network, such as the reference

   architecture specified in DSL Forum [TR-059], multicast traffic

   replication is performed in the NAS.  In this model, typically IGMP

   is used to control the multicast replication process towards the

   subscribers.  The NAS terminates and processes IGMP signaling

   messages sent by the subscribers; towards the Regional Network, the

   NAS typically uses a multicast routing protocol such as PIM. The ATM

   Access Nodes and aggregation switches don't perform IGMP processing,

   nor do they perform multicast traffic replication.  As a result,

   network resources are wasted within the access/aggregation network.

   To overcome this resource inefficiency, the Access Node, aggregation

   node(s) and the NAS must all be involved in the multicast

   replication process. This avoids that several copies of the same

   stream are sent within the access/aggregation network. In case of an

   Ethernet-based access/aggregation network, this may, for example, be

   achieved by means of IGMP snooping or IGMP proxy in the Access Node

   and aggregation node(s).

   By introducing IGMP processing in the access/aggregation nodes, the

   multicast replication process is now divided between the NAS, the

   aggregation node(s) and Access Nodes.  In order to ensure backward

   compatibility with the ATM-based model, the NAS, aggregation node

   and Access Node need to behave as a single logical device.  This

   logical device must have exactly the same functionality as the NAS

   in the ATM access/aggregation network. The Access Node Control

   Mechanism can be used to make sure that this logical/functional

   equivalence is achieved by exchanging the necessary information

   between the Access Node and the NAS.

   Another option is for NAS to terminate IGMP signaling from the

   subscriber. In this scenario, NAS can use ANCP to create replication

   state in the AN for efficient multicast replication. The NAS sends a

   single copy of the multicast stream towards the AN. The NAS can perform

   conditional access and multicast admission control on IGMP joins, and create

   replication state in the AN if the flow is admitted by the NAS.

   The following subsections describe the different use cases related to multicast.

3.4.2. Multicast Admission Control

   The successful delivery of Triple Play Broadband services is quickly

   becoming a big capacity planning challenge for most of the Service

   Providers nowadays.  Solely increasing available bandwidth is not

   always practical, cost-economical and/or sufficient to satisfy end

   user experience given not only the strict requirements of unicast

   delay sensitive applications like VoIP and Video, but also the fast

   growth of multicast interactive applications such as

   videoconferencing, digital TV, digital audio, online movies and

   networked gaming.  These applications are typically characterized by

   a delay sensitive nature, an extremely loss sensitive nature and

   intensive bandwidth requirements.  They are also typically "non-

   elastic", which means that they operate at a fixed bandwidth, that

   cannot be dynamically adjusted to the currently available bandwidth.

   Therefore a Connection Admission Control (CAC) mechanism covering

   admission of multicast traffic over the DSL Broadband access is

   required, in order to avoid oversubscribing the available bandwidth

   and negatively impacting the end user experience.

   Considering specifically admission control over the access line,

   before honoring a user request to join a new multicast flow, the

   combination of AN and NAS MUST ensure admission control is performed

   to validate that there is enough "video" bandwidth remaining on the

   access line to carry the new flow (in addition to all other existing

   multicast and unicast video traffic).  The solution needs to cope

   with multiple flows per access line and needs to allow access line

   bandwidth to be dynamically shared across multicast and unicast

   traffic (irrespective of whether unicast CAC is performed by NAS or

   by some off-path Policy Server).

   Thus, supporting CAC for the access line requires some form of

   synchronization between the entity performing multicast CAC (e.g.

   the NAS or the AN) and the entity performing unicast CAC (e.g. the

   NAS or a Policy Server) and the entity actually enforcing the

   multicast replication (i.e. the AN). This synchronization can be

   achieved in a number of ways:

   o  One approach is for the AN to query the NAS so that both unicast

      and multicast CAC for the access line are performed by the NAS.

      In this case, the AN can use ANCP to query the NAS, that in turn

      performs multicast CAC and responds to the AN indicating whether

      the join is to be honored (and hence replication performed by the

      AN) or denied.  In the process, the NAS may communicate with a

      Policy Server.  The NAS may locally maintain available "video"

      bandwidth on the access-loop, and perform "video" bandwidth

      accounting for the access-loop. On receiving an admission request

      from the AN, the NAS can check available "video" bandwidth before

      admitting or denying the multicast flow. The policy server may

      query the NAS to perform admission control on a VoD flow, and update

      the available “video” bandwidth maintained by the NAS.

      Similarly to what has been discussed in the Conditional Access

      use case, in response to a Admission Request from the AN for

      admission control of a multicast flow, the NAS may send back an

      Admission Response message to the AN, including admission control

      information for that multicast flow, as well as for other a set

      of multicast flows sharing the same admission control rules.

      The AN can then autonomously honor or deny

      requests for a given user/port for the set of Multicast flows as

      indicated in the Admission Response message.  The ANCP

      requirements to support this approach (where the AN queries the

      NAS) are specified in this document;

   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.  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.

In case the NAS terminates IGMP signaling from the subscriber and controls the

replication state on the AN, the CAC function can be completely contained within

the NAS. NAS may locally maintain available "video" bandwidth on the access-loop,

perform "video" bandwidth accounting, and perform CAC on the received IGMP. Based

on the available bandwidth, if the IGMP join can be honored, the NAS can set the

replication state on the AN using ANCP. The policy server may query the NAS to

perform admission control on a VoD flow, and update the available "video" bandwidth

maintained by the NAS.

-----Original Message-----

> From: Francois Le Faucheur IMAP [mailto:flefauch at cisco.com]

> Sent: maandag 26 november 2007 11:42

> To: OOGHE Sven

> Cc: Francois Le Faucheur IMAP; Wojciech Dec (wdec); ancp at ietf.org;

> Maglione Roberta

> Subject: Re: Spontaneous Admission Response (was Re: [ANCP] ANCP WG

> follow-up)

> Hi Sven,

> On 26 Nov 2007, at 11:06, OOGHE Sven wrote:

> > Woj,

> >

> > From what I can find on the email list, the proposed change

> to section

> > 3.4.4 is related to the following remark from Sanjay (mid September

> > 2007):

> >

> > "The option I alluded to is IGMP from RG to BNG, and replication on

> > the AN. The replication state on the AN created/controlled

> via ANCP by BNG.

> > An optimization could be optional transparent snooping of

> IGMP on the

> > AN to act on IGMP reports for leave only (to implement

> "fast leave")."

> Right. This is what initiated the thread.

> I am also aware of other planned deployments where the Multicast joins

> are processed by the device behaving as the ANCP-controller (as

> opposed to the AN).

> As these ANCP deployments will exist, the ANCP specs ought to

> recognize and allow them. Note that this has very little impact on the

> ANCP protocol anyways (since "spontaneous Admission Responses"

> are already explicitly allowed anyways for multicast termination)

> >