[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] ANCP Multicast Admission Control
Hi Stefaan
Francois described this in very good terms in another email. But here is
another way to describe it:
The model is addressed in draft maglione - spontaneous/asynchronous
multicast request where how the request was invoke (HTTP, Radius CoA or
any other method) is outside the scope. The end result is the same where
the AN will handle its execution part for the mcast signaling the same
way as if it had participated in the IGMP join/leave. The only
difference here is the AN needs to specifically create the L2 forwarding
entry on the user VLAN, sort of like if manually configured.
Regards
Phil
>-----Original Message-----
>From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder at alcatel-lucent.be]
>Sent: Wednesday, January 30, 2008 6:18 AM
>To: Philippe Champagne (pchamp)
>Cc: Sanjay Wadhwa; Francois Le Faucheur (flefauch);
>Sven.Ooghe at alcatel-lucent.be; ancp at ietf.org
>Subject: Re: [ANCP] ANCP Multicast Admission Control
>
>
>Hi Phil,
>
>How is in the case of HTTP the multicast stream delivered to
>the DSLAMs?
> The ethernet switches do not receive an IGMP message, so
>their IGMP proxy/snooping will not see the new join. The
>model you describe is not really related to ANCP, so maybe
>better to leave it out to avoid new problems?
>
>regards,
>Stefaan
>
>
>Philippe Champagne (pchamp) wrote:
>
>> Hi Sanjay
>>
>> Question on this first paragraph and suggestion on the 2nd:
>>
>> 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.
>>
>>
>>
>> pchamp> So, this means ANCP will need to cover the case of
>admitting or denying on the AN a unicast flow rather than
>multicast flow...
>>
>> ie: Policy Server quering the AN indirectly via the NAS. Or
>you meant that only for the multicast part.
>>
>>
>>
>>
>>
>> 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.
>>
>>
>> pchamp> This paragraph should also add some phrasing to
>cover the case
>> where IGMP is not involved but rather an out of band protocol (HTTP
>> based). For example, the subscriber requesting a given
>multicast on a
>> web page linked to the policy server. In turn it would
>direct the NAS
>> to submit an admission control to the AN for that given
>multicast flow.
>> This could be done by adding to the 2nd paragraph, the following
>> statement (or close to it):
>>
>> Another case would be where the subscriber makes the request using
>> HTTP directly to a web server linked to the policy server, bypassing
>> both AN and NAS. In such case, the admission request would originate
>> from the policy server towards the NAS.
>>
>>
>>
>>
>>
>---------------------------------------------------------------
>---------
>> *From:* Sanjay Wadhwa [mailto:swadhwa at juniper.net]
>> *Sent:* Tuesday, January 29, 2008 3:06 AM
>> *To:* Francois Le Faucheur (flefauch);
>Sven.Ooghe at alcatel-lucent.be;
>> ancp at ietf.org
>> *Subject:* [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)
>>
>>>
>>
>>> >
>>
>>
>>
>>
>>
>>
>>
>>
>>
>----------------------------------------------------------------------
>> --
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP at ietf.org
>> https://www1.ietf.org/mailman/listinfo/ancp
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp