[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
ANCP                                                         R. Maglione
Internet-Draft                                               A. Garofalo
Intended status: Standards Track                          Telecom Italia
Expires: January 12, 2009                                 F. Le Faucheur
                                                               T. Eckert
                                                                   Cisco
                                                               T. Taylor
                                                                  Huawei
                                                           July 11, 2008


                    ANCP Multicast Handling Sessions
                    draft-maglione-ancp-mcast-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 12, 2009.













Maglione, et al.        Expires January 12, 2009                [Page 1]


Internet-Draft           ANCP Multicast Handling               July 2008


Abstract

   This memorandum aims at presenting ANCP Multicast handling.  It
   proposes updated description of the Multicast Use cases and
   corresponding updated ANCP requirements.  It also presents the
   corresponding Message Flows.













































Maglione, et al.        Expires January 12, 2009                [Page 2]


Internet-Draft           ANCP Multicast Handling               July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Multicast Use Cases  . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Conditional Access . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Multicast Admission Control  . . . . . . . . . . . . . . .  9
       3.2.1.  When not to perform Admission Control for a subset
               of flows . . . . . . . . . . . . . . . . . . . . . . . 12
       3.2.2.  Multicast Admission Control and White Lists  . . . . . 12
     3.3.  Multicast Accounting and Reporting . . . . . . . . . . . . 12
     3.4.  Spontaneous Admission Response . . . . . . . . . . . . . . 12
   4.  Multicast Protocol Requirements  . . . . . . . . . . . . . . . 13
     4.1.  ANCP Multicast Requirements  . . . . . . . . . . . . . . . 13
     4.2.  ANCP Access Node Multicast Requirements  . . . . . . . . . 13
     4.3.  ANCP NAS Multicast Requirements  . . . . . . . . . . . . . 15
   5.  Message Flows  . . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Multicast Conditional Access without CAC . . . . . . . . . 17
       5.1.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 17
       5.1.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 18
       5.1.3.  Join & Leave Operations  . . . . . . . . . . . . . . . 18
     5.2.  Multicast Conditional Access and CAC without AN
           Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 20
       5.2.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 20
       5.2.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 20
       5.2.3.  Join & Leave Operations  . . . . . . . . . . . . . . . 20
     5.3.  Multicast Admission Control with AN Bandwidth
           Delegation . . . . . . . . . . . . . . . . . . . . . . . . 21
       5.3.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 21
       5.3.2.  Profile Mapping and Initial Bandwidth Delegation . . . 22
       5.3.3.  Join & Leave Operations  . . . . . . . . . . . . . . . 23
       5.3.4.  AN-Triggered Increase of Delegated Multicast
               Bandwidth  . . . . . . . . . . . . . . . . . . . . . . 25
       5.3.5.  NAS-Triggered Decrease of Delegated Multicast
               Bandwidth  . . . . . . . . . . . . . . . . . . . . . . 26
       5.3.6.  AN Release of Redundant Multicast Bandwidth  . . . . . 26
     5.4.  Multicast Accounting . . . . . . . . . . . . . . . . . . . 27
       5.4.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 27
       5.4.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 28
       5.4.3.  Join & Leave Operations  . . . . . . . . . . . . . . . 28
     5.5.  Multicast Reporting  . . . . . . . . . . . . . . . . . . . 30
     5.6.  NAS-Controlled Multicast Replication . . . . . . . . . . . 30
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 32
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 35
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 35



Maglione, et al.        Expires January 12, 2009                [Page 3]


Internet-Draft           ANCP Multicast Handling               July 2008


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
   Intellectual Property and Copyright Statements . . . . . . . . . . 38

















































Maglione, et al.        Expires January 12, 2009                [Page 4]


Internet-Draft           ANCP Multicast Handling               July 2008


1.  Introduction

   [I-D.ietf-ancp-framework] defines a framework and requirements for an
   Access Node Control Mechanism between a Network Access Server (NAS)
   and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer
   (DSLAM)) in a multi-service reference architecture in order to
   perform QoS-related, service-related and Subscriber-related
   operations.  [I-D.ietf-ancp-protocol] specifies a Protocol for Access
   Node Control Mechanism in Broadband Networks in line with this
   framework.

   [I-D.ietf-ancp-framework] defines multicast use cases (in section
   3.4) as well as the corresponding ANCP Multicast requirements, ANCP
   Access Node Multicast Requirements and ANCP NAS Multicast
   Requirements (respectively in sections 4.2, 4.7.7 and 4.8.6).  The
   multicast use cases addressed are "Conditional Access", "Admission
   Control", "Accounting and Reporting", and finally "Spontaneous
   Admission Response".  The ANCP requirements associated with the
   Admission Control use case support a number of models.  One such
   model is where ANCP allows Admission Control to be performed without
   involvement of the Access Node i.e performed by the NAS (possibly
   with interactions with a Policy Server).  Another model is where
   Admission Control is to be performed with some involvement of the
   Access Node i.e. performed by NAS (possibly with interactions with a
   Policy Server) but this time with some delegation of decision to the
   Access Node.

   This memorandum proposes some enhancements to the ANCP operations for
   the model where some admission control decision is delegated to the
   Access Node.  The key enhancement is to explicitely delegate
   multicast bandwidth to the Access Node for the purpose of multicast
   admission control (instead of simply identifying multicast flows that
   share the same admission control rules and access control rules, as
   per current version of[I-D.ietf-ancp-framework]).  This allows the
   Access Node to perform admission control without ANCP signaling with
   the NAS in more situations than the current proposal.

   With this bandwidth delegation approach the AN manages a delegated
   multicast bandwidth that is a subset of the total video bandwidth for
   an AN port.  The AN can autonomously perform admission control of
   multicast flows within this delegated bandwidth.  An initial value
   for the delegated multicast bandwidth can be provisioned on the AN by
   the NAS through ANCP.  The AN and NAS then communicate via ANCP to
   increase or decrease the delegated multicast bandwidth depending on
   the relative demand of muticast flows versus unicast flows.  The
   proposed approach for admission control with bandwidth delegation is
   compatible with all the conditional access methods supported by
   [I-D.ietf-ancp-framework].  In particular, it allows multicast



Maglione, et al.        Expires January 12, 2009                [Page 5]


Internet-Draft           ANCP Multicast Handling               July 2008


   admission control check to be performed by the AN even when the AN
   needs to query the NAS for conditional access check.

   This memorandum identifies all the corresponding changes that would
   be required to [I-D.ietf-ancp-framework] in order to reflect the
   proposed multicast admission control enhancement.  The corresponding
   message flows are also documented, in view of clarifying all the
   proposed multicast ANCP operations and facilitating future
   specification of the corresponding ANCP protocol extensions.

   This memorandum does not propose any change to the other model of
   operations for multicast Admission Control Control, nor to ANCP
   operations for the other multicast use cases.






































Maglione, et al.        Expires January 12, 2009                [Page 6]


Internet-Draft           ANCP Multicast Handling               July 2008


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.














































Maglione, et al.        Expires January 12, 2009                [Page 7]


Internet-Draft           ANCP Multicast Handling               July 2008


3.  Multicast Use Cases

   This section describes the ANCP use cases related to Multicast.

3.1.  Conditional Access

   This section discusses the changes proposed to section 3.4.1 of
   [I-D.ietf-ancp-framework].

   [I-D.ietf-ancp-framework] defines the concept of multicast flows that
   share the same control rules (ie same Conditional Access rules and
   same Admission Control rules).  The objective of this concept was to
   achieve a tradeoff between pre-provisioning the AN with all
   Conditional Access and Admission Control information and querying the
   NAS on a per join basis.  The former may be a configuration burden
   and may lead in large delays when the NAS or AN restarts, while the
   latter may increase channel join and channel change times because of
   the additional message processing involved in the AN, the NAS and
   potentially the Policy Server.

   Now considering that

   o  this memorandum proposes (in Section 3.2) the extension of the
      concept of multicast flows that share the same Admission Control
      rules into an approach of bandwidth delegation from NAS to the AN
      whereby channels of equivalent bandwidth no longer need to be
      provisioned into the AN by the NAS

   o  grey lists in case of the Conditional Access scenario are mainly
      used in order to be able to have the conditional access decision
      taken by the NAS or a Policy Server (especially in order to
      address the case when conditional access information changes
      frequently, or when the multicast groups are not known to a client
      application in advance, thus where it may not be possible or
      convenient to pre-provisioning AN with conditional access
      information)

   we propose to simplify operations of Conditional Access and remove
   the notion of multicast flows sharing the same conditional access
   rules.  Specifically, we propose to remove the following two
   paragraphs of section 3.4.1 [I-D.ietf-ancp-framework]:

   "Querying the NAS before performing a join on the AN may increase
   channel join and channel change times because of the additional
   message processing involved in the AN, the NAS and potentially the
   Policy Server.  On the other hand, pre-provisioning per subscriber
   profiles potentially different for each subscriber may be a
   configuration burden, may result in large delays when the NAS or AN



Maglione, et al.        Expires January 12, 2009                [Page 8]


Internet-Draft           ANCP Multicast Handling               July 2008


   restarts, or may not be viable when conditional access changes
   frequently or are to remain under the control of an external
   administrative entity.

   In order to account for these operational factors and associated
   trade-offs, in some cases, the provisioning and querying techniques
   can be combined.  In such a model, the AN sends an Admission Request
   message to the NAS as a trigger for a particular multicast flow.  The
   NAS would then send back an Admission Response message to the AN,
   including conditional access information for that multicast flow, as
   well as for a set of multicast flows sharing the same conditional
   access 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."

3.2.  Multicast Admission Control

   Section 3.4.2 of [I-D.ietf-ancp-framework] presents the requirement
   for synchronization between the entity performing multicast CAC, the
   entity performing unicast CAC and the entity actually enforcing
   multicast replication.  It describes three approaches to perform this
   synchronization.  This memorandum proposes the following changes to
   the methods described in the first and in the third bullet.

   Replace the following text:

   " 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.  The NAS may locally maintain available "video" bandwidth on
   the Access Loop, and perform video bandwidth accounting for the
   Access Loop.  Upon receiving an Admission Request from the AN, the
   NAS can check available "video" bandwidth before admitting or denying
   the multicast flow.  In the process, the NAS may communicate with the
   Policy Server.  For unicast video services such as Video on Demand
   (VoD), the NAS may also be queried (by a Policy Server or via on-path
   CAC signaling), so that it can perform admission control for the
   unicast 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 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



Maglione, et al.        Expires January 12, 2009                [Page 9]


Internet-Draft           ANCP Multicast Handling               July 2008


   message.  The ANCP requirements to support this approach (where the
   AN queries the NAS) are specified in this document;"

   by the following text:

   "One approach is where ANCP allows Admission Control to be performed
   by the NAS (possibly with interactions with a Policy Server) either
   without any involvement of the Access Node or with some involvement
   of the Access Node in particular with the delegation of some
   decisions to the Access Node.

   The NAS uses ANCP to indicate to the AN whether or not Admission
   Control is needed for each multicast flow on a given Access Port, and
   where Admission Control is needed whether or not it is to be
   performed with AN Bandwidth Delegation.  In particular:

   o  multicast flows that require Admission Control without AN
      Bandwidth Delegation are inserted in the Grey List and these
      entries are flagged as "no Bandwidth Delegation";

   o  multicast flows that require Admission Control with AN Bandwidth
      Delegation are:

   o

      *  inserted in the White list and flagged as "Bandwidth
         Delegation", in case they do not require any Conditional Access
         operation to be performed by the NAS

      *  inserted in the Grey List and flagged as "Bandwidth
         Delegation", in case they require some Conditional Access
         checks to be performed by the NAS.

   In case of Admission Control without AN Bandwidth Delegation, the AN
   can use ANCP to query the NAS, that in turn performs multicast
   Admission Control check for the new multicast flow and responds to
   the AN indicating whether the join is to be honored (and hence
   replication performed by the AN) or denied.  The NAS may locally
   maintain available "video" bandwidth on the Access Loop, and perform
   video bandwidth accounting for the Access Loop.  Upon receiving an
   Admission Request from the AN, the NAS can check available "video"
   bandwidth before admitting or denying the multicast flow.  In the
   process, the NAS may communicate with the Policy Server.  For unicast
   video services such as Video on Demand (VoD), the NAS may also be
   queried (by a Policy Server or via on-path CAC signaling), so that it
   can perform admission control for the unicast flow, and update the
   available video bandwidth maintained by the NAS.




Maglione, et al.        Expires January 12, 2009               [Page 10]


Internet-Draft           ANCP Multicast Handling               July 2008


   In case of Admission Control with AN Bandwidth Delegation, the NAS
   (possibly with interactions with a Policy Server) manages total
   bandwidth for video admission, performs unicast admission control and
   uses ANCP to delegate a certain amount of bandwidth for some
   multicast flows to the Access Node.  In this scenario upon receiving
   a join to a multicast flow which matches the White or Grey Lists
   whose entry is flagged as "Bandwidth Delegation" for a specific
   Access Port, before starting the multicast flow replication the AN
   must perform the necessary bandwidth admission control check for the
   new multicast flow.

   In some cases, the bandwidth that the NAS initially delegated to the
   AN may not be enough to satisfy a multicast request for a new flow.
   In this scenario the AN can use ANCP to query the NAS in order to
   request additional multicast bandwidth; the NAS (possibly with
   interactions with a Policy Server) decides if the request for more
   bandwidth can be satisfied and uses ANCP to send a response to the AN
   indicating the updated delegated multicast bandwidth.  It is worth
   noticing that in this case, the time taken to complete the procedure
   is an increment to the zapping delay: in order to minimize the
   zapping delay for future join requests the AN can insert in the
   request message two values: the minimum amount of additional
   multicast bandwidth requested, and the preferred additional amount.
   The first value is the amount that allows the present join request to
   be satisfied, the second value an amount that anticipates further
   join requests.

   In some cases, the NAS (or the Policy Server) may not have enough
   unicast bandwidth to satisfy a new incoming video request: in these
   scenarios the NAS can use ANCP to query (or instruct) the AN in order
   to decrease the amount of multicast bandwidth previously delegated on
   a given Access Port.  The AN upon receiving this query from the NAS
   can use ANCP to send a response to AN indicating the updated
   delegated multicast bandwidth.  Actually, based on considerations
   similar to those of the previous paragraph, it indicates the minimum
   amount of multicast bandwidth that it needs released and a preferred
   amount, which may be larger.

   In addition in some cases upon receiving a leave for a specific
   multicast flow the AN can decides that it has an excess of delegated
   but uncommitted bandwidth, thus the AN can use ANCP to send a message
   to the NAS to release unused multicast bandwdth previously delegated.

   The ANCP requirements to support this approach (where the AN queries
   the NAS) are specified in this document; "

   Replace this text:




Maglione, et al.        Expires January 12, 2009               [Page 11]


Internet-Draft           ANCP Multicast Handling               July 2008


   " In a third approach, the Policy Server queries 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.  This method will not be
   addressed in this document; it may be covered by means of ANCP
   extensions at a later stage.  "

   by the following text:

   "In a third approach, the Policy Server queries the AN directly 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 this scenario 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."

3.2.1.  When not to perform Admission Control for a subset of flows

   This memorandum does not propose any update over the description of
   this use case provided in section 3.4.2.1 of
   [I-D.ietf-ancp-framework].

3.2.2.  Multicast Admission Control and White Lists

   This memorandum does not propose any update over the description of
   this use case provided in section 3.4.2.2 of
   [I-D.ietf-ancp-framework].

3.3.  Multicast Accounting and Reporting

   This memorandum does not propose any update over the description of
   this use case provided in section 3.4.3 of [I-D.ietf-ancp-framework].

3.4.  Spontaneous Admission Response

   This memorandum does not propose any update over the description of
   this use case provided in section 3.4.4 of [I-D.ietf-ancp-framework].






Maglione, et al.        Expires January 12, 2009               [Page 12]


Internet-Draft           ANCP Multicast Handling               July 2008


4.  Multicast Protocol Requirements

4.1.  ANCP Multicast Requirements

   This memorandum proposes the following changes to section 4.2 of
   [I-D.ietf-ancp-framework].

   Replace the following requirement:

   o  The ANCP must allow the NAS, when replying to an AN request, to
      convey information on multiple multicast flows sharing the same
      conditional access and/or admission control rules.  This allows
      the AN to take autonomous decisions for these flows later on.

   by the following requirements:

   o  The ANCP must allow the NAS to indicate to the AN whether or not
      Admission Control is needed for some multicast flows on a given
      Access Port and where needed whether or not it is to be performed
      with AN Bandwidth Delegation.

   o  In case of Admission Control without AN Bandwidth Delegation the
      ANCP must allow the NAS to reply to a query from the AN indicating
      whether or not a multicast flow may be replicated to a particular
      Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, the
      ANCP must allow the NAS to delegate a certain amount of bandwidth
      to the AN for a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation the ANCP
      must allow the AN to query the NAS to request additional multicast
      bandwidth on a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation the ANCP
      must allow the NAS to query (or to instruct) the AN to reduce the
      amount of bandwidth previously delegated on a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation the ANCP
      must allow the AN to autonomous release redundant multicast
      bandwidth on a given Access Port.

4.2.  ANCP Access Node Multicast Requirements

   This memorandum proposes the following changes to section 4.7.6 of
   [I-D.ietf-ancp-framework].

   Replace the following requirements:



Maglione, et al.        Expires January 12, 2009               [Page 13]


Internet-Draft           ANCP Multicast Handling               July 2008


   o  The AN must accept any join to a multicast flow matching the White
      List for the relevant Access Port.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List for a specific Access Port, the AN must support using ANCP to
      query the NAS to receive a response indicating whether that join
      is to be honored or denied.

   o  Upon querying the NAS, the AN should support receiving ANCP
      messages from the NAS containing conditional access and/or
      admission control information of multiple multicast flows.  This
      allows the AN to take autonomous decisions for these flows later
      on.

   o  The AN should support using ANCP to notify the NAS when resources
      for a multicast flow are no longer in use (e.g. the AN is no
      longer replicating any multicast flows from a set of multicast
      flows sharing the same admission control rules).  This allows
      corresponding bandwidth to be released on NAS.

   by the following requirements:

   o  The AN must accept any join to a multicast flow matching the White
      List and flagged as "no CAC" for the relevant Access Port.

   o  Upon receiving a join to a multicast flow which matches the White
      List whose entry is flagged as "Bandwidth Delegation" for a
      specific Access Port, before starting the multicast flow
      replication the AN must perform the necessary bandwidth admission
      control check for the new flow.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List whose entry is flagged as "no Bandwidth Delegation" for a
      specific Access Port, the AN must support using ANCP to query the
      NAS that in turn will perform both the necessary conditional
      access and the admission control checks for the new flow and sends
      a response indicating whether that join is to be honored or
      denied.  The AN must support using ANCP to notify the NAS when the
      the user leaves the multicast flow.

   o  Upon receiving a join to a multicast flow which matches the Grey
      List whose entry is flagged as "Bandwidth Delegation" for a
      specific Access Port, the AN must perform the necessary bandwidth
      admission control check for the new flow and if it is successful
      the AN must support using ANCP to query the NAS to receive a
      response indicating whether that join is to be honored or denied.





Maglione, et al.        Expires January 12, 2009               [Page 14]


Internet-Draft           ANCP Multicast Handling               July 2008


   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to query the NAS to request additional
      delegated multicast bandwidth on a given Access Port; the AN
      should be able to specify both the minimum and the preferred
      amount of additional multicast bandwidth requested.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving a Bandwidth Delegation Request from the NAS querying or
      instructing to decrease the delegated multicast bandwidth on a
      given Access Port, the AN must support using ANCP to send a
      Bandwidth Delegation Response indicating the new delegating
      multicast bandwidth

   o  In case of Admission Control with AN Bandwidth Delegation, the AN
      must support using ANCP to send a Bandwidth Release message to the
      NAS in order to release unused delegated multicast bandwidth on a
      given Access Port.

4.3.  ANCP NAS Multicast Requirements

   This memorandum proposes the following changes to section 4.8.6 of
   [I-D.ietf-ancp-framework].

   Replace the following requirements:

   o  The NAS must support using ANCP to configure multicast conditional
      access information to Access Ports on an Access Node, using Black
      Lists and White Lists

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port, the NAS must support
      using ANCP to reply to the AN indicating whether the request is to
      be honored or denied.

   o  Upon receiving a query from the AN for a request to replicate
      multicast flow to a particular Access Port, the NAS should support
      sending an Admission Response message containing conditional
      access and/or admission control information of multiple multicast
      flows.  This allows the AN to take autonomous decisions for these
      flows later on

   by the following requirements:

   o  The NAS must support using ANCP to configure multicast conditional
      access information to Access Ports on an Access Node, using Black
      Lists, Grey Lists and White Lists.





Maglione, et al.        Expires January 12, 2009               [Page 15]


Internet-Draft           ANCP Multicast Handling               July 2008


   o  The NAS must support using ANCP to indicate to the AN whether or
      not Admission Control is needed for some multicast flows on a
      given Access Port and where needed whether or not it is to be
      performed with AN Bandwidth Delegation.

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port and where Admission
      Control is not needed for that multicast flow on that Access Port,
      the NAS must be able to perform the necessary conditional access
      check for the new flow and the NAS must support using ANCP to
      reply to the AN indicating whether the request is to be honored or
      denied.

   o  Upon receiving a query from the AN for a request to replicate a
      multicast flow to a particular Access Port and where Admission
      Control without AN Bandwidth Delegation is needed for that
      multicast flow on that Access Port, the NAS must be able to
      perform both the necessary conditional access (if needed) and the
      bandwidth admission control check for the new flow and the NAS
      must support using ANCP to reply to the AN indicating whether the
      request is to be honored or denied.

   o  In case of Admission Control with AN Bandwidth Delegation the NAS
      must support using ANCP to delegate a certain amount of bandwidth
      to the AN for a given Access Port.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving a Bandwidth Delegation Request from the AN requesting to
      increase the delegated multicast bandwidth on a given Access Port,
      the NAS must support using ANCP to send a Bandwidth Delegation
      Response indicating the new delegating multicast bandwidth.

   o  In case of Admission Control with AN Bandwidth Delegation, the NAS
      must support using ANCP to send a request the AN to decrease the
      amount of multicast bandwidth previously delegated on a given
      Access Port; the NAS should be able to specify both the minimum
      and the preferred amount decrement of multicast bandwidth
      requested.

   o  In case of Admission Control with AN Bandwidth Delegation, upon
      receiving an ANCP Bandwidth Release message, the NAS must be able
      to update accordingly its view of the multicast bandwidth
      delegated to the AN.








Maglione, et al.        Expires January 12, 2009               [Page 16]


Internet-Draft           ANCP Multicast Handling               July 2008


5.  Message Flows

   This section documents the message flows associated with multicast
   handling by ANCP.  It is not proposed that these message flows be
   incorporated in [I-D.ietf-ancp-framework] since message flows are
   outside its scope.  These messages flows are intended to clarify
   operation of the ANCP Multicast and provide guidance for the
   specification of ANCP Protocol extensions for support of multicast.

5.1.  Multicast Conditional Access without CAC

   This section describes ANCP operations when multicast flows are
   subject to multicast Conditional Access but not subject to CAC.

5.1.1.  List/Profile Provisioning

   The AN provisioning is performed by NAS using a Provisioning message
   that contains White/Black/Grey lists and their corresponding
   "Multicast Profile ID".  To indicate to the AN that it need not
   perform any CAC operation on those flows, the White List entries are
   flagged as "no CAC" and the Grey List entries are flagged as "no
   Bandwidth Delegation".  The corresponding message flow is illustrated
   in Figure 1.

   Although Figure 1 shows the three lists in the ANCP provisioning
   message, the message may instead contain any subset of 2 or 1 list.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |    Provisioning(    |
      |                 |                      | (White List(noCAC), |
      |                 |                      | Grey List(noBD),    |
      |                 |                      | Black List,         |
      |                 |                      | Profile_ID)         |
      |                 |                      |<--------------------|

(noCAC): entries in the White List flagged as "no CAC"
(noBD) : entries in the Grey List flagged
         as "no Bandwidth Delegation"

   Figure 1: Provisioning AN with White/Grey/Black Lists for Conditional
                                  Access






Maglione, et al.        Expires January 12, 2009               [Page 17]


Internet-Draft           ANCP Multicast Handling               July 2008


5.1.2.  Profile Mapping

   As soon as the AN port comes up, the AN sends an ANCP PORT_UP message
   to the NAS specifying the Access Loop Circuit ID.  The NAS replies
   with an ANCP PORT_MNGT message that, together with the other
   parameters, includes the Multicast Profile ID to be associated to
   that Port.  The corresponding message flow is illustrated in
   Figure 2.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |                     |
      |                 |      DSL Synch.      |                     |
      |                 |--------------------->|                     |
      |                 |                      |    PORT_UP(Port ID) |
      |                 |                      |-------------------->|
      |                 |                      |                    (*)
      |                 |                      | PORT_MNGT(Port ID,  |
      |                 |                      |      Profile_ID)    |
      |                 |                      |<--------------------|


(*) The NAS may optionnaly communicate with an external
    Autorization/Policy Server

                Figure 2: Associating Profile ID to AN Port

5.1.3.  Join & Leave Operations

   The message flows in Figure 3 illustrates the behavior of the AN in
   case of receiving a join and leave messages on the Access Port for
   multicast flows respectively part of:

   o  white list (with matching entry flagged as "no CAC")

   o  black list

   o  grey list (with matching entry flagged as "no Bandwidth
      Delegation")









Maglione, et al.        Expires January 12, 2009               [Page 18]


Internet-Draft           ANCP Multicast Handling               July 2008


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |            |          |                   |
         |            |          |                   |
         |   Join(WhiteNoCAC-Fl) |                   |
         |------------+--------->|                   |
         |            |          |                   |
         |     Mcast White Flow  |                   |
         |<======================+                   |
         |            |          |                   |
         |            |          |                   |
         |  Leave(WhiteNoCAC-Fl) |                   |
         |------------+--------->|                   |
         |            |          |                   |
         |    Join(Black-Fl)     |                   |
         |-----------+---------->x                   |
         |    <No Replication >  |                   |
         |    <For Black-Flow >  |                   |
         |           |           |                   |
         |           |           |                   |
         |   Join(GreyNoBD-Fl)   |     Admission     |
         |-----------+---------->|      Request      |
         |           |           |------------------>|
         |           |           |     Admission    (*)
         |           |           |      Response     |
         |     Mcast Grey Flow   |<------------------|
         |<======================+                   |
         |                       |                   |
         |           |           |                   |
         | Leave(GreyNoBD-Fl)    |     Admission     |
         |-----------+---------->|      Release      |
         |           |           |------------------>|
         |           |           |                   |


   WhiteNoCAC-Fl : Multicast Flow matching an entry in White List
                   flagged as "No CAC"
   GreyNoBD-Fl   : Multicast Flow matching an entry in Grey List
                   flagged as "No Bandwidth Delegation"
   (*) The NAS may optionnaly communicate with an external
       Autorization/Policy Server

                  Figure 3: Multicast Conditional Access






Maglione, et al.        Expires January 12, 2009               [Page 19]


Internet-Draft           ANCP Multicast Handling               July 2008


5.2.  Multicast Conditional Access and CAC without AN Bandwidth
      Delegation

   This section describes ANCP operations when multicast flows are
   subject to multicast Conditional Access and subject to CAC on NAS
   without bandwidth delegation on the Access Node.

5.2.1.  List/Profile Provisioning

   The AN provisioning is performed by NAS using a Provisioning message
   that contains Black/Grey lists and their corresponding "Multicast
   Profile ID".  To indicate to the AN that it need not perform any CAC
   operation on those flows, the Grey List entries are flagged as "no
   Bandwidth Delegation".  The corresponding message flow is illustrated
   in Figure 4.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |    Provisioning(    |
      |                 |                      | (Grey List(noBD),   |
      |                 |                      | Black List,         |
      |                 |                      | Profile_ID)         |
      |                 |                      |<--------------------|

(noBD) : entries in the Grey List flagged
         as "no Bandwidth Delegation"

      Figure 4: Provisioning AN with Grey/Black Lists for Conditional
                Access and CAC without Bandwidth Delegation

5.2.2.  Profile Mapping

   The "Profile ID" is associated to the port when the DSL line comes up
   in the exact same way as illustrated in Figure 2.

5.2.3.  Join & Leave Operations

   Upon receiving a join request for a multicast flow in a Grey List
   whose entry is flagged as "No Bandwidth Delegation", the AN uses ANCP
   to query the NAS, that in turn will perform the necessary conditional
   access check and bandwidth admission control check for the new flow
   and then it will respond to the AN indicating whether the join is to
   be honored (and hence replication performed by the AN) or denied (and
   hence replication not performed by the AN).  This is illustrated in
   Figure 5.



Maglione, et al.        Expires January 12, 2009               [Page 20]


Internet-Draft           ANCP Multicast Handling               July 2008


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |           |           |                   |
         |    Join(Black-Fl)     |                   |
         |-----------+---------->x                   |
         |    <No Replication >  |                   |
         |    <For Black-Flow >  |                   |
         |           |           |                   |
         |   Join(GreyNoBD-Fl)   |     Admission     |
         |-----------+---------->|      Request      |
         |           |           |------------------>|
         |           |           |                  (*)
         |           |           |     Admission     |
         |           |           |    Response       |
         |       Mcast-Flow      |<------------------|
         |<======================+                   |
         |           |           |                   |
         |           |           |                   |
         |  Leave(GreyNoBD-Fl)   |     Admission     |
         |-----------+---------->|      Release      |
         |           |           |------------------>|

   (*) The NAS may optionnaly communicate with an external
       Autorization/Policy Server

   Figure 5: Multicast Admission Control without AN Bandwidth Delegation

5.3.  Multicast Admission Control with AN Bandwidth Delegation

   This section describes ANCP operations when multicast flows are
   subject to multicast Conditional Access and subject to CAC on NAS
   with bandwidth delegation on the Access Node.

5.3.1.  List/Profile Provisioning

   The AN provisioning is performed by NAS using a Provisioning message
   that contains White/Black/Grey lists and their corresponding
   "Multicast Profile ID".  To indicate to the AN that it need perform
   CAC in compliance with Bandwidth Delegation on those flows, the White
   List entries and Grey List Entries are flagged as "Bandwidth
   Delegation".  The corresponding message flow is illustrated in
   Figure 1.

   Although Figure 6 shows the three lists in the ANCP provisioning
   message, the message may instead contain any subset of 2 or 1 list.



Maglione, et al.        Expires January 12, 2009               [Page 21]


Internet-Draft           ANCP Multicast Handling               July 2008


   The AN is configured by other means with the multicast bandwidth
   required for each multicast flow.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                      |
      |                 |                      |    Provisioning(    |
      |                 |                      | (White List(BD),    |
      |                 |                      | Grey List(BD),      |
      |                 |                      | Black List,         |
      |                 |                      | Profile_ID)         |
      |                 |                      |<--------------------|

(BD): entries in the White/Grey List flagged
      as "Bandwidth Delegation"

   Figure 6: Provisioning AN with White/Grey/Black Lists for Conditional
                                  Access

5.3.2.  Profile Mapping and Initial Bandwidth Delegation

   The "Profile ID" is associated to the port when the DSL line comes up
   in the same way as illustrated in Figure 2.  In addition, the NAS
   passes to the AN the total video bandwidth (unicast plus multicast)
   associated to the AN port and the initial AN allocation of multicast
   bandwidth for the port.  The message flow combining these two steps
   is illustrated in Figure 7.






















Maglione, et al.        Expires January 12, 2009               [Page 22]


Internet-Draft           ANCP Multicast Handling               July 2008


 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |                     |
      |                 |      DSL Synch.      |                     |
      |                 |--------------------->|                     |
      |                 |                      |   PORT_UP(Port ID)  |
      |                 |                      |-------------------->|
      |                 |                      |                    (*)
      |                 |                      | PORT_MNGT(Port ID,  |
      |                 |                      |      Profile_ID,    |
      |                 |                      | Total Video bw,     |
      |                 |                      | Delegated multicast |
      |                 |                      | Bandwidth)          |
      |                 |                      |<--------------------|
      |                 |                      |                     |
      |                 |                      |   Response          |
      |                 |                      |-------------------->|
      |                 |                      |                     |
      |                 |                      |                    (*)
      |                 |                      |                     |


(*) The NAS may optionnaly communicate with an
    external Policy Server


    Figure 7: Multicast Admission Control with AN Bandwidth Delegation

5.3.3.  Join & Leave Operations

   Upon receiving a join request for a multicast flow in a Grey List
   whose entry is flagged as "Bandwidth Delegation", the AN performs
   admission control of the flow in accordance with Bandwidth Delegation
   and uses ANCP to query the NAS that in turn will perform the
   necessary conditional access check for the new flow.  The NAS will
   respond to the AN indicating whether the join is to be honored (and
   hence replication performed by the AN) or denied (and hence
   replication not performed by the AN).  This is illustrated in
   Figure 8.  In the case where the NAS reponses indicates that the
   replication is not to be honored, the AN will reflect this in his
   Bandwidth Delegation operation (ie release corresponding bandwidth
   within the delegated bandwidth).






Maglione, et al.        Expires January 12, 2009               [Page 23]


Internet-Draft           ANCP Multicast Handling               July 2008


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |     Join(WhiteBD-Fl)  |                   |
         |-----------+---------->|                   |
         |           |           |                   |
         |       Mcast-Flow      |                   |
         |<======================|                   |
         |           |           |                   |
         |   Leave(WhiteBD-Fl)   |                   |
         |-----------+---------->|                   |
         |           |           |                   |
         |           |           |                   |
         |           |           |                   |
         |        JOIN(Black-Fl) |                   |
         |-----------+---------->|                   |
         |    <No Replication >  |                   |
         |    <For Black-Flow >  |                   |
         |           |           |                   |
         |     Join(GreyBD-Fl)   |     Admission     |
         |-----------+---------->|    Request        |
         |           |           |------------------>|
         |           |           |                  (*)
         |           |           |     Admission     |
         |           |           |   Response        |
         |       Mcast-Flow      |<------------------|
         |<======================|                   |
         |           |           |                   |
         |   Leave(GreyBD-FL)    |     Admission     |
         |-----------+---------->|      Release      |
         |           |           |------------------>|

   WhiteBD-Fl : Multicast Flow matching an entry in White List
                flagged as "Bandwidth Delegation"
   GreyBD-Fl  : Multicast Flow matching an entry in Grey List
                flagged as "Bandwidth Delegation"
   (*) The NAS may optionnaly communicate with an
       external Autorization/Policy Server


    Figure 8: Multicast Admission Control with AN Bandwidth Delegation








Maglione, et al.        Expires January 12, 2009               [Page 24]


Internet-Draft           ANCP Multicast Handling               July 2008


5.3.4.  AN-Triggered Increase of Delegated Multicast Bandwidth

+----------+    +-------+   +-----+    ANCP    +-----+
|Subscriber|    | Home  |   | AN  |<---------->| NAS |
+----------+    |Gateway|   +-----+            +-----+
      |         +-------+     |                   |
      |           |           |                   |
      |     Join(WhiteBD-Fl1) |                   |
      |-----------+---------->|                   |
      |           |           |                   |
      |       Mcast-Flow      |                   |
      |<======================|                   |
      |           |           |                   |
      |        Leave(Flow)    |                   |
      |-----------+---------->|                   |
      |           |           |                   |
      |           |           |                   |
      |   Join(WhiteBD-Fl2)   |  Band Delegation  |
      |-----------+---------->|    Request        |
      |           |           | (min increment,   |
      |           |           |(pref increment)   |
      |           |           |------------------>|
      |           |           |                  (*)
      |           |           |  Band Delegation  |
      |           |           |     Response      |
      |           |           |  (delegated       |
      |           |           |   multicast bw)   |
      |       Mcast-Flow      |<------------------|
      |<======================|                   |
      |           |           |                   |
      |        Leave(Flow)    |                   |
      |-----------+---------->|                   |
      |           |           |                   |

WhiteBD-Fl1 : Multicast Flow matching an entry in White List
              flagged as "Bandwidth Delegation"
WhiteBD-Fl2 : Multicast Flow matching an entry in White List
              flagged as "Bandwidth Delegation"
              WhiteBD-Fl2 requires more bandwidth than currently
              remaining available from the multicast delegated bandwidth

(*) The NAS may optionnaly communicate with an
    external Autorization/Policy Server


               Figure 9: Requesting More Multicast Bandwidth





Maglione, et al.        Expires January 12, 2009               [Page 25]


Internet-Draft           ANCP Multicast Handling               July 2008


5.3.5.  NAS-Triggered Decrease of Delegated Multicast Bandwidth

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |           |           |                  (*)
         |           |           |                   |
         |           |           | Band Delegation   |
         |           |           |    Request        |
         |           |           | (min increment,   |
         |           |           |(pref increment)   |
         |           |           |<------------------|
         |           |           |                   |
         |           |           |  Band Delegation  |
         |           |           |      Response     |
         |           |           |  (delegated       |
         |           |           |   multicast bw)   |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                  (*)
         |           |           |                   |


   (*) The NAS may optionnaly communicate with an
       external Autorization/Policy Server

               Figure 10: Requesting More Unicast Bandwidth

5.3.6.  AN Release of Redundant Multicast Bandwidth




















Maglione, et al.        Expires January 12, 2009               [Page 26]


Internet-Draft           ANCP Multicast Handling               July 2008


   +----------+    +-------+   +-----+      ANCP      +-----+
   |Subscriber|    | Home  |   | AN  |<-------------->| NAS |
   +----------+    |Gateway|   +-----+                +-----+
         |         +-------+      |                      |
         |             |          |                      |
         | Leave(WhiteBD-Fl)      |                      |
         |----------------------->|      Band Release    |
         |             |          |  (allocated multicast|
         |             |          |     bandwidth)       |
         |             |          |--------------------->|
                                                        (*)

   WhiteBD-Fl : Multicast Flow matching an entry in White List
                 flagged as "Bandwidth Delegation"

   (*) The NAS may optionnaly communicate with an
       external Autorization/Policy Server

          Figure 11: AN Autonomous Release of Multicast Bandwidth

5.4.  Multicast Accounting

   The NAS specifies if accounting is needed for a particular multicast
   flow: for Multicast flows belonging to the Grey list this can be
   conveyed in the ANCP Admission Response message sent from NAS to AN.
   For Multicast flows whose replication is controlled by the AN via the
   White list, the AN starts the multicast replication without querying
   the NAS and thus the NAS does not send Admission Response message; in
   this case the need for accounting is conveyed by the NAS in the White
   list during the White list provisioning phase.

5.4.1.  List/Profile Provisioning

   The AN provisioning is performed by NAS using a Provisioning message
   that contains White/Black/Grey lists and their corresponding
   "Multicast Profile ID".  To indicate to the AN that it need perform
   Accounting on those flows, the White List entries are flagged as
   either "Basic Accounting" or "Detailed Accounting".  The
   corresponding message flow is illustrated in Figure 12.

   Although Figure 6 shows the three lists in the ANCP provisioning
   message, the message may instead contain any subset of 2 or 1 list.









Maglione, et al.        Expires January 12, 2009               [Page 27]


Internet-Draft           ANCP Multicast Handling               July 2008


    +----------+      +---------+      +-----+                  +-----+
    |Subscriber|      |  Home   |      | AN  |                  | NAS |
    +----------+      | Gateway |      +-----+                  +-----+
         |            +---------+        |                          |
         |                 |             |                          |
         |                 |             |    Provisioning(         |
         |                 |             |(White List (Accounting), |
         |                 |             | Grey List,               |
         |                 |             | Black List,              |
         |                 |             | Profile_ID)              |
         |                 |             |<-------------------------|
         |                 |             |                          |

   (Accounting): entries in the White List flagged
         as "Basic Accounting" or "Detailed Accounting"

   Figure 12: Provisioning AN with White/Grey/Black Lists for Accounting

5.4.2.  Profile Mapping

   The "Profile ID" is associated to the port when the DSL line comes up
   in the exact same way as illustrated in Figure 2.

5.4.3.  Join & Leave Operations

   The message flows in Figure 13 illustrates the behavior of the AN in
   case of receiving a join and leave messages on the Access Port for
   multicast flows respectively part of:

   o  white list (with matching entry flagged as "Basic Accounting" or
      "Detailed Accouting")

   o  black list

   o  grey list
















Maglione, et al.        Expires January 12, 2009               [Page 28]


Internet-Draft           ANCP Multicast Handling               July 2008


   +----------+    +-------+     +-----+    ANCP    +-----+
   |Subscriber|    | Home  |     | AN  |<---------->| NAS |
   +----------+    |Gateway|     +-----+            +-----+
         |         +-------+       |                    |
         |            |            |                    |
         |            |            |                    |
         |     Join(WhiteAcct-Fl)  |                    |
         |------------+----------->|                    |
         |            |            |                    |
         |     Mcast White Flow    |                    |
         |<========================+ Replication Start  |
         |            |            |------------------->|
         |            |            |                    |
         |            |            |                    |
         |            |            |                    |
         |   Leave(WhiteAcct-Fl)   |                    |
         |------------+----------->| Information Report |
         |            |            |------------------->|
         |            |            |                    |
         |    Join(Black-Fl)       |                    |
         |------------+----------->x                    |
         |    <No Replication >    |                    |
         |    <For Black-Flow >    |                    |
         |            |            |                    |
         |            |            |                    |
         |   Join(Grey-Fl)         |   Admission        |
         |------------+----------->|    Request         |
         |            |            |------------------->|
         |            |            |     Admission     (*)
         |            |            |Response(Accounting)|
         |     Mcast Grey Flow     |<-------------------|
         |<========================+                    |
         |                         |                    |
         |            |            | Replication Start  |
         |            |            |------------------->|
         |     Leave(Grey-Fl)      |                    |
         |------------+----------->| Information Report |
         |            |            |------------------->|
         |            |            |                    |


   WhiteAcct-Fl : Multicast Flow matching an entry in White List
                   flagged as "Basic Accouting"
   Grey-Fl   : Multicast Flow matching an entry in Grey List

   (*) The NAS may optionnaly communicate with an external
       AAA Server




Maglione, et al.        Expires January 12, 2009               [Page 29]


Internet-Draft           ANCP Multicast Handling               July 2008


                      Figure 13: Multicast Accounting

5.5.  Multicast Reporting

   NAS uses "Port Report-Query" to query the AN to know which flows are
   currently active on a specific port;

   NAS uses "Multicast Flow Report-Query" to query the AN to know on
   which ports the specified multicast flow is currently active;

   NAS uses "AN global Report-Query" to query the AN to know all
   multicast flows currently active on all AN ports.

   The message flows in Figure 14 illustrates the behavior of the AN in
   case of receiving one of three Report Query messages from the NAS.

   +----------+    +-------+     +-----+    ANCP    +-----+
   |Subscriber|    | Home  |     | AN  |<---------->| NAS |
   +----------+    |Gateway|     +-----+            +-----+
         |         +-------+       |                   |
         |            |            |                   |
         |            |            | Port Report-Query |
         |            |            |     (Port ID)     |
         |  Report (Mcast flows)   |<------------------|
         |------------+----------->|                   |
         |            |            |                   |
         |            |            |                   |
         |            |            | Flow Report-Query |
         |            |            |   (Mcast Flow)    |
         |  Report (Port IDi,      |<------------------|
         |         Port IDj,..)    |                   |
         |------------+----------->|                   |
         |            |            |                   |
         |            |            |                   |
         |            |            |Global-Report-Query|
         |            |            |       (Port ID)   |
         |            |            |                   |
         |Report (All Mast Flows)  |<------------------|
         |------------+----------->|                   |


                      Figure 14: Multicast Reporting

5.6.  NAS-Controlled Multicast Replication

   The Replication Control Request Message is sent by the NAS to the AN
   with a directive to either join or leave one or more multicast flows.
   The AN will use a Replication Control Response message when conveying



Maglione, et al.        Expires January 12, 2009               [Page 30]


Internet-Draft           ANCP Multicast Handling               July 2008


   the outcome of the directive.  The message flows in Figure 15
   illustrates the behavior of the AN in case of receiving a Replication
   Control Request Message.

   +----------+    +-------+     +-----+      ANCP    +-----+
   |Subscriber|    | Home  |     | AN  |<------------>| NAS |
   +----------+    |Gateway|     +-----+              +-----+
         |         +-------+         |                     |
         |            |              |                     |
         |            |              | Replication-Crl(    |
         |            |              |   Port ID,add Flow1)|
         |            |              |<--------------------|
         |       Mcast Flow 1        |                     |
         |<==========================+                     |
         |            |              |Replication-Response |
         |            |              |   (status)          |
         |            |              |-------------------->|
         |            |              |                     |
         |            |              |                     |
         |            |              | Replication-Crl(    |
         |            |              |Port ID,delete Flow1)|
         |            |              |<--------------------|
         |            |              |                     |
         |    <Stop Replication of   x                     |
         |            Mcast Flow 1>  |Replication-Response |
         |            |              |   (status)          |
         |            |              |-------------------->|

              Figure 15: NAS-Controlled Multicast Replication






















Maglione, et al.        Expires January 12, 2009               [Page 31]


Internet-Draft           ANCP Multicast Handling               July 2008


6.  Security Considerations

   Those are addressed in [I-D.ietf-ancp-framework].
















































Maglione, et al.        Expires January 12, 2009               [Page 32]


Internet-Draft           ANCP Multicast Handling               July 2008


7.  IANA Considerations

   Not applicable.
















































Maglione, et al.        Expires January 12, 2009               [Page 33]


Internet-Draft           ANCP Multicast Handling               July 2008


8.  Acknowledgements

   The authors would like to thank Wojciech Dec for his valuable
   comments.















































Maglione, et al.        Expires January 12, 2009               [Page 34]


Internet-Draft           ANCP Multicast Handling               July 2008


9.  References

9.1.  Normative References

   [I-D.ietf-ancp-framework]
              Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband  Multi-Service Networks",
              draft-ietf-ancp-framework-06 (work in progress), May 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3292]  Doria, A., Hellstrand, F., Sundell, K., and T. Worster,
              "General Switch Management Protocol (GSMP) V3", RFC 3292,
              June 2002.

9.2.  Informative References

   [I-D.ietf-ancp-protocol]
              Wadhwa, S., "Protocol for Access Node Control Mechanism in
              Broadband Networks", draft-ietf-ancp-protocol-02 (work in
              progress), November 2007.




























Maglione, et al.        Expires January 12, 2009               [Page 35]


Internet-Draft           ANCP Multicast Handling               July 2008


Authors' Addresses

   Roberta Maglione
   Telecom Italia
   Via Reiss Romoli 274
   Torino  10148
   Italy

   Phone:
   Email: roberta.maglione@telecomitalia.it


   Angelo Garofalo
   Telecom Italia
   Via Reiss Romoli 274
   Torino  10148
   Italy

   Phone:
   Email: angelo.garofalo@telecomitalia.it


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com


   Toerless Eckert
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Email: ackert@cisco.com











Maglione, et al.        Expires January 12, 2009               [Page 36]


Internet-Draft           ANCP Multicast Handling               July 2008


   Tom Taylor
   Huawei Technologies
   1852 Lorraine Ave
   Ottawa, Ontario  K1H 6Z8
   Canada

   Phone: +1 613 680 2675
   Email: tom.taylor@rogers.com











































Maglione, et al.        Expires January 12, 2009               [Page 37]


Internet-Draft           ANCP Multicast Handling               July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Maglione, et al.        Expires January 12, 2009               [Page 38]