[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

ANCP                                                      F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                             R. Maglione
Expires: April 30, 2009                                   Telecom Italia
                                                               T. Taylor
                                                                  Huawei
                                                        October 27, 2008


            Additional Multicast Control Extensions for ANCP
               draft-lefaucheur-ancp-mc-extensions-00.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 April 30, 2009.















Le Faucheur, et al.      Expires April 30, 2009                 [Page 1]


Internet-Draft          ANCP Multicast Extensions           October 2008


Abstract

   This memorandum aims at defining additional ANCP protocol extensions
   (beyond those already defined) to support some of the Multicast use
   cases defined in the ANCP Framework document that are not yet
   supported.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  ANCP Messages  . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Provisioning Message . . . . . . . . . . . . . . . . . . .  5
     3.2.  Port Management Message  . . . . . . . . . . . . . . . . .  6
     3.3.  Multicast Admission Control Message  . . . . . . . . . . .  6
     3.4.  Multicast Replication Control Message  . . . . . . . . . .  8
     3.5.  Multicast Status Message . . . . . . . . . . . . . . . . .  9
   4.  ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Multicast-Service-Profile TLV  . . . . . . . . . . . . . . 11
     4.2.  Service-Profile TLV  . . . . . . . . . . . . . . . . . . . 14
     4.3.  Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 14
     4.4.  Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 15
     4.5.  Request-Source-IP sub-TLV  . . . . . . . . . . . . . . . . 15
     4.6.  Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 16
     4.7.  Status-Info TLV and Error Codes  . . . . . . . . . . . . . 17
   5.  New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  Example of Messages and Message Flows  . . . . . . . . . . . . 19
     6.1.  Multicast Conditional Access and CAC without AN
           Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 19
       6.1.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 19
       6.1.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 20
       6.1.3.  Successful Join/Leave Operations . . . . . . . . . . . 21
       6.1.4.  Admission Control Reject . . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     10.2. Informative References . . . . . . . . . . . . . . . . . . 33
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 35









Le Faucheur, et al.      Expires April 30, 2009                 [Page 2]


Internet-Draft          ANCP Multicast Extensions           October 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 as well as the
   corresponding ANCP Multicast requirements, ANCP Access Node Multicast
   Requirements and ANCP NAS Multicast Requirements.  The current
   version of [I-D.ietf-ancp-protocol] incorporates (or will
   incorporate) the extensions proposed in [I-D.ancp-mc-extensions].
   Therefore it supports a subset of the multicast use cases
   (specifically it supports the NAS initiated ANCP Multicast Control
   use case).  This memorandum proposes some extensions to the ANCP
   protocol to cover a bigger subset of the multicast use cases
   (specifically the Conditional Access use case and the Multicast
   Admission Control without Bandwidth delegation use case).





























Le Faucheur, et al.      Expires April 30, 2009                 [Page 3]


Internet-Draft          ANCP Multicast Extensions           October 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 [RFC2119].














































Le Faucheur, et al.      Expires April 30, 2009                 [Page 4]


Internet-Draft          ANCP Multicast Extensions           October 2008


3.  ANCP Messages

   This section defines new ANCP messages and new usage of existing ANCP
   messages as well as procedures associated with the use of these
   messages.

3.1.  Provisioning Message

   This section defines a new message called the Provisioning Message.

   The Provisioning Message is sent by the NAS to the AN to provision
   information in the AN.  This message can be used to provision
   multicast-related information (e.g.  Multicast Service Profiles,
   Bandwidth Delegation activation/deactivation) as well as non-
   multicast-related information (e.g.  Service Profile).

   The Message Type for the Provisioning Message is 93 (TBC).

   The NAS sending the Provisioning Message MUST set the Result field to
   0x00.

   The NAS MUST populate the ANCP Transaction Identifier field with a
   distinct non-zero, linearly incrementing value for each request per
   adjacency, as described in [I-D.ietf-ancp-protocol] .

   The ANCP Provisioning Message payload MAY contain the following TLVs:

   o  Service-Profile TLV: the Service-Profile TLV is defined in the
      present document in Section 4.2.  It MAY appear zero, one or
      multiple times.

   o  Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV
      is defined in the present document in Section 4.1.  It MAY appear
      zero, one or multiple times.  Each instance of the Multicast-
      Service-Profile TLV contains a (possibly empty) White List, a
      (possibly empty) Grey List, a (possibly empty) Black List and the
      Multicast Service Profile name associated with this set of three
      lists.

   o  Bandwidth-Delegation-Control TLV: The Bandwidth-Delegation-Control
      TLV is defined in the present document in Section 4.3.  It MAY
      appear zero times or once.  When present it instructs the AN on
      whether Bandwidth Delegation is to be activated or deactivated.

   On receipt of the Provisioning message, the AN MUST:

   o  ignore the Result field




Le Faucheur, et al.      Expires April 30, 2009                 [Page 5]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  if the AN can process the message successfully and accept all the
      provisioning directives contained in it, the AN MUST NOT send any
      response.

   o  [Editor's note: the behavior of the AN when it cannot process the
      message, or when it cannot accept all the provisioning directives
      contained in it is for further study.]

3.2.  Port Management Message

   As defined in [I-D.ietf-ancp-protocol], the NAS may send line
   configuration information to the AN ("ANCP based Line Configuration"
   use case) using GSMP Port Management messages modified to contain an
   extension block.  [I-D.ietf-ancp-protocol] defines a number of TLVs
   that can be included in the Extension Value field inside a Port
   Management message (e.g.  "Access-Loop-Circuit-ID", "Service-
   Profile-Name").

   This document specifies that the Port Management message MAY also be
   used by the NAS to associate a "Multicast-Service-Profile" (aka. a
   triple of White, Grey and Black lists) to a AN port.  To do so, the
   NAS includes a "Multicast-Service-Profile-Name" TLV as defined in
   Section 4.4 in the Port Management message.

3.3.  Multicast Admission Control Message

   This section defines a new message called the Multicast Admission
   Control Message.  The Multicast Admission Control Message is sent by
   the AN to the NAS to request admission or a multicast flow, or to
   notify of the removal of a multicast flow, over a given target.  The
   NAS will use a Multicast Replication Control message or a Status
   message (as discussed in Section 3.4) in order to convey back to the
   AN the outcome of the admission request.

   The Message Type for the Multicast Admission Control Message is 92
   (TBC).

   The AN sending the Multicast Admission Control Message MUST set the
   Result field to "0x00".

   The AN MUST populate the ANCP Transaction Identifier field with a
   distinct non-zero, linearly incrementing value for each request per
   adjacency, as described in [I-D.ietf-ancp-protocol] .

   The ANCP Multicast Admission Control message payload contains three
   TLVs:





Le Faucheur, et al.      Expires April 30, 2009                 [Page 6]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
      It MUST appear once and only once in the Multicast Admission
      Control message.  It is encoded as specified in
      [I-D.ietf-ancp-protocol] and identifies the AN port subject to the
      request for admission or release.

   o  Command TLV: The Command TLV is defined in
      [I-D.ietf-ancp-protocol].  It MUST be present.  If it appears more
      than once, only the first instance is considered meaningful in the
      present version of the document and the other instances are
      ignored .  The Command TLV is encoded as specified in
      [I-D.ietf-ancp-protocol] with the following additional rules:

      *  the R flag is set to 0

      *  the O flag is set to 0

      *  the Command field is set to "0x01 - Add" when the message
         conveys a Join , to "0x02 - Delete" when the message conveys a
         Leave and to "0x03 - Delete All" when the message conveys a
         Leave of all channels (on the target).

      *  The M Flag, Multicast Source Address and Multicast Flow Address
         of the Command TLV identify the multicast flow subject to the
         request for admission or release.

      *  a Request-Source-IP sub-TLV (as defined in Section 4.5) MAY be
         included by the AN to convey the IP address of the sender of
         the join/leave message (e.g.  IGMP Join/Leave) that triggered
         the AN to include the corresponding Command TLV in the
         Admission Control message.  If it appears more than once, only
         the first instance is considered meaningful and the other
         instances are ignored.

      *  a Request-Source-MAC sub-TLV (as defined in Section 4.6) MAY be
         included by the AN to convey the MAC address of the sender of
         the join/leave message (e.g.  IGMP Join/Leave) that triggered
         the AN to include the corresponding Command TLV in the
         Admission Control message.  If it appears more than once, only
         the first instance is considered meaningful and the other
         instances are ignored.

   In the future, the specification of the Admission Control Message may
   be extended to allow transport of more than a single directive (e.g.
   to carry both a leave from one group and a join to another group for
   the same Target).  It is expected that this would support a similar
   notion of strict sequenced processing as currently defined for
   handling multiple directives in the Multicast Replication Control



Le Faucheur, et al.      Expires April 30, 2009                 [Page 7]


Internet-Draft          ANCP Multicast Extensions           October 2008


   message whereby all directives following the first directive that can
   not be executed are not executed either.  When the strict sequenced
   processing of the directives is not required the directives are
   distributed across separate messages

3.4.  Multicast Replication Control Message

   The [I-D.ietf-ancp-framework] describes the NAS initiated ANCP
   Multicast Control use case.  In this use case, the NAS issues ANCP
   directives to the AN (to instructs the AN to either add (join) or
   delete (leave) multicast flows without the AN having previously
   issued corresponding ANCP requests.  To support this use
   case[I-D.ietf-ancp-protocol] defines the Multicast Replication
   Control Message and how that message can be used from the NAS to the
   AN to convey a directive to either add (join) or delete (leave) one
   or more multicast flows.

   This section specifies another use of the Multicast Replication
   Control Message in order to support the Multicast Admission Control
   use cases defined in [I-D.ietf-ancp-framework].  To support that use
   case, the Multicast Replication Control message can also used by the
   NAS in response to a Multicast Admission Control from the AN.

   On receipt of an Multicast Admission Control message, the NAS:

   o  MUST ignore the Result field

   o  if the directive in the Multicast Admission Control Message is
      "0x02 - Delete" or "0x03 - Delete All" and is processed correctly
      by the NAS, the NAS MUST NOT generate any ANCP message in response
      to the Multicast Admission Control Message

   o  if the directive in the Multicast Admission Control Message is
      "0x01 - Add" and is accepted by the NAS, the NAS MUST generate a
      Multicast Replication Control in response to the Multicast
      Admission Control Message.  The Multicast Replication Control
      Message:

      *  MUST contain a Result set to 0x00

      *  MUST contain a Transaction ID generated by the NAS (distinct
         non-zero, and linearly incremented by NAS for each request per
         adjacency).

      *  MUST contain the directive as accepted by the NAS






Le Faucheur, et al.      Expires April 30, 2009                 [Page 8]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  if the directive in the Multicast Admission Control Message is
      "0x01 - Add", is processed correctly but not accepted by the NAS
      (i.e. it does not pass the admission control or conditional access
      check), the NAS MUST generate a Multicast Status Message in
      response to the Multicast Admission Control Message.  The Status
      Message:

      *  MUST contain a Result set to "Failure" in the ANCP header

      *  MUST contain a Transaction ID that echoes the value of the
         Transaction ID received in the Multicast Admission Control
         Message.

      *  MUST contain a Status TLV with a Result Code set to "Admission
         Control reject" or "Conditional Access reject" or "Admission
         Control and Conditional Access reject" (see Section 4.7).

   o  if the Multicast Admission Control Message cannot be processed
      correctly by the NAS (e.g. the message is malformed, the multicast
      flow does not exist etc.), the NAS MUST generate a Multicast
      Status Message in response to the Multicast Admission Control
      Message.  The Status Message:

      *  MUST contain a Result set to "Failure" in the ANCP header

      *  MUST contain a Transaction ID that echoes the value of the
         Transaction ID received in the Multicast Admission Control
         Message.

      *  MUST contain a Status TLV including a Result Code indicating
         the reason why the Admission Control Message could not be
         processed and encoded as specified in [I-D.ietf-ancp-protocol].

3.5.  Multicast Status Message

   [I-D.ietf-ancp-protocol] defines the Multicast Status Message and how
   that message can be used in response to a Replication Control Message
   in order to support of the NAS initiated ANCP Multicast Control use
   case.

   This section specifies other uses of the Multicast Status Message in
   order to support the Multicast Admission Control use cases defined in
   [I-D.ietf-ancp-framework].

   First, the Multicast Status message is used by the NAS in some
   situations as specified in Section 3.4 in response to a Multicast
   Admission Control message from the AN.




Le Faucheur, et al.      Expires April 30, 2009                 [Page 9]


Internet-Draft          ANCP Multicast Extensions           October 2008


   Secondly, when the AN receives a Multicast Replication Control
   message (that is a response to a Multicast Admission Control message
   sent earlier by the AN), the AN can use the Multicast Status Message
   message to respond to the Multicast Replication Control message
   exactly as already defined in [I-D.ietf-ancp-protocol] for the NAS
   initiated ANCP Multicast Control use case.  For example, if the AN
   cannot process the Multicast Replication Control message, it MUST
   respond with a Status Message with a Result set to Failure and a
   Status TLV indicating the reason of the failure (e.g. 0x09 - Target
   port down).









































Le Faucheur, et al.      Expires April 30, 2009                [Page 10]


Internet-Draft          ANCP Multicast Extensions           October 2008


4.  ANCP TLVs and Sub-TLVs

   This section defines new ANCP TLVs and sub-TLVs or extends existing
   ones.

4.1.  Multicast-Service-Profile TLV

   This document defines the new Multicast-Service-Profile TLV.

   The Multicast-Service-Profile TLV MAY be included in a Provisioning
   message as specified in Section 3.1.

   The Multicast-Service-Profile is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Mcast Service Profile |             TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Multicast-Service-Profile-Name Sub-TLV                      |
       |   Sub-TLV tag = 0x0001                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   White-List Sub-TLV                                          |
       |   Sub-TLV tag = 0x0002                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Grey-List Sub-TLV                                           |
       |   Sub-TLV tag = 0x0003                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Black-List Sub-TLV                                          |
       |   Sub-TLV tag = 0x0004                                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Each of the four sub-TLVs begins with a 32-bit header consisting of a
   16-bit sub-TLV tag followed by a 16-bit length field giving the
   amount of data following this sub-TLV header in octets.  The tag
   values for the respective sub-TLVs are indicated in the figure.  The
   content of the sub-TLV follows immediately after the sub-TLV header.
   The sub-TLVs are placed into the list consecutively without
   intervening padding.  The Multicast Service Profile Name sub-TLV MUST
   be present, and MUST be unique over all profiles provisioned to the
   same AN.  At least one other sub-TLV MUST be present, but any of
   White List, Grey List, or Black List sub-TLV MAY be omitted if not
   applicable to this profile.  Those sub-TLVs present MUST be ordered
   by increasing tag value.

   The Multicast-Service-Profile-Name sub-TLV is an opaque sequence of
   octets used to refer to the profile when activating it for a given
   target within a Port Management message (see Section 3.2).



Le Faucheur, et al.      Expires April 30, 2009                [Page 11]


Internet-Draft          ANCP Multicast Extensions           October 2008


   The content of the White-List, Grey-List, and Black-List sub-TLVs
   following their respective headers is in each case a sequence of
   multicast flow fields as described below.

   [***Will the addresses in a given profile either be all IPv4 or all
   IPv6, or can they be mixed?  If they're all the same, we should have
   an address-type sub-TLV following the profile name.***]

   Each multicast flow field refers either to a Single Source Multicast
   (SSM) channel or to an Any Source Multicast (ASM) group.  The scope
   of the designation may be broadened to multiple channels or groups
   through use of non-zero mask values.  Multicast flow fields MUST be
   placed consecutively within the sub-TLV without intervening padding.

   A multicast flow field consists of a three octet header followed by
   one (in case of ASM) or two (in case of SSM) address values as shown
   below:


       +-+-+-+-+-+-+-+-+
       | IP ver        |
       +-+-+-+-+-+-+-+-+
       | Group Mask    |
       +-+-+-+-+-+-+-+-+
       | Source Mask   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Group Address (multicast)                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Source Address (unicast, SSM only)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The header defines the IP version of the group and source addresses,
   the number of unspecified low-order bits of the group address, and
   the number of unspecified low-order bits of the source address.  The
   IP version octet MUST have value 0x00 for IPv4 addresses, 0x01 for
   IPv6 addresses.  A value of 0xFF for either the Group Mask or the
   Source Mask indicates that any value of the corresponding address
   will match (wild card).  If the value 0xFF is provided for a
   particular mask, the corresponding address MUST be omitted from the
   field contents.  In particular, a value of 0xFF for the Source Mask
   indicates an ASM multicast entry, and the Source Address will be
   absent.

   The total length of a multicast address field has the following
   possible values:





Le Faucheur, et al.      Expires April 30, 2009                [Page 12]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  3 octets (the header only) for a totally wildcarded entry;

   o  7 octets for an IPv4 ASM entry or an IPv4 SSM entry with
      wildcarded group address;

   o  11 octets for an IPv4 SSM entry with no wildcarding;

   o  19 octets for an IPv6 ASM entry or an IPv6 SSM entry with
      wildcarded group address;

   o  35 octets for an IPv6 SSM entry with no wildcarding.

   When a given multicast service profile has been activated on a given
   AN port (using the Port Management message as defined in
   Section 3.2):

   o  On receipt of a join message on an Access Port whose multicast
      flow matches the White List, the AN autonomously starts
      replicating multicast traffic.  On receipt of a leave message on
      an Access Port whose multicast flow matches the White List, the AN
      autonomously stops replicating multicast traffic.

   o  On receipt of a join message on an Access Port whose multicast
      flow matches the Grey List, the AN uses ANCP to query the NAS,
      that in turn 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.)  On
      receipt of a leave message on an Access Port whose multicast flow
      matches the Grey List, the AN autonomously stops replicating
      multicast traffic and the AN notifies the NAS.

   o  On receipt of a join message on an Access Port whose multicast
      flow matches the Black List, the AN autonomously discards the join
      message.

   If the requested multicast flow matches multiple lists associated
   with the Access Port, then the most specific match will be considered
   by the AN.  If the most specific match occurs in multiple lists, the
   Black list entry takes precedence over the Grey list, which takes
   precedence over the White list.  In this context, the most specific
   match is defined as:

   o  first, most specific match on the multicast flow address (i.e. on
      G of <S,G>)

   o  then, most specific match on the multicast source address (i.e. on
      S of <S,G>)




Le Faucheur, et al.      Expires April 30, 2009                [Page 13]


Internet-Draft          ANCP Multicast Extensions           October 2008


   If the requested multicast flow is not part of any list, the join
   message should be discarded by the AN.  This default behavior can
   easily be changed by means of a "catch-all" statement in either the
   White list or the Grey list.  For instance, adding (<S=*,G=*>) in the
   White List would make the default behavior to accept join messages
   for a multicast flow that has no other match on any list.

4.2.  Service-Profile TLV

   This TLV is outside the scope of the present document as it is not
   related to Multicast.  It may be defined as part of a separate effort
   and is expected to allow configuration of all the relevant parameters
   of a service profile as well as its Service Profile Name.

4.3.  Bandwidth-Delegation-Control TLV

   This document defines the new Bandwidth-Delegation-Control TLV.

   The Bandwidth-Delegation-Control TLV MAY be included in a
   Provisioning message as specified in Section 3.1.

   The Bandwidth-Delegation-Control is illustrated below:

        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Band-Del-Control    |             TLV Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|                Reserved                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Bandwidth-Delegation-Control TLV Type:

             TLV (0xTBD) : indicating that this is a Bandwidth-
             Delegation-Control TLV

   Bandwidth-Delegation-Control TLV Length:

             Combined length in bytes of the data inside sub-TLV.
             Excludes the sub-TLV Header.

   E Flag::

             When set to 0, indicates that Bandwidth Delegation is to be
             disabled on the AN.  When set to 1, indicates that
             Bandwidth Delegation is to be enabled on the AN.  When
             Bandwidth Delegation is enabled, the AN MUST subject
             multicast channels matching the White List or the Grey List



Le Faucheur, et al.      Expires April 30, 2009                [Page 14]


Internet-Draft          ANCP Multicast Extensions           October 2008


             to admission control according to the Bandwidth Delegation
             procedures defined in [I-D.ietf-ancp-framework].

4.4.  Multicast-Service-Profile-Name TLV

   [I-D.ietf-ancp-protocol] defines an Extension TLV that can be used in
   ANCP messages.  It also defines a number of TLVs that can be included
   in the Extension TLV when present (with a Tech Type set to "DSL") in
   a Port Management message (e.g.  "Access-Loop-Circuit-ID", "Service-
   Profile-Name").

   This document defines an additional TLV that can appear in an
   Extension TLV of Tech Type "DSL" in a Port Management message:

   o  Type (Multicast-Service-Profile-Name = 0x06 - TBC): Reference to a
      multicast service profile on the AN, that defines a <White List,
      Black List, Grey List> triple.

         Length : (up to 64 bytes)

         Value : ASCII string containing the multicast profile name.

4.5.  Request-Source-IP sub-TLV

   [I-D.ietf-ancp-protocol] defines the Command TLV that can be used in
   a Multicast Replication Control Message and (as defined in this
   document) in the Admission Control message.  The Command TLV MAY
   include sub-TLVs immediately following the Command Info field.

   This document defines the new Request-Source-IP sub-TLV.

   The Request-Source-IP sub-TLV MAY be included in a Command TLV inside
   an Admission Control message.

   The Request-Source-IP sub-TLV is illustrated below:


        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type   |   Unicast Address           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Request-Source-IP sub-TLV Type:





Le Faucheur, et al.      Expires April 30, 2009                [Page 15]


Internet-Draft          ANCP Multicast Extensions           October 2008


             sub-TLV (0xTBD) indicating the contents to be one or more
             command directives.

   Request-Source-IP sub-TLV Length:

             Combined length in bytes of the data inside sub-TLV.
             Excludes the sub-TLV Header.

   Address Family, Encoding type and Unicast Address:

             Contains the IP address of the sender of the join/leave
             message (e.g.  IGMP Join/Leave) that triggered the AN to
             include the corresponding Command TLV in an Admission
             Control message.  The IP address is encoded as per
             [IANAAEA].

4.6.  Request-Source-MAC sub-TLV

   This document defines the new Request-Source-MAC sub-TLV.

   The Request-Source-MAC sub-TLV MAY be included in a Command TLV
   inside an Admission Control message.

   The Request-Source-MAC sub-TLV is illustrated below:


        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |sub-TLV Type=Request-Source-MAC  |Request-S-MAC sub-TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TBD                                                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Request-Source-MAC sub-TLV Type:

             sub-TLV (0xTBD) indicating the contents to be one or more
             command directives.

   Request-Source-MAC sub- TLV Length:

             Combined length in bytes of the data inside sub-TLV.
             Excludes the sub-TLV Header.

   TBD:






Le Faucheur, et al.      Expires April 30, 2009                [Page 16]


Internet-Draft          ANCP Multicast Extensions           October 2008


             Contains the IEEE MAC address of the sender of the join/
             leave message (e.g.  IGMP Join/Leave) that triggered the AN
             to include the corresponding Command TLV in an Admission
             Control message.  The IP address is encoded as per TBD.

4.7.  Status-Info TLV and Error Codes

   [I-D.ietf-ancp-protocol] defines the Status-Info TLV that can be used
   in a Multicast Status Message.  The Status-Info TLV contains an Error
   Code field and a number of values are already defined for this field.

   The present document specifies the following new additional values
   for the Error Code of the Status-Info TLV:

        0x11 - Admission Control reject

        0x12 - Conditional Access reject

        0x13 - Admission Control and Conditional Access reject
































Le Faucheur, et al.      Expires April 30, 2009                [Page 17]


Internet-Draft          ANCP Multicast Extensions           October 2008


5.  New Capabilities

   [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism
   as well as a number of capabilities.  This document defines two new
   capabilities for support of the Multicast Admission Control use case:

   o  Capability Type : Multicast Admission Control without Bandwidth
      Delegation = 0x05 (TBC)

         Length (in bytes) : 0

         Capability Data : NULL

   o  Capability Type : Multicast Admission Control without and with
      Bandwidth Delegation = 0x06 (TBC)

         Length (in bytes) : 0

         Capability Data : NULL

   A NAS or AN supporting the "Multicast Admission Control without
   Bandwidth Delegation" capability MUST support the Multicast Admission
   Control Message, the Multicast Replication Message and the Multicast
   Status Message.

   A NAS or AN supporting the "Multicast Admission Control without and
   with Bandwidth Delegation" capability MUST support the Multicast
   Admission Control Message, the Multicast Replication Message, the
   Multicast Status Message as well as the (to be defined) additional
   messages that are required to support the "Multicast Admission
   Control with Bandwidth Delegation" use case.




















Le Faucheur, et al.      Expires April 30, 2009                [Page 18]


Internet-Draft          ANCP Multicast Extensions           October 2008


6.  Example of Messages and Message Flows

   This section provides example message flows.

6.1.  Multicast Conditional Access and CAC without AN Bandwidth
      Delegation

   This section describes ANCP operations when multicast flows are
   subject to multicast Conditional Access and Admission Control without
   Bandwidth Delegation.

6.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 Service Profile Name".  To indicate to the AN that it need
   not perform any CAC operation on those flows, the Provisioning
   message also conveys an indication that Bandwidth Delegation is to be
   deactivated.  The corresponding message flow is illustrated in
   Figure 1.

 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |(M1) Provisioning    |
      |                 |                      | (Mcast S Prof name, |
      |                 |                      |     White List,     |
      |                 |                      |      Grey List,     |
      |                 |                      |      Black List,    |
      |                 |                      | Bw Del Deactivated) |
      |                 |                      |<--------------------|


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

   The Provisioning Message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 93 - Provisioning

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS




Le Faucheur, et al.      Expires April 30, 2009                [Page 19]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  a Multicast-Service-Profile TLV containing:

      *  a Multicast-Service-Profile-Name sub-TLV

      *  an Empty White-List in our example (and hence no White-List
         sub-TLV)

      *  a Grey-List sub-TLV containing a catch-all entry for IPv4 (in
         our example)

      *  an Empty Back-List in our example (and hence no Black-List sub-
         TLV)

   The Provisioning Message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=93 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0008      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Mcast-Service-Prof TLV Type   | Mcast-Service-Prof TLV Length |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sub-TLV Type = 0x0001         |       sub-TLV Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Multicast service profile name             ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | sub-TLV Type = 0x0003         |       sub-TLV Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 0x00          | 0xFF          |  0xFF         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



6.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 Service Profile Name to be
   associated to that Port.  The corresponding message flow is
   illustrated in Figure 2.



Le Faucheur, et al.      Expires April 30, 2009                [Page 20]


Internet-Draft          ANCP Multicast Extensions           October 2008


 +----------+      +---------+               +-----+             +-----+
 |Subscriber|      |  Home   |               | AN  |             | NAS |
 +----------+      | Gateway |               +-----+             +-----+
      |            +---------+                 |                     |
      |                 |                      |                     |
      |                 |                      |                     |
      |                 |      DSL Synch.      |                     |
      |                 |--------------------->|                     |
      |                 |                      |(M1)PORT_UP(Port ID) |
      |                 |                      |-------------------->|
      |                 |                      |                    (*)
      |                 |                      |(M2) PORT_MNGT       |
      |                 |                      |    (Port ID,        |
      |                 |                      |Mcast S Profile Name)|
      |                 |                      |<--------------------|


(*) The NAS may optionally seek direction from an external
    Autorization/Policy Server

                Figure 2: Associating Profile ID to AN Port

6.1.3.  Successful Join/Leave Operations

   The message flows in Figure 3 illustrates the ANCP message flow in
   case of a simple join and leave for a multicast flow that matches the
   grey list and when the "Bandwidth Delegation" mechanism is not
   activated in the AN.  In that case the AN queries the NAS that
   performs Conditional Access and Admission Control.






















Le Faucheur, et al.      Expires April 30, 2009                [Page 21]


Internet-Draft          ANCP Multicast Extensions           October 2008


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |     Multicast     |
         |           |           |     Replication  (*)
         |           |           |     Control (M2)  |
         |     Mcast Grey Flow   |<------------------|
         |<======================+                   |
         |           |           |                   |
         ~           ~           ~                   ~
         |           |           |                   |
         |     Leave(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M3) |
         |           |           |------------------>|
         |           |           |                   |



   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (Bandwidth Delegation not activated on AN)

   (*) The NAS may optionally seek direction from an external
       Autorization/Policy Server

                  Figure 3: Multicast Conditional Access

   The Multicast Admission Control Message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Add




Le Faucheur, et al.      Expires April 30, 2009                [Page 22]


Internet-Draft          ANCP Multicast Extensions           October 2008


      *  R = 0

      *  O = 0

      *  the multicast flow for which the IGMP Join was received by AN=
         (192.0.2.1, 233.252.2.2)

      *  a Request-Source-IP sub-TLV containing the IGMP join source IP
         (192.0.2.100).

   The Multicast Admission Control Message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+



   The Multicast Replication Control Message M2 contains:





Le Faucheur, et al.      Expires April 30, 2009                [Page 23]


Internet-Draft          ANCP Multicast Extensions           October 2008


   o  an ANCP Header with:

      *  Message-Type = 90 - Multicast Replication Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Add

      *  R= 1 (since in our example the flow resources have been
         admitted by NAS)

      *  O = 0 (since in our example flow accounting is not required)

      *  the multicast flow for which the IGMP Join was received by AN=
         (192.0.2.1, 233.252.2.2)

   The Multicast Admission Control Message M2 is illustrated below:




























Le Faucheur, et al.      Expires April 30, 2009                [Page 24]


Internet-Draft          ANCP Multicast Extensions           October 2008


       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=90 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0009      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |1 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+




   The Multicast Admission Control Message M3 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Delete

      *  R = 0




Le Faucheur, et al.      Expires April 30, 2009                [Page 25]


Internet-Draft          ANCP Multicast Extensions           October 2008


      *  O = 0

      *  the multicast flow for which the IGMP leave was received by AN=
         (192.0.2.1, 233.252.2.2)

      *  a Request-Source-IP sub-TLV containing the IGMP join source IP
         (192.0.2.100).

   The Multicast Admission Control Message M3 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0002      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0002 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.2     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = 0xTBD (Request-S.) TLV  |    Request-S.-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+









Le Faucheur, et al.      Expires April 30, 2009                [Page 26]


Internet-Draft          ANCP Multicast Extensions           October 2008


6.1.4.  Admission Control Reject

   The message flow in Figure 4 illustrates the ANCP message flow in
   case of a join that is rejected by the NAS because of admission
   control.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |     Multicast    (*)
         |           |           |     Status (M2)   |
         |     Mcast Grey Flow   |<------------------|
         |       not replicated  x                   |
         |           |           |                   |


   Grey-Fl   : Multicast Flow matching an entry in Grey List
               (Bandwidth Delegation not activated on AN)

   (*) The NAS may optionally seek direction from an external
       Autorization/Policy Server

                  Figure 4: Multicast Conditional Access

   The Multicast Admission Control Message M1 contains:

   o  an ANCP Header with:

      *  Message-Type = 92 - Multicast Admission Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by AN

   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Add

      *  R = 0




Le Faucheur, et al.      Expires April 30, 2009                [Page 27]


Internet-Draft          ANCP Multicast Extensions           October 2008


      *  O = 0

      *  the multicast flow for which the IGMP join was received by AN=
         (192.0.2.1, 233.252.2.3).

      *  a Request-Source-IP sub-TLV containing the IGMP join source IP
         (192.0.2.100).

   The Multicast Admission Control Message M1 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=92 | 0x00  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0003      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Type = 0xTBD (Command) TLV   |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.3     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+



   The Multicast Status Message M2 contains:

   o  an ANCP Header with:





Le Faucheur, et al.      Expires April 30, 2009                [Page 28]


Internet-Draft          ANCP Multicast Extensions           October 2008


      *  Message-Type = 91 - Status

      *  Result= Failure

      *  Transaction-ID = Transaction-ID contained in the Multicast
         Admission Control message that triggered this Multicast Satus
         message

   o  a Status-Info TLV containing:

      *  Result Code = Admission Control reject

   o  a Target TLV identifying the AN Port

   The Multicast Status Message M2 is illustrated below:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type (0x88-0C)         |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Vers  |  Sub  |MessageType=91 | 0x03  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0003      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    TLV Type = Status-Info     |    Status-Info TLV Length     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |adm cont reject|    0x00       |      0x00                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1000 (Target)      |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+













Le Faucheur, et al.      Expires April 30, 2009                [Page 29]


Internet-Draft          ANCP Multicast Extensions           October 2008


7.  Security Considerations

   The security considerations of ANCP are discussed in
   [I-D.ietf-ancp-protocol] and in [I-D.ietf-ancp-security-threats].















































Le Faucheur, et al.      Expires April 30, 2009                [Page 30]


Internet-Draft          ANCP Multicast Extensions           October 2008


8.  IANA Considerations

   This document defines new ANCP messages, TLVs, sub-TLVs and error
   codes.  The corresponding IANA considerations will be defined if/when
   the proposed extenesions are folded in the ANCP protocol document.














































Le Faucheur, et al.      Expires April 30, 2009                [Page 31]


Internet-Draft          ANCP Multicast Extensions           October 2008


9.  Acknowledgements

   The authors would like to acknowledge Wojciech Dec for providing
   useful input to this document.















































Le Faucheur, et al.      Expires April 30, 2009                [Page 32]


Internet-Draft          ANCP Multicast Extensions           October 2008


10.  References

10.1.  Normative References

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

10.2.  Informative References

   [I-D.ancp-mc-extensions]
              Champagne, P., Dec, W., Wadhwa, S., Cnodder, S., and R.
              Maglione, "Multicast Control Extensions for ANCP",
              draft-ancp-mc-extensions-00 (work in progress), July 2008.

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

   [I-D.ietf-ancp-protocol]
              Moisand, J., Subramanian, S., Haag, T., Voigt, N., and S.
              Wadhwa, "Protocol for Access Node Control Mechanism in
              Broadband Networks", draft-ietf-ancp-protocol-03 (work in
              progress), July 2008.

   [I-D.ietf-ancp-security-threats]
              Moustafa, H., Tschofenig, H., and S. Cnodder, "Security
              Threats and Security Requirements for the Access Node
              Control  Protocol (ANCP)",
              draft-ietf-ancp-security-threats-06 (work in progress),
              October 2008.

   [IANAAEA]  "http://www.iana.org/assignments/address-family-numbers",
              2005.
















Le Faucheur, et al.      Expires April 30, 2009                [Page 33]


Internet-Draft          ANCP Multicast Extensions           October 2008


Authors' Addresses

   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


   Roberta Maglione
   Telecom Italia
   Via Reiss Romoli 274
   Torino  10148
   Italy

   Phone:
   Email: roberta.maglione@telecomitalia.it


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

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





















Le Faucheur, et al.      Expires April 30, 2009                [Page 34]


Internet-Draft          ANCP Multicast Extensions           October 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.











Le Faucheur, et al.      Expires April 30, 2009                [Page 35]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/