[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-lefaucheur-ancp-mc-extensions) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16

ANCP                                                      F. Le Faucheur
Internet-Draft                                                     Cisco
Intended status: Standards Track                             R. Maglione
Expires: January 4, 2010                                  Telecom Italia
                                                               T. Taylor
                                                                  Huawei
                                                            July 3, 2009


            Additional Multicast Control Extensions for ANCP
                  draft-ietf-ancp-mc-extensions-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 4, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the



Le Faucheur, et al.      Expires January 4, 2010                [Page 1]

Internet-Draft          ANCP Multicast Extensions              July 2009


   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.












































Le Faucheur, et al.      Expires January 4, 2010                [Page 2]

Internet-Draft          ANCP Multicast Extensions              July 2009


Abstract

   This document specifies the extensions to the Access Node Control
   Protocol required for support of the multicast use cases defined in
   the Access Node Control Protocol framework document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Multicast Use Cases  . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  NAS Initiated Multicast Replication Control Use Case . . .  7
       3.1.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  Message Flow . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Conditional Access and Admission Control Use Case  . . . .  8
       3.2.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Message Flow . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Multicast Flow Reporting Use Case  . . . . . . . . . . . .  9
       3.3.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.2.  Message Flow . . . . . . . . . . . . . . . . . . . . . 10
   4.  ANCP Messages  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Provisioning Message . . . . . . . . . . . . . . . . . . . 11
     4.2.  Port Management Message  . . . . . . . . . . . . . . . . . 11
     4.3.  Multicast Replication Control Message  . . . . . . . . . . 12
     4.4.  Multicast Status Message . . . . . . . . . . . . . . . . . 17
     4.5.  Multicast Admission Control Message  . . . . . . . . . . . 20
     4.6.  Bandwidth Reallocation Request Message . . . . . . . . . . 23
     4.7.  Bandwidth Transfer Message . . . . . . . . . . . . . . . . 25
     4.8.  Delegated Bandwidth Query Request and Response Messages  . 26
     4.9.  Multicast Flow Query Request and Response Messages . . . . 28
     4.10. Delegated Bandwidth Reset Procedure  . . . . . . . . . . . 30
   5.  ANCP TLVs and Sub-TLVs . . . . . . . . . . . . . . . . . . . . 32
     5.1.  Multicast-Service-Profile TLV  . . . . . . . . . . . . . . 32
       5.1.1.  Profile Processing At the Access Node  . . . . . . . . 34
     5.2.  Bandwidth-Delegation-Control TLV . . . . . . . . . . . . . 36
     5.3.  Bandwidth-Allocation TLV . . . . . . . . . . . . . . . . . 37
     5.4.  Bandwidth-Request TLV  . . . . . . . . . . . . . . . . . . 38
     5.5.  Bandwidth-Status TLV . . . . . . . . . . . . . . . . . . . 38
     5.6.  Multicast-Service-Profile-Name TLV . . . . . . . . . . . . 39
     5.7.  Request-Source-IP sub-TLV  . . . . . . . . . . . . . . . . 39
     5.8.  Request-Source-MAC sub-TLV . . . . . . . . . . . . . . . . 40
     5.9.  Multicast-Flow TLV . . . . . . . . . . . . . . . . . . . . 41
   6.  New Capabilities . . . . . . . . . . . . . . . . . . . . . . . 43
   7.  Example of Messages and Message Flows  . . . . . . . . . . . . 45
     7.1.  Multicast Conditional Access and CAC without AN
           Bandwidth Delegation . . . . . . . . . . . . . . . . . . . 45
       7.1.1.  List/Profile Provisioning  . . . . . . . . . . . . . . 45



Le Faucheur, et al.      Expires January 4, 2010                [Page 3]

Internet-Draft          ANCP Multicast Extensions              July 2009


       7.1.2.  Profile Mapping  . . . . . . . . . . . . . . . . . . . 47
       7.1.3.  Successful Join/Leave Operations . . . . . . . . . . . 47
       7.1.4.  Admission Control Reject without NAS Response  . . . . 53
       7.1.5.  Admission Control Reject with NAS Response . . . . . . 55
     7.2.  Example Flows For Bandwidth Delegation . . . . . . . . . . 59
       7.2.1.  Activation and Provisioning of Delegated Bandwidth . . 60
       7.2.2.  Successful Request For More Delegated Bandwidth  . . . 61
       7.2.3.  Failed Autonomous Transfer With Reset  . . . . . . . . 63
     7.3.  Example Flows For Multicast Flow Reporting . . . . . . . . 66
       7.3.1.  Per Port Multicast Flow Reporting  . . . . . . . . . . 66
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 71
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 72
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 77
     11.2. Informative References . . . . . . . . . . . . . . . . . . 77
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 79


































Le Faucheur, et al.      Expires January 4, 2010                [Page 4]

Internet-Draft          ANCP Multicast Extensions              July 2009


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 in broadband networks in line with this framework.

   The Access Node Control Protocol (ANCP) specified in
   [I-D.ietf-ancp-protocol] supports a number of use cases defined in
   [I-D.ietf-ancp-framework] such as the Access Topology Discovery use
   case, the Access Loop Configuration use case and the Remote
   Connectivity Test use case.  However, it does not support the
   multicast use cases defined in [I-D.ietf-ancp-framework].  The
   present document specifies the extensions to the Access Node Control
   Protocol required for support of these multicast use cases.

































Le Faucheur, et al.      Expires January 4, 2010                [Page 5]

Internet-Draft          ANCP Multicast Extensions              July 2009


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

   The expression "delegated bandwidth" is used as a shorter way of
   saying: "the total amount of video bandwidth delegated to the AN for
   multicast admission control".










































Le Faucheur, et al.      Expires January 4, 2010                [Page 6]

Internet-Draft          ANCP Multicast Extensions              July 2009


3.  Multicast Use Cases

   Quoting from [I-D.ietf-ancp-framework]:

   "... the Access Node, aggregation node(s) and the NAS must all be
   involved in the multicast replication process.  This avoids that
   several copies of the same stream are sent within the access/
   aggregation network.  In case of an Ethernet-based access/aggregation
   network, this may, for example, be achieved by means of IGMP snooping
   or IGMP proxy in the Access Node and aggregation node(s).  By
   introducing IGMP processing in the access/aggregation nodes, the
   multicast replication process is now divided between the NAS, the
   aggregation node(s) and Access Nodes.  In order to ensure backward
   compatibility with the ATM-based model, the NAS, aggregation node and
   Access Node need to behave as a single logical device.  This logical
   device must have exactly the same functionality as the NAS in the ATM
   access/aggregation network.  The Access Node Control Mechanism can be
   used to make sure that this logical/functional equivalence is
   achieved by exchanging the necessary information between the Access
   Node and the NAS.  "

   [I-D.ietf-ancp-framework] describes the use cases for ANCP associated
   with such multicast operations, and identifies the associated ANCP
   requirements.  The present section describes a subset of these use
   cases as background to facilitate reading of this document, but the
   reader is refered to [I-D.ietf-ancp-framework] for a more exhaustive
   description of the ANCP multicast use cases.  Detailed example
   message flows can also be found in Section 7.

3.1.  NAS Initiated Multicast Replication Control Use Case

3.1.1.  Goals

   One option for multicast handling is for the subscriber to
   communicate the "join/leave" information to the NAS.  This can be
   done for instance by terminating all subscriber IGMP ([RFC3376]) or
   MLD ([RFC2710], [RFC3810]) signaling on the NAS.  Another example
   could be a subscriber using some form of application level signaling,
   which is redirected to the NAS.  In any case, this option is
   transparent to the access and aggregation network.  In this scenario,
   the NAS uses ANCP to create and remove replication state in the AN
   for efficient multicast replication.  Thus, the NAS only sends a
   single copy of the multicast stream towards the AN, which in turn
   performs replication to multiple subscribers as instructed by the NAS
   via ANCP.  The NAS first performs conditional access and multicast
   admission control when processing multicast join requests, and only
   creates replication state in the AN if admission succeeds.




Le Faucheur, et al.      Expires January 4, 2010                [Page 7]

Internet-Draft          ANCP Multicast Extensions              July 2009


3.1.2.  Message Flow

   With the NAS-initiated use case, a Multicast Replication Control
   Message is sent by the NAS to the AN with a directive to either join
   or leave one (or more) multicast flow(s).  The AN uses a Multicast
   Status Message to convey the outcome of the directive.  Figure 1
   illustrates such an ANCP message exchange as well as the associated
   AN behavior.

   +----------+    +-------+     +-----+        ANCP          +-----+
   |Subscriber|    | Home  |     | AN  |<-------------------->| NAS |
   +----------+    |Gateway|     +-----+                      +-----+
         |         +-------+         |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,add, Flow 1)    |
         |            |              |<--------------------------|
         |       Mcast Flow 1        |                           |
         |<==========================+                           |
         |            |              |     Multicast-Status      |
         |            |              |-------------------------->|
         |            |              |                           |
         |            |              |                           |
         ~            ~              ~                           ~
         |            |              |                           |
         |            |              | Multicast-Replication-Crl |
         |            |              |   (Target,delete, Flow 1) |
         |            |              |<--------------------------|
         |            |              |                           |
         |  <Stop Replication of     X                           |
         |            Mcast Flow 1>  |     Multicast-Status      |
         |            |              |-------------------------->|

           Figure 1: NAS Initiated Multicast Replication Control

3.2.  Conditional Access and Admission Control Use Case

3.2.1.  Goals

   One option for multicast handling is for the access/aggregation nodes
   to participate in IGMP/MLD processing (e.g. via IGMP/MLD snooping).
   In this scenario, on detecting a join/leave request from an enduser
   for a multicast flow, the AN uses ANCP to request conditional access
   and admission control decision from the NAS.  In turn, after
   conditional access and admission control checks, the NAS uses ANCP to
   instruct the AN to change the replication states accordingly.






Le Faucheur, et al.      Expires January 4, 2010                [Page 8]

Internet-Draft          ANCP Multicast Extensions              July 2009


3.2.2.  Message Flow

   For support of the conditional access and admission control use case,
   on detection of an IGMP/MLD Join, the AN sends an Admission Control
   message to the NAS to request conditional access and admission
   control check.  In case of positive outcome, the NAS sends a
   Multicast Replication Control Message to the AN with a directive to
   replicate the multicast flow to the corresponding user.  Similarly on
   detection of an IGMP/MLD leave, an Admission Control message is sent
   by the AN to the NAS to keep the NAS aware of user departure for the
   flow.  This message flow is illustrated in Figure 2.

   +----------+    +-------+   +-----+      ANCP           +-----+
   |Subscriber|    | Home  |   | AN  |<------------------->| NAS |
   +----------+    |Gateway|   +-----+                     +-----+
         |         +-------+      |                           |
         |            |           |                           |
         |       Join(Flow 1)     |  Admission-Control        |
         |------------+---------->|   (Target,add, Flow 1)    |
         |            |           |-------------------------->|
         |            |           |                          (*)
         |            |           | Multicast-Replication-Crl |
         |            |           |   (Target,add, Flow 1)    |
         |            |           |<--------------------------|
         |     Mcast Flow 1       |                           |
         |<=======================+                           |
         |            |           |                           |
         ~            ~           ~                           ~
         |            |           |                           |
         |      Leave(Flow 1)     |  Admission-Control        |
         |------------+---------->| (Target,delete, Flow 1)   |
         |            |           |-------------------------->|
         | <Stop Replication of   X                           |
         |         Mcast Flow 1>  |                           |
         |            |           |                           |


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

       Figure 2: Multicast Conditional Access and Admission Control

3.3.  Multicast Flow Reporting Use Case

3.3.1.  Goals

   The Multicast flow reporting use case allows the NAS to
   asynchronously query the AN to obtain an instantaneous status report



Le Faucheur, et al.      Expires January 4, 2010                [Page 9]

Internet-Draft          ANCP Multicast Extensions              July 2009


   related to multicast flows currently replicated by the AN.

3.3.2.  Message Flow

   The NAS sends a Multicast Flow Query Request message to the AN in
   order to query the AN about information such as which multicast flows
   are currently active on a given AN port or which ports are currently
   replicating a given multicast flow.  The AN conveys the requested
   information to the NAS in a Multicast Flow Query Response message.
   This message flow is illustrated in Figure 3.

   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |  Multicast Flow   |
         |           |           |  Query Request    |
         |           |           |<------------------|
         |           |           |                   |
         |           |           | Multicast Flow    |
         |           |           | Query Response    |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                   |

                    Figure 3: Multicast Flow Reporting

























Le Faucheur, et al.      Expires January 4, 2010               [Page 10]

Internet-Draft          ANCP Multicast Extensions              July 2009


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

4.1.  Provisioning Message

   [I-D.ietf-ancp-protocol] defines the Provisioning message that is
   sent by the NAS to the AN to provision information in the AN.

   The present document specifies that the Provisioning message MAY be
   used by the NAS to provision multicast-related information (e.g.
   Multicast Service Profiles, Bandwidth Delegation activation/
   deactivation).

   The ANCP Provisioning message payload MAY contain the following TLVs:

   o  Multicast-Service-Profile TLV: the Multicast-Service-Profile TLV
      is defined in the present document in Section 5.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 5.2.  It MAY
      appear zero times or once.  When present it instructs the AN on
      whether Bandwidth Delegation is to be activated or deactivated.

   [Editor's Note: A generic mechanism should be defined in ancp-proto
   to deal with incorrect/invalid Provisioning message.  This should
   include an error code for the AN to indicate that it does not know a
   given TLV and does not support the corresponding capability, and an
   error code for the AN to indicate that a given TLV and its
   corresponding capabilities have been "negotiated out" during the
   Capability negotiation phase.  The present document can indicate that
   (i) the 1st error code can be used when Provisioning message contain
   a multicast related TLV but the AN does not support it and (ii) the
   2nd error code can be used when Bandwidth-delegation-Control TLV
   indicates "active" but Bandwidth Delegation is not part of the
   negotiated multicast capabilities].

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



Le Faucheur, et al.      Expires January 4, 2010               [Page 11]

Internet-Draft          ANCP Multicast Extensions              July 2009


   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 (specified in
   Section 5.6) in the Port Management message.

   In addition, when bandwidth delegation is activated for this AN, the
   Port Management message MAY be used to provision the initial amount
   of bandwidth delegated to the AN for multicast admission control
   (hereafter referred to as the "delegated bandwidth").  To do so, the
   NAS MAY include in the Port Management message a "Bandwidth-
   Allocation" TLV (defined in Section 5.3) .

   [Editor's Note: the Port Management message requires the
   specification of an Access-Loop-Circuit-Id TLV indicating the target
   of the assignment.  Thinking about the possibility of PON, will we be
   updating the definition of Access-Loop-Circuit-Id TLV to include
   default naming formats for PON?  Of the authors, TT prefers this
   route, leaving Target to designate multiple targets for the same
   command.]

4.3.  Multicast Replication Control Message

   This section defines a new message called the Multicast Replication
   Control message.  The Multicast Replication Control message is sent
   by the NAS to the AN with one or more directives to add (join) or
   delete (leave) a multicast flow on a target object identified in the
   content of the message.  When a response is needed an AN MUST use the
   Multicast Status message (defined in Section 4.4) to convey the
   outcome of the directive.

   The Message Type for the Multicast Replication Control message is
   0x90.  The sender of a Multicast Replication Control message MUST set
   the Result field to "0x00" meaning "Ignore".  The sender MUST
   populate the ANCP Transaction Identifier field with a unique value,
   as described in section 5.4.5 of [I-D.ietf-ancp-protocol].

   The NAS MAY issue a Multicast Replication Control message to the AN
   to convey one or more directives to add (join) or delete (leave) a
   multicast flow.  The NAS sends this message on its own initiative to
   support the NAS initiated Multicast Control use case presented in
   [I-D.ietf-ancp-framework] and summarized in Section 3.1.  The NAS



Le Faucheur, et al.      Expires January 4, 2010               [Page 12]

Internet-Draft          ANCP Multicast Extensions              July 2009


   sends this message in response to a Multicast Admission Control
   message (defined in Section 4.5) received from the AN to support the
   conditional access and admission control use case presented in
   [I-D.ietf-ancp-framework] and summarized in Section 3.2.

   The ANCP Multicast Replication Control message payload contains the
   following TLVs:

   o  Target TLV: The Target TLV is defined in [I-D.ietf-ancp-protocol].
      It MUST appear once and only once.  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.  It MAY appear
      multiple times.  Each Command TLV contains a multicast flow
      directive for the target.

   The contents of the Command TLV for the Multicast Replication Control
   Message are defined in Figure 4 and subsequent text.

       0                   1                   2                   3
       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Command Code  |R O M   Flags  |         Command Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Source Address |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Source Address (Cont'd)  ...                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Group Address  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Group Address (Cont'd)  ...                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ...                          | Padding to 32-bit boundary    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 4: Command TLV in Multicast Replication Control Message

   Command Code:
             Command directive: 0x01 - Add; 0x02 - Delete; 0x03 - Delete
             All.

   Command Length:
             Length in bytes of the Command including multicast flow
             address, but excluding the Command Code header and flags.





Le Faucheur, et al.      Expires January 4, 2010               [Page 13]

Internet-Draft          ANCP Multicast Extensions              July 2009


   Flags:
             8 bit General purpose Flag field.  Currently the following
             flags are defined:

             R -       Resource Admitted Flag.  Set to 1 in an add
                       command to indicate that the flow resources have
                       been reserved by admission control, 0 otherwise.
                       Not used in delete command.

             O -       Flow Accounting.  When set in add command
                       indicates that byte accounting for the flow is to
                       commence.

             M -       When set, indicates that the multicast flow is
                       SSM; the Command MUST then specify both the
                       source and the group address.  When not set,
                       indicates that the multicast flow is ASM; the
                       Command MUST then specify the group address only,
                       omitting the Source Address field.

   Address Family:
             The address family of the address with values as defined in
             [IANAAEA].

   Encoding Type:
             The type of encoding used within a specific Address Family.
             The value `0' is reserved for this field, and represents
             the native encoding of the Address Family.  This is
             consistent with the address encoding specified in
             [RFC4601].

   Address:
             The address as represented by the given Address Family and
             Encoding Type.  This is consistent with the address
             encoding specified in [RFC4601].

   If needed, padding is done after both addresses so that the TLV is
   32-bit aligned.

   If the AN receives a Multicast Replication Control Message containing
   an unrecognized Target TLV, the AN MUST return a Multicast Status
   Message (Section 4.4) indicating the "Unrecognised port Type - 0x04"
   error.

   Each Multicast Replication Control Message MAY contain one or more
   commands, each encapsulated in its own Command TLV.  The sender MUST
   use a separate Command TLV for each distinct multicast flow.




Le Faucheur, et al.      Expires January 4, 2010               [Page 14]

Internet-Draft          ANCP Multicast Extensions              July 2009


   When successive commands (in the same or different messages) relate
   to the same Target and multicats flow, the state of each feature
   controlled or affected by flags or by optional attributes received in
   the Multicast Replication Control message, SHALL be as set by the
   last command or message referring to that target and flow and
   containing the controlling flag or optional attribute.  As an
   example, successive Multicast Replication Control messages containing
   add commands for a given port and flow, but differing only in the
   accounting flag setting SHALL be interpreted to mean that the state
   of the accounting feature is as set in the final command received,
   but all other feastures are as set in the initial message.

   If more than one Command TLV is present in a Multicast Replication
   Control message, the AN MUST act on the commands in the order in
   which they are presented in the message.  The AN SHALL assign a
   sequence number to each command in a given Multicast Replication
   Control message, starting from 0x01 for the first command.  The AN
   MUST use the assigned sequence number in any response message when
   necessary to distinguish the Command TLV instance to which a given
   status code applies.

   The processing/execution of multiple commands contained in a single
   Multicast Control message MUST be interrupted at the first error
   encountered, and the remaining commands in the Multicast Replication
   Control message discarded.  In such a case a Multicast Status message
   MUST be sent indicating the command number that resulted in the error
   along with the error code.

   When the order of processing of two commands does not matter, the
   commands MUST be transmitted in separate Multicast Replication
   Control messages.

   Each command directive is equipped with an 8-bit Flags field that
   allows specification of Multicast ASM or SSM modes of operation, and
   an indication of other features or conditions attached to this
   command (e.g.  To enable accounting for the flow, etc).  Unassigned
   flags are reserved for future use, and could in the future be subject
   of the capability negotiation.  When receiving a Multicast
   Replication Control Message containing an unrecognized Flag set (to
   1), a recipient MUST interpret it as an error, and generate an
   Multicast Status message indicating the error.

   The multicast flow subject to the command is specified by means of
   one or two well known Address Family designators ([IANAAEA]), the
   IPv4-Address-Family (0x01) and the IPv6-Address-Family (0x02).  When
   the M flag is set the two Address-Family tuples MUST be present in
   the strict order specifying the multicast flow source and group
   respectively.  When the M flag is cleared only one Address-Family is



Le Faucheur, et al.      Expires January 4, 2010               [Page 15]

Internet-Draft          ANCP Multicast Extensions              July 2009


   allowed, specifying the multicast flow.

   For future extensibility, each Command TLV MAY also have additional
   [sub- or same level ????]  TLVs appended following the command and
   multicast flow information (referred to as "TLVs" in the message
   format above).  Unrecognized TLVs SHOULD be silently discarded.  The
   figure below is an example of a Multicast Replication Control message
   that would result in a swap from multicast SSM flows 192.0.2.1,
   233.252.0.2, to 192.0.2.2, 233.252.0.3 on the Target identified by
   the "Access Loop Circuit ID":









































Le Faucheur, et al.      Expires January 4, 2010               [Page 16]

Internet-Draft          ANCP Multicast Extensions              July 2009


       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 | 0x02  |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = Target 0x1000   |        Target TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ~                    Access Loop Circuit ID                     ~
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = Command TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x02 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.1  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Mcast Flow : 233.252.0.2                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |        Type = Command-TLV     |       Command-TLV Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Cmd Code=0x01 |0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |Mcast Source (Ctnd) 192.0.2.2  | AddrFamily 01 | EncType 0x0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Mcast Flow: 233.252.0.3                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



4.4.  Multicast Status Message

   This section defines a new message called the Multicast Status
   message.  The general purpose of the Multicast Status message is to
   provide information on the success or failure to process a message
   previously received from the sender's peer.  Depending on the
   particular use case, the Multicast Status message MAY be sent by



Le Faucheur, et al.      Expires January 4, 2010               [Page 17]

Internet-Draft          ANCP Multicast Extensions              July 2009


   either the NAS or the AN.  In some cases the Multicast Status message
   is REQUIRED, even when processing of the original message is
   successful.  In other cases the Multicast Status message is used only
   to report failures.  For further details see the descriptions of
   other multicast-related messages presented in this section.

   The Message Type for the Multicast Status message is 0x91.

   A Multicast Status message MUST use the same ANCP Transaction ID as
   that in the message that it is responding to.  The Success or Failure
   status is reported in the Result field of the ANCP header as
   described in section 5 of [I-D.ietf-ancp-protocol].

   A Multicast Status Message indicating Success SHOULD simply consist
   only of the base ANCP header with no body, however the message MAY
   contain one or more TLVs that are meant to communicate any relevant
   information to an application.  The payload of a Multicast Status
   Message indicating Failure MUST contain a Status-Info TLV (0x12) (as
   defined in [I-D.ietf-ancp-protocol]) as its first TLV.  This SHOULD
   be followed by the Target TLV (as defined in
   [I-D.ietf-ancp-protocol]) and Port-info [???].  Other TLVs MAY be
   present.  A Multicast Status message indicating Failure MUST be sent
   whenever a multicast control message cannot be fulfilled or results
   in an execution error.  The Cmnd Nmbr parameter in the Status-Info
   TLV contained by the Multicast Status Message is used to indicate the
   sequence number of the command in the Multicast Replication Control
   Message that resulted in an error.  In the case where the problem is
   with the Multicast Replication Control Message as a whole, or in the
   case where the problem is with a message that is not a Multicast
   Replication Control message, the Cmnd Nmbr parameter SHOULD be set to
   0x00.

   The following values are defined for the Result Code field in the
   Status-Info TLV contained in a Multicast Status Message:

        0x00 - Success

        0x01 - Malformed message

        0x02 - Command not supported

        0x03 - Flag set but not supported

        0x04 - Unrecognized Target







Le Faucheur, et al.      Expires January 4, 2010               [Page 18]

Internet-Draft          ANCP Multicast Extensions              July 2009


        0x05 - Unsupported Address Family

        0x06 - Malformed flow address

        0x07 - No resources

        0x08 - Unknown Target

        0x09 - Target down

        0x0a - Configuration error (such as Port not enabled for
        multicast)

        0x0b - Multicast flow does not exist

        0x0c - Unsupported address encoding

        0x0d - Additional info needed to execute command (payload MAY
        contain an indication of the expected info)

        0x0e - Multicast flow count exceeded

        0x0f - M Flag set, but no IP Source address provided

        0x10 - Transaction-id out of sequence

        0x11 - Invalid preferred bandwidth amount

        0x12 - Bandwidth delegation not activated

        0x13 - Delegated bandwidth reset required

   An example of a failure message for an invalid address, including the
   Target TLV for a 4 byte "Access Loop Circuit ID", followed by TLV
   padding, is as follows:
















Le Faucheur, et al.      Expires January 4, 2010               [Page 19]

Internet-Draft          ANCP Multicast Extensions              July 2009


       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 | 0x4   |        Code           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Partition ID  |            Transaction Identifier = 0001      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |I|      SubMessage Number      |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Status-info-TLV=0x12  |      Status-TLV-Length        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Result Code  |  Cmd Number   |    Error Message Length       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Error Message (padded to 4) if Length > 0           |
       +---------------------------------------------------------------+
       |     Target TLV=0x10           |        Target-Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Access Loop ID type       |     Access-Loop ID  Length    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            circuit ID                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.5.  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 of 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 (as discussed in
   Section 4.3) in order to convey back to the AN the outcome of the
   admission request.

   The Message Type for the Multicast Admission Control message is 0x92.

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

   The AN MUST populate the ANCP Transaction Identifier field with a
   unique value, as described in section 5.4.5
   of[I-D.ietf-ancp-protocol] .

   The ANCP Multicast Admission Control message payload contains two
   TLVs:

   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



Le Faucheur, et al.      Expires January 4, 2010               [Page 20]

Internet-Draft          ANCP Multicast Extensions              July 2009


      [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 Section 4.3
      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 5.7) MAY be
         included by the AN to convey the IP address of the sender of
         the join/leave message (e.g.  IGMP/MLD 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 5.8) MAY be
         included by the AN to convey the MAC address of the sender of
         the join/leave message (e.g.  IGMP/MLD 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
   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



Le Faucheur, et al.      Expires January 4, 2010               [Page 21]

Internet-Draft          ANCP Multicast Extensions              July 2009


   distributed across separate messages.

   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

   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 MAY generate a Multicast Replication Control
      message in response to the Multicast Admission Control message.
      This optional message can be used by the AN to maintain statistics
      about admission control reject and, in the future, when the
      protocol between the subscriber and the AN allows explicit
      notification of join reject (e.g.
      [I-D.morin-mboned-igmpmld-error-feedback]).  When used in this
      situation, 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 rejected by the NAS (i.e.  Target
         TLV and Command TLV) but with a Command Code set to "0x04 -
         Admission Control Reject", "0x05 - Conditional Access Reject"
         or "0x06 - Admission Control and Conditional Access Reject".




Le Faucheur, et al.      Expires January 4, 2010               [Page 22]

Internet-Draft          ANCP Multicast Extensions              July 2009


   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 (defined in Section 4.4) in response to the
      Multicast Admission Control message.  The Multicast 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 Section 4.4.

4.6.  Bandwidth Reallocation Request Message

   The Bandwidth Reallocation Request message is used when the Bandwidth
   Delegation capability has been activated.  It MAY be sent either by
   the NAS or by the AN to request an adjustment in the amount of
   delegated bandwidth.  It will be sent by the NAS typically to reduce
   the multicast bandwidth allocated to the AN in order for the NAS to
   satisfy a request to add a unicast video channel.  Conversely, the AN
   will send a Bandwidth Reallocation Request to obtain additional
   bandwidth to satisfy a request to add a multicast channel.  In each
   case, the requestor has a minimum requirement for additional
   bandwidth, and MAY ask for additional bandwidth beyond this amount
   (say to handle anticipated future requests).

   The Message Type for the Bandwidth Reallocation Request message is
   0x94.  The Result field in the header of the Bandwidth Reallocation
   Request message is not used and MUST be set to Ignore (0x00).  The
   Bandwidth Reallocation Request message MUST contain two TLVs:

   o  the Target TLV (section 5.4.5.1.1 of [I-D.ietf-ancp-protocol]),
      specifying a single access line; [TT - I would prefer the Access-
      Loop-Circuit-Id TLV, believing it should evolve to include non-DSL
      identifiers, but the majority overruled me];

   o  the Bandwidth-Request TLV (Section 5.4), specifying the required
      and preferred amounts of delegated bandwidth.

   The bandwidth values in the Bandwidth-Request TLV are expressed in
   terms of total bandwidth delegated to the AN.





Le Faucheur, et al.      Expires January 4, 2010               [Page 23]

Internet-Draft          ANCP Multicast Extensions              July 2009


      The choice of "total bandwidth" rather than "incremental
      bandwidth" was made so that it would be easier for the AN and NAS
      to keep their respective views of the current amount of delegated
      bandwidth synchronized.

   Because the values are totals rather than desired increments/
   decrements, the relationship between the required amount and the
   preferred amount will differ depending on whether the Bandwidth
   Reallocation Request message is issued by the NAS or the AN.

   o  If the NAS is making the request, the preferred amount MUST be
      less than or equal to the required amount.  The required amount
      MUST be less than the current delegated bandwidth value.

   o  If the AN is making the request, the preferred amount MUST be
      greater than or equal to the required amount.  The required amount
      MUST be greater than the current delegated bandwidth value.

   If these conditions are violated and the problem is the relationship
   between the required amount and the receiver's view of the current
   delegated bandwidth, the delegated bandwidth reset procedure
   described in Section 4.10 MUST be performed.  If the problem is the
   relationship between the preferred and required amounts, the peer
   receiving the Bandwidth Reallocation Request message MUST return a
   Multicast Status message where the Result field in the header
   indicates Failure (0x4) and the Status-Info TLV contains the
   following values:

      Result Code = invalid preferred bandwidth amount (0x11);

      Command Number = 0x1;

      Error Message Length = 0x0 (or optionally the length of an error
      message, padded to a four-octet boundary);

      Error Message (optional text);

      the Target TLV, copied from the Bandwidth Reallocation Request
      message;

      the Bandwidth-Request TLV, also copied from the request message.

   When the peer receives a valid Bandwidth Reallocation Request
   message, it SHOULD determine whether it can satisfy the request from
   its existing allocation of unused video bandwidth.  If it decides
   that it can reallocate bandwidth to the peer, it MAY choose to return
   any amount between the required and the preferred amounts indicated
   in the Bandwidth Reallocation Request message.  The peer MUST return



Le Faucheur, et al.      Expires January 4, 2010               [Page 24]

Internet-Draft          ANCP Multicast Extensions              July 2009


   a Bandwidth Transfer message Section 4.7 indicating its decision.  If
   the request is met, the Result field of the Bandwidth Transfer
   message MUST be set to Success (0x3), and the Bandwidth-Allocation
   TLV (Section 5.3) MUST contain the new value of delegated bandwidth.
   This new value MUST lie between the required and preferred values,
   inclusive, from the request message.  If the request is not met, the
   Result field of the Bandwidth Transfer message MUST be set to Failure
   (0x4) and the Bandwidth Allocation TLV MUST contain the value of the
   current amount of delegated bandwidth as the responder views it.

   To avoid deadlock due to race conditions, the following rules MUST be
   applied:

   a.  If the NAS receives a Bandwidth Reallocation Request message
       while it has a Bandwidth Reallocation Request message of its own
       outstanding for the same access line, the NAS MUST provide an
       immediate failure response to the request from the AN.

   b.  If the AN receives a Bandwidth Reallocation Request message while
       it has a Bandwidth Reallocation Request message of its own
       outstanding for the same access line, the AN MUST release any
       bandwidth it has already committed to an outstanding Join request
       while it is awaiting a response from the NAS.  It MUST decide
       upon and send its response to the NAS taking the released
       bandwidth into account.

   [Editor's Note: This is an arbitrary rule which gives priority to
   unicast over multicast.  Is that the right direction?]

4.7.  Bandwidth Transfer Message

   The Bandwidth Transfer message is used to transfer video bandwidth
   from the sender to the peer for a specific access line.  This message
   MAY be sent either from the AN or from the NAS.  As described in the
   previous section, it is the required response to a valid Bandwidth
   Reallocation Request message.

   The Bandwidth Transfer message MAY also be used to transfer bandwidth
   autonomously from one peer to another.  One example of this usage is
   to release bandwidth borrowed earlier by means of the Bandwidth
   Reallocation Request message.  When the message is used in this way,
   the Result field in the Bandwidth Transfer message MUST be set to
   Ignore (0x0).

      This allows the receiver to distinguish between an autonomous
      transfer and a response to a previous Bandwidth Reallocation
      Request, for purposes of validation.




Le Faucheur, et al.      Expires January 4, 2010               [Page 25]

Internet-Draft          ANCP Multicast Extensions              July 2009


   The Message Type for the Bandwidth Transfer message is 0x95.  The
   Bandwidth Transfer message MUST contain the following TLVs:

   o  the Target TLV, designating the access line concerned;

   o  an instance of the Bandwidth-Allocation TLV (Section 5.3).

   The bandwidth value in the Bandwidth-Allocation TLV is the new amount
   of delegated bandwidth.  The following relationships MUST hold:

   o  if the message is sent by the NAS, the bandwidth value in the
      Bandwidth-Allocation TLV MUST be greater than or equal to the
      current amount of delegated bandwidth for the access line
      concerned;

   o  if the message is sent by the AN, the bandwidth value in the
      Bandwidth-Allocation TLV MUST be less than or equal to the current
      amount of delegated bandwidth for the access line concerned.

   In either case, equality to the current delegated bandwidth is
   permitted only for a failure response to a previous Bandwidth
   Reallocation Request.

   If the Bandwidth Transfer message satifies these conditions, the
   receiver MUST update its view of the amount of delegated bandwidth to
   the value given in the Bandwidth-Allocation TLV.  If, on the other
   hand, the bandwidth value in the Bandwidth-Value TLV is invalid, the
   receiver MAY either accept the new value or MAY choose to initiate
   the delegated bandwidth reset procedure described in Section 4.10.

4.8.  Delegated Bandwidth Query Request and Response Messages

   The Message Type for the Delegated Bandwidth Query Request and
   Response messages is 0x96.

   The Delegated Bandwidth Query Request message MAY be sent by the NAS
   to retrieve the AN's view of the total amount of delegated bandwidth
   and the amount that is already committed.  The request contains one
   TLV:

   o  a Target TLV designating the access line(s) for which the
      information is requested.

   Consistently with other multicast-related messages, the Result field
   in the header of the Delegated Bandwidth Query Request message MUST
   be set to Ignore (0x0).

   If the AN receives an invalid Delegated Bandwidth Query Request



Le Faucheur, et al.      Expires January 4, 2010               [Page 26]

Internet-Draft          ANCP Multicast Extensions              July 2009


   message, it MUST return a Multicast Status message with the Result
   field in the header set to Failure (0x4).  The following cases may
   occur:

   o  if the Target is invalid, the Status-Info TLV contains the
      following values:

         Result Code = unrecognized target (0x04);

         Command Number = the order of the invalid Target TLV within the
         request, numbering from 1 for the first one listed;

         Error Message Length = 0x0 (or optionally the length of an
         error message, padded to a four-octet boundary);

         Error Message (optional text);

         the invalid Target TLV, copied from the Delegated Bandwidth
         Query Request message.

   o  if bandwidth delegation is not activated on the AN, the Status-
      Info TLV contains the following values:

         Result Code = bandwidth delegation not activated (0x12);

         Command Number = 0x1;

         Error Message Length = 0x0 (or optionally the length of an
         error message, padded to a four-octet boundary);

         Error Message (optional text).

   The AN MUST respond to a valid request with a Delegated Bandwidth
   Query Response.  The Result field in the header of this message MUST
   be set to Success (0x3).  This message contains the following TLVs:

   o  the Target TLV, copied from the request;

   o  one instance of the Bandwidth-Status TLV (Section 5.5) for each
      access line designated in the Target TLV.  The instances MUST have
      the same order in the response as the corresponding access lines
      in the Target TLV.

   [Editor's Note: the base protocol draft is incomplete regarding the
   specification of multiple access lines in the Target TLV.]






Le Faucheur, et al.      Expires January 4, 2010               [Page 27]

Internet-Draft          ANCP Multicast Extensions              July 2009


4.9.  Multicast Flow Query Request and Response Messages

   This section defines two new messages called the Multicast Flow Query
   Request and Multicast Flow Query Response.  The Multicast Flow Query
   Request is sent by the NAS to request information about the multicast
   flows that are active on the AN.  The Multicast Flow Query Response
   is sent in response by the AN to provide the requested information to
   the NAS.

   The Message Type for the Multicast Flow Query Request and Multicast
   Flow Query Response messages is 0x97.  The sender of a Multicast Flow
   Query Request and Multicast Flow Query Response message MUST set the
   Result field to "0x00" meaning "Ignore".

   The Multicast Flow Query Request message MAY be sent by the NAS to
   retrieve the AN's view of which multicast flows are currently active
   on one (or multiple) given port(s) of the AN.  In that case, the
   Multicast Flow Query Request payload MUST contain the following TLVs:

   o  Target TLV.  It MUST appear at least once.  Each occurence
      identifies one AN port for which information on active multicast
      flows is queried.  It is encoded as specified in
      [I-D.ietf-ancp-protocol].

   The Multicast Flow Query Request message MAY be sent by the NAS to
   retrieve the AN's view of which ports one (or multiple) given
   multicast flow(s) is (are) currently active on.  In that case, the
   Multicast Flow Query Request payload MUST contain the following TLVs:

   o  Multicast-Flow TLV.  It MUST appear at least once.  Each occurence
      identifies one multicast flow for which information is queried.
      It is encoded as specified in Section 5.9.

   The Multicast Flow Query Request message MAY be sent by the NAS to
   retrieve the AN's view of all the multicast flows currently active on
   each and every port of the AN.  In that case, the Multicast Flow
   Query Request payload MUST NOT contain the Target TLV nor the
   Multicast-Flow TLV.

   If the AN receives an invalid Multicast Flow Query Request message,
   it MUST return a Multicast Status message with the Result field in
   the header set to Failure (0x4).  The following cases may occur:

   o  if the Target is invalid, the Status-Info TLV contains the
      following values:

         Result Code = unrecognized target (0x04);




Le Faucheur, et al.      Expires January 4, 2010               [Page 28]

Internet-Draft          ANCP Multicast Extensions              July 2009


         Command Number = the order of the invalid Target TLV within the
         request, numbering from 1 for the first one listed;

         Error Message Length = 0x0 (or optionally the length of an
         error message, padded to a four-octet boundary);

         Error Message (optional text);

         the invalid Target TLV, copied from the Multicast Flow Query
         Request message.

   o  [Editor's note: if needed, add other error codes ???- eg if query
      contained both Target TLV and Multicast Flow TLV]

   The AN MUST respond to a valid Multicast Flow Query Request message
   with a Multicast Flow Query Response message.

   If the Multicast Flow Query Request contained one (or more) Target
   TLV, the AN MUST include, for each of these Target TLVs, the
   following set of TLVs:

   o  Target TLV.  This MUST be identical to the Target TLV in the
      received Multicast Flow Query Request message.

   o  Multicast Flow TLV(s).  The Multicast Flow TLV MUST appear once
      per Multicast Flow that is currently active on the AN port
      identified in the preceding Target TLV.

   The Target TLVs MUST appear in the response from the AN in the same
   order as in the query from the NAS.

   If the Multicast Flow Query Request contained one (or more) Multicast
   Flow TLV, the AN MUST include, for each of these Multicast Flow TLVs,
   the following set of TLVs:

   o  Multicast Flow TLV.This MUST be identical to the Target TLV in the
      received Multicast Flow Query Request message.

   o  Target TLV(s).  The Target TLV MUST appear once per AN port on
      which the multicast flow identified in the preceding Multicast
      Flow TLV is active.

   The Multicast Flow TLVs MUST appear in the response from the AN in
   the same order as in the query from the NAS.

   If the Multicast Flow Query Request contained no Target TLV and no
   Multicast Flow TLV, the AN MUST include, for each and every AN port,
   the following set of TLVs:



Le Faucheur, et al.      Expires January 4, 2010               [Page 29]

Internet-Draft          ANCP Multicast Extensions              July 2009


   o  Target TLV.  This MUST identify one AN port.

   o  Multicast Flow TLV(s).  The Multicast Flow TLV MUST appear once
      per Multicast Flow that is currently active on the AN port
      identified in the preceding Target TLV.

4.10.  Delegated Bandwidth Reset Procedure

   As described above, the receiver of a Bandwidth Reallocation Request
   or Bandwidth Transfer message may determine that a bandwidth value in
   that message bears an incorrect relationship to its view of the
   current amount of delegated bandwidth.  The probable cause of this
   condition is a discrepancy between its view and its peer's view of
   this amount.  Upon detecting this condition, the receiver MAY choose
   to initiate the reset procedure described in this section.  If so, it
   MUST send a Multicast Status message to its peer with the Result
   field in the header set to Failure (0x4) and a Status-Info TLV
   containing the following values:

      Result Code = delegated bandwidth reset required (0x13);

      Command Number = 0x1;

      Error Message Length = 0x0 (or optionally the length of an error
      message, padded to a four-octet boundary);

      Error Message (optional text);

      the Target TLV, copied from the received message

      an instance of the Bandwidth-Allocation TLV containing the
      receiver's view of the current amount of delegated bandwidth.

   Upon sending or receiving a Multicast Status message containing this
   Result Code, the NAS MUST take the following actions:

   1.  halt processing of admission requests for the access line
       indicated by the Target TLV until the reset procedure is
       complete;

   2.  issue a Delegated Bandwidth Query request message to the AN to
       determine the amount of bandwidth it has currently committed to
       multicast usage, and its view of the amount of delegated
       bandwidth;

   3.  based on the reply and possibly in consultation with the Policy
       Server, apply policy to determine what the amount of delegated
       bandwidth should be;



Le Faucheur, et al.      Expires January 4, 2010               [Page 30]

Internet-Draft          ANCP Multicast Extensions              July 2009


   4.  issue a Port Management message where the Access-Loop-Circuit-Id
       TLV is derived from the Target TLV in the Multicast Status
       message.  The Port Management message MUST contain a Bandwidth-
       Allocation TLV giving the decided amount of delegated bandwidth.

   5.  update its own view of the current amount of delegated bandwidth
       to the decided amount.

   At this point the reset procedure is complete and the NAS can resume
   processing of admission requests for the affected access line.

   Upon sending or receiving a Multicast Status message containing this
   Result Code, the AN MUST take the following actions:

   1.  halt processing of admission requests for the access line
       indicated by the Target TLV until the reset procedure is
       complete;

   2.  wait for and respond to a Delegated Bandwidth Query request
       message, indicating the amount of bandwidth it has currently
       committed to multicast usage and its view of the amount of
       delegated bandwidth;

   3.  wait for a Port Management message giving the decided amount of
       delegated bandwidth for the access line concerned;

   4.  update its view of the current amount of delegated bandwidth to
       the amount received in the Port Management message.

   At this point the reset procedure is complete and the AN can resume
   processing of admission requests for the affected access line.




















Le Faucheur, et al.      Expires January 4, 2010               [Page 31]

Internet-Draft          ANCP Multicast Extensions              July 2009


5.  ANCP TLVs and Sub-TLVs

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

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

   The Multicast-Service-Profile is illustrated in Figure 5:

                            1                   2                   3
        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 type = 0x0001                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   White-List Sub-TLV                                          |
       |   Sub-TLV type = 0x0002                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Grey-List Sub-TLV                                           |
       |   Sub-TLV type = 0x0003                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Black-List Sub-TLV                                          |
       |   Sub-TLV type = 0x0004                                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 5: Multicast-Servive-Profile TLV

   Multicast Service Profile TLV Type:

             TLV (0x13) : indicating that this is a Multicast Service
             Profile TLV

   Each of the four sub-TLVs begins with a 32-bit header consisting of a
   16-bit sub-TLV type code followed by a 16-bit length field giving the
   amount of data following this sub-TLV header in octets.  The type
   code 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



Le Faucheur, et al.      Expires January 4, 2010               [Page 32]

Internet-Draft          ANCP Multicast Extensions              July 2009


   same AN partition.  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.

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

   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 organized by address family.  IPv4 addresses
   are listed first, followed by IPv6 addresses.  Either set of
   addresses MAY be omitted if not applicable, but at least one set of
   addresses MUST be present.  Figure 6 shows the detailed layout of a
   white, grey, or black list, where the detailed layout of an
   individual multicast flow field is described below.  The list length
   in Figure 6 is the number of octets of multicast flow field data for
   that address family following the list header.

                            1                   2                   3
        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 tag = 0x0002,3,4      |       Sub-TLV Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Ver=0x0000  (IPv4)         |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP Ver=0x0001  (IPv6)         |          List Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Multicast flow fields                      |
                                 ......
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 6: Organization of a White, Grey, or Black List

   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 prefix length values smaller than the total address
   length for the given address family.  Multicast flow fields MUST be
   placed consecutively within the sub-TLV without intervening padding
   except to round out individual addresses to the nearest octet
   boundary.




Le Faucheur, et al.      Expires January 4, 2010               [Page 33]

Internet-Draft          ANCP Multicast Extensions              July 2009


   A multicast flow field consists of two single-octet prefix lengths
   followed by zero to two prefix values as shown in Figure 7:


       +-+-+-+-+-+-+-+-+
       | Group PrefLen |
       +-+-+-+-+-+-+-+-+
       | Source PrefLen|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Group Prefix (multicast)  (0 to 16 octets)                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Source Prefix (unicast, SSM only) (0 to 16 octets)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Figure 7: Organization of a Single Multicast Flow Field

   The prefix length has its usual meaning.  It is the number of most-
   significant bits specified within the corresponding prefix.  The
   prefix length MAY vary from 0 to 32 in the IPv4 sub-list, and from 0
   to 128 in the IPv6 sub-list.  A match to the multicast flow
   specification is performed based on the prefix values only, ignoring
   lower-order bits in the respective addresses.

   A value of 0x00 for either the Group PrefLen (prefix length) or the
   Source PrefLen indicates that any value of the corresponding address
   will match (wild card).  If the value 0x00 is provided for a
   particular prefix length, the corresponding prefix MUST be omitted
   from the field contents.  In particular, a value of 0x00 for the
   Source PrefLen indicates an ASM multicast entry, and the Source
   Prefix will be absent.

   The length of a Source or Group Prefix field is equal to (PrefLen +
   7)/8 octets, truncated to the nearest integer.  Unused bits at the
   end of the prefix MUST be set to zeroes.

5.1.1.  Profile Processing At the Access Node

   When the AN receives an IGMP/MLD Join request, it first checks
   whether the program limit for that subscriber has been exceeded.  If
   so, it discards the request.  Otherwise its next step is to determine
   whether the source and group of the request match a multicast flow
   specification in the white list, the grey list, or the black list
   according to the profile assigned to the access line.

   If the requested multicast flow matches multiple lists associated
   with the access line, then the most specific match will be considered
   by the AN.  If the most specific match occurs in multiple lists, the



Le Faucheur, et al.      Expires January 4, 2010               [Page 34]

Internet-Draft          ANCP Multicast Extensions              July 2009


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

   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.

   If the requested multicast flow matches a flow in the black list, the
   AN discards the Join request.

   Otherwise, if bandwidth delegation is active for the access line, the
   AN determines whether it has enough unused capacity out of the total
   video bandwidth that has been delegated to it for multicast admission
   control.  If so, it does white or grey list processing as described
   below.  If there is not enough unused bandwidth, it MAY issue a
   Bandwidth Reallocation Request message.  The required bandwidth
   amount in the Bandwidth-Request TLV MUST be large enough that if the
   request is granted, there will be sufficient unused capacity to
   accommodate the Join request.  The AN MAY set the preferred amount in
   the Bandwidth-Request TLV to the same value as the required amount,
   or to some higher amount determined by configured policy.  If the
   request fails or if the AN does not choose to issue a Bandwidth
   Reallocation Request (e.g., because another such request failed
   recently), it does no further processing of the Join request.

   If the bandwidth check succeeds or if bandwidth delegation is not
   active, then:

   o  if the requested multicast flow matches a flow in the white list,
      the AN MUST autonomously start replicating multicast traffic
      according to the request;

   o  if the requested flow matches a flow in the grey list, the AN MUST
      send a Multicast Admission Control message (Section 4.5) to the
      NAS with the value of Command set to Add (0x01) and await the
      Multicast Replication Control message (Section 4.3) which responds
      to it.  Note that, when bandwidth delegation is active, the AN
      MUST NOT send the Multicast Admission Control message until it has



Le Faucheur, et al.      Expires January 4, 2010               [Page 35]

Internet-Draft          ANCP Multicast Extensions              July 2009


      fully established that the bandwidth checks succeeds (either
      because the AN has enough unused capacity in the delegated
      bandwidth or because the AN requested and obtained the necessary
      increased delegated bandwidth in a Bandwidth REallocation Response
      from the NAS).  When the Multicast ReplicationControl message
      arrives, the AN MUST act according to its content.  The AN MAY set
      a timer after which it will take no further action on the Join
      request and will ignore the Multicast Replication Control
      response, if any.

   [Editor's Note: for grey list requests, there is a currently
   unfulfilled need to indicate to the NAS (or require the NAS to know)
   whether admission control has been done at the AN.  If so, the NAS
   can skip the admission control step and just apply policy.]

   When the AN receives a Leave request for an admitted flow, it halts
   replication of the indicated channel to the access line concerned.
   In the case of a grey list flow, it also notifies the NAS using the
   Multicast Admission Control message with the Command TLV set to
   Delete (0x03).

5.2.  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 4.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 = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |E|                Reserved                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                   The Bandwidth-Delegation-Control TLV

   Bandwidth-Delegation-Control TLV Type:

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

   Bandwidth-Delegation-Control TLV Length:





Le Faucheur, et al.      Expires January 4, 2010               [Page 36]

Internet-Draft          ANCP Multicast Extensions              July 2009


             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
             to admission control according to the Bandwidth Delegation
             procedures defined in [I-D.ietf-ancp-framework].

   If Bandwidth Delegation is enabled, the NAS SHOULD provision an
   initial value for the amount of bandwidth delegated to the AN for
   multicast admission control for each line, in a Port Management (Line
   Configuration) message.  An initial delegated amount MAY be
   configured directly on the AN.  A delegated bandwidth value received
   in a Port Management message overrides any configured value.  If no
   value is configured and no value is provisioned by the NAS, the
   default initial amount of delegated bandwidth is zero.

      This implies that in the absence of provisioning or configuration,
      the AN will issue a Bandwidth Reallocation Request message to the
      NAS asking for multicast bandwidth, the first time it receives an
      IGMP/MLD Join for the given line.

5.3.  Bandwidth-Allocation TLV

   The Bandwidth-Allocation TLV is used to indicate the total amount of
   video bandwidth delegated to the AN for multicast admission control
   for a given line, in kilobits per second.  The TLV has the format
   shown in Figure 8.

        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-Alloc          |          TLV Length = 4       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Delegated amount (kbits/s)                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 8: The Bandwidth-Allocation TLV

   Bandwidth-Allocationl TLV Type:

             TLV (0x15) : indicating that this is a Bandwidth-Allocation
             TLV




Le Faucheur, et al.      Expires January 4, 2010               [Page 37]

Internet-Draft          ANCP Multicast Extensions              July 2009


5.4.  Bandwidth-Request TLV

   The Bandwidth-Request TLV is used to request an adjustment of the
   total amount of video bandwidth delegated to the AN for multicast
   admission control for a given line.  The "Required amount" field
   indicates the minimum adjustment required to meet the request.  The
   "Preferred amount" field indicates the adjustment the requestor would
   prefer to have, if possible.  Section 4.6 discusses the required
   relationships between the "Required amount", "Preferred amount", and
   current values of total bandwidth delegated to the AN.

   The Bandwidth-Request TLV has the format shown in Figure 9.

        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-Req          |            TLV Length = 8       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Required amount  (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Preferred amount (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 9: The Bandwidth-Request TLV

   Bandwidth-Request TLV Type:

             TLV (0x16) : indicating that this is a Bandwidth-Request
             TLV

5.5.  Bandwidth-Status TLV

   The Bandwidth-Status TLV is used in the Delegated Bandwidth Query
   Response to report the AN's view of the current amount of delegated
   bandwidth and the amount of bandwidth within that quantity that is
   already committed to active programs.  The Bandwidth-Status TLV has
   the format shown in Figure 10.

        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-Status       |            TLV Length = 8       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Delegated amount  (kbits/s)                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Committed amount (kbits/s)                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 10: The Bandwidth-Status TLV




Le Faucheur, et al.      Expires January 4, 2010               [Page 38]

Internet-Draft          ANCP Multicast Extensions              July 2009


   Bandwidth-Status TLV Type:

             TLV (0x17) : indicating that this is a Bandwidth-Status TLV

   The committed amount SHOULD be less than or equal to the delegated
   amount.  One case where this may not be so is if the procedure
   described in Section 4.10 has been performed and the NAS returned a
   delegated amount lower than the current committed amount.  Another
   case might be if bandwidth delegation was activated after multicast
   bandwidth had been allocated by other means.  Obviously such cases
   are exceptional and transient in nature.

5.6.  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 = 0x18): 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.

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







Le Faucheur, et al.      Expires January 4, 2010               [Page 39]

Internet-Draft          ANCP Multicast Extensions              July 2009


        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:

             sub-TLV (0x92) indicating the contents to be a Request-
             Source-IP sub-TLV.

   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/MLD 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].

5.8.  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 (0x93) indicating the contents to be a Request-
             Source-MAC sub-TLV.



Le Faucheur, et al.      Expires January 4, 2010               [Page 40]

Internet-Draft          ANCP Multicast Extensions              July 2009


   Request-Source-MAC sub- TLV Length:

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

   TBD:

             Contains the IEEE MAC address of the sender of the join/
             leave message (e.g.  IGMP/MLD 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.

5.9.  Multicast-Flow TLV

   This document defines the new Multicast-Flow TLV.

   The Multicast-Flow TLV MAY be included in a Multicast Flow Query
   Request or Response message as specified in Section 4.9.

   The Multicast-Flow 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |TLV Type = Multicast-Flow      |          TLV Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Source Address |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Source Address (Ctnd)  ...                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Addr Family   | Encoding Type | Multicast Flow Group Address  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Multicast Flow Group Address (Ctnd)  ...                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ...                          | Padding to 32-bit boundary    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                          The Multicast-Flow TLV

   Multicast-Flow TLV Type:

             TLV (0x19) : indicating that this is a Multicast-Flow TLV

   Multicast-Flow TLV Length:






Le Faucheur, et al.      Expires January 4, 2010               [Page 41]

Internet-Draft          ANCP Multicast Extensions              July 2009


             Length in bytes of the Value field of the TLV.  Excludes
             the TLV Header (Type and Length).

   Addr Family, Encoding Type, Multicast Flow Source Address, Multicast
   Flow Group Address and Padding are encoded as specified for the
   corresponding field of the Command TLV in Section 4.3.













































Le Faucheur, et al.      Expires January 4, 2010               [Page 42]

Internet-Draft          ANCP Multicast Extensions              July 2009


6.  New Capabilities

   [I-D.ietf-ancp-protocol] defines a capability negotiation mechanism
   as well as a number of capabilities.

   This document defines the following generic Multicast Capability Type
   allowing negotiation of the level of subcapability within the
   Multicast capability:

   o  Capability Type : Multicast = 0x03

         Length (in bytes) : 1

         Capability Data (1 byte): The following values are defined:

         +  0x00: Reserved

         +  0x01: "Transactional Multicast"

         +  0x02: "Transactional Multicast" and "Multicast Admission
            Control without Bandwidth Delegation"

         +  0x03: "Transactional Multicast", "Multicast Admission
            Control without Bandwidth Delegation" and "Multicast
            Admission Control with Bandwidth Delegation"

         +  other values: Reserved

   Both the NAS and the AN MUST advertise the Multicast capability in
   their originated adjacency messages when they support it.  Initially,
   they indicate the full set of multicast subcapabilities that they
   respectively support by setting the Capability Value to the value
   corresponding to their respective supported set of subcapabilities.
   Then, if a received adjacency message indicates that the originating
   device supports a smaller set of multicast subcapabilities that the
   device receiving the message, the receiving device will turn off the
   multicast subcapabilities that are not supported by the other device
   and will send an updated adjacency message with an updated Capability
   Value that now matches the one of the other device.  This process
   will eventually result in both sides agreeing on the common set of
   supported multicast subcapabilities.

   For example, if the NAS supports "Transactional Multicast" and
   "Multicast Admission Control without Bandwidth Delegation" while the
   AN only supports "Transactional Multicast", the NAS and AN will
   initially advertise the Multicast capability with a respective
   Capability Data of 0x02 and 0x01.  On receipt of the adjacency
   message from the AN, the NAS will turn off its "Multicast Admission



Le Faucheur, et al.      Expires January 4, 2010               [Page 43]

Internet-Draft          ANCP Multicast Extensions              July 2009


   Control without Bandwidth Delegation" subcapability and will send a
   new adjacency message with a Multicast capability containing a
   Capability Data of 0x01.  From there on, the NAS and AN agree to make
   use of (only) the "Transactional Multicast" subcapability.

   A NAS or AN supporting the "Transactional Multicast" subcapability
   MUST support the Multicast Replication message and the Multicast
   Status message.

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

   A NAS or AN supporting the "Transactional Multicast", "Multicast
   Admission Control without Bandwidth Delegation" and "Multicast
   Admission Control with Bandwidth Delegation" capability MUST support
   the Multicast Admission Control message, the Multicast Replication
   message, the Multicast Status message, the Bandwidth Reallocation
   Request and Response messages, the Autonomous Bandwidth Transfer
   message and the Delegated Bandwidth Query Request and Response
   messages.





























Le Faucheur, et al.      Expires January 4, 2010               [Page 44]

Internet-Draft          ANCP Multicast Extensions              July 2009


7.  Example of Messages and Message Flows

   This section provides example message flows.

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

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

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


        Figure 11: 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 January 4, 2010               [Page 45]

Internet-Draft          ANCP Multicast Extensions              July 2009


   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 Black-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 = 0x06       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IP ver = 0x00                 |       List length = 0x02      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Grp PLen=0x00 | Src PLen=0x00 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                 Figure 12








Le Faucheur, et al.      Expires January 4, 2010               [Page 46]

Internet-Draft          ANCP Multicast Extensions              July 2009


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

 +----------+      +---------+               +-----+             +-----+
 |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 13: Associating Profile ID to AN Port

7.1.3.  Successful Join/Leave Operations

   The message flows in Figure 14 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 January 4, 2010               [Page 47]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +----------+    +-------+   +-----+    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 14: Successful Join/Leave Operations

   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 January 4, 2010               [Page 48]

Internet-Draft          ANCP Multicast Extensions              July 2009


      *  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 January 4, 2010               [Page 49]

Internet-Draft          ANCP Multicast Extensions              July 2009


   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)

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

   The Multicast Admission Control message M2 is illustrated below:

























Le Faucheur, et al.      Expires January 4, 2010               [Page 50]

Internet-Draft          ANCP Multicast Extensions              July 2009


       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     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+



   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:





Le Faucheur, et al.      Expires January 4, 2010               [Page 51]

Internet-Draft          ANCP Multicast Extensions              July 2009


      *  a Command Code = Delete

      *  R = 0

      *  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:






































Le Faucheur, et al.      Expires January 4, 2010               [Page 52]

Internet-Draft          ANCP Multicast Extensions              July 2009


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



7.1.4.  Admission Control Reject without NAS Response

   The message flow in Figure 15 illustrates the ANCP message flow in
   case of a join that is rejected by the NAS because of admission
   control and without explicit response from the NAS.  In that case,
   the multicast flow is never replicated simply by virtue of the NAS
   not requesting replication.









Le Faucheur, et al.      Expires January 4, 2010               [Page 53]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                  (*)
         |           |           |                   |
         |     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 15: Admission Control Reject without NAS Response

   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

      *  O = 0

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





Le Faucheur, et al.      Expires January 4, 2010               [Page 54]

Internet-Draft          ANCP Multicast Extensions              July 2009


      *  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         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+



7.1.5.  Admission Control Reject with NAS Response

   The message flow in Figure 16 illustrates the ANCP message flow in
   case of a join that is rejected by the NAS because of admission
   control and with explicit response from the NAS.  In that case, the
   multicast flow is not replicated by virtue of the NAS explicitely
   signaling to the AN that the multicast flow is not to be replicated.






Le Faucheur, et al.      Expires January 4, 2010               [Page 55]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |                   |
         |      Join(Grey-Fl)    |     Admission     |
         |-----------+---------->|      Control (M1) |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |     Multicast    (*)
         |           |           |     Replication   |
         |           |           |     Control (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 16: Admission Control Reject with NAS Response

   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

      *  O = 0

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




Le Faucheur, et al.      Expires January 4, 2010               [Page 56]

Internet-Draft          ANCP Multicast Extensions              July 2009


      *  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 = 0004      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |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.4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |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:

   o  an ANCP Header with:

      *  Message-Type = 90 - Multicast Replication Control

      *  Result= 0x00

      *  Transaction-ID = Transaction-ID maintained by NAS




Le Faucheur, et al.      Expires January 4, 2010               [Page 57]

Internet-Draft          ANCP Multicast Extensions              July 2009


   o  a Target TLV identifying the AN Port

   o  a Command TLV containing:

      *  a Command Code = Admission Control Reject (since in our example
         the flow is rejected by NAS because of bandwidth admission
         control and not because of conditional access)

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

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

      *  the multicast flow (192.0.2.1, 233.252.2.4)

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

   The Multicast Admission Control message M2 is illustrated below:
































Le Faucheur, et al.      Expires January 4, 2010               [Page 58]

Internet-Draft          ANCP Multicast Extensions              July 2009


       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 = 0010      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |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=0xTBD|0 0 1          |      Command Length           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
       |Type = (Request-S-IP) sub-TLV  | Request-S-IP sub-TLV Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | AddrFamily 01 | EncType 0x0   |  Source : 192.0.2.100         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+



7.2.  Example Flows For Bandwidth Delegation

   As noted in Section 5.1.1, the operation of bandwidth delegation is
   supplemental to the operation of request processing in the absence of
   bandwidth delegation.  Thus the same flows shown in the previous
   section continue to hold, except that the AN does multicast call
   admission before doing grey and white list processing.  The example
   flows of this section are therefore limited to the incremental
   operations of bandwidth delegation.  They include initial
   provisioning, a successful request from the AN for an increase in
   delegated bandwidth, an autonomous transfer of the borrowed bandwidth
   back to the NAS, and the initiation of the bandwidth reset procedure
   (Section 4.10) by the NAS when it finds that the amount of delegated
   bandwidth passed by the AN is larger than its current view of that
   amount.



Le Faucheur, et al.      Expires January 4, 2010               [Page 59]

Internet-Draft          ANCP Multicast Extensions              July 2009


7.2.1.  Activation and Provisioning of Delegated Bandwidth

   Activation of bandwidth delegation occurs at the level of the AN as a
   whole and is done by including a Bandwidth-Delegation-Control TLV in
   the Provisioning message with the E-flag set to 1.  The message flow
   is as shown in Figure 11.  In place of Figure 12 we have the
   following content within the Provisioning message:

                       1                   2                   3
   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 = 0x06       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IP ver = 0x00                 |       List length = 0x02      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Grp PLen=0x00 | Src PLen=0x00 |           Padding = 0x00      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type = Band-Del-Control   |       TLV Length = 0x04       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|      Reserved  = 0x00       |        Reserved  = 0x00       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   Once bandwidth delegation has been activated, the NAS must provision
   the amount of delegated bandwidth for each access line (unless it is
   pre-configured on the AN).  This requires a Port Management message
   with a Bandwidth-Allocation TLV.  The same Port Management message
   may be used to provision other information, such as the multicast
   service profile name applicable to the access line.  The information
   flow is therefore similar to that in Figure 13.  In the following
   figure, an initial allocation of 8000 kbits/s is provided.



Le Faucheur, et al.      Expires January 4, 2010               [Page 60]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Msg Type = 32 |Rslt =1|        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Port = 0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Port Session Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Event Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|x|x|x|x|x|x|x|   Duration    |    Func = 8   | X-Func = 0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Event Flags         |        Flow Control Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |x|x|x|x|x|x|x|x| Msg Type = 32 | Tech Type = 5 | Block Len = 0 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     # of TLVs = 2             | Ext Block length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TLV Type = 0x01          |  Access-Loop-Cct-ID length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                 Access-Loop-Circuit-ID                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TLV Type = Bandwidth-Alloc   |         TLV length = 4        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Delegated amount = 8000                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 18: Port Management Message Allocating Delegated Bandwidth

7.2.2.  Successful Request For More Delegated Bandwidth

   Suppose that the AN allocates all 8000 kbits/s of its delegated
   amount and receives a Join request requiring another 2000 kbits/s.
   The AN issues a Bandwidth Reallocation Request message where the
   required amount field is set to acquire this amount of additional
   bandwidth.  Since the request is framed in terms of total delegated
   bandwidth, required amount is 10000 kbits/s.  Suppose that the AN is
   configured with a policy that causes it to request enough for one
   additional channel as a preferred amount.  Hence the preferred amount
   is set to 12000 kbits/s.  The Bandwidth Reallocation Request message
   has the following format:



Le Faucheur, et al.      Expires January 4, 2010               [Page 61]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 94   |Rslt=0 |        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request   |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Required amount =  10000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Preferred amount = 12000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 19: Example Bandwidth Reallocation Request Message

   In response to this request, the NAS is willing to grant the full
   preferred amount.  (It could have granted any value between 10000 and
   12000, or it could have rejected the request.)  The Bandwidth
   Transfer message sent as a response indicates that the new delegated
   bandwidth amount is 12000 kbits/s, as shown in the next figure.




















Le Faucheur, et al.      Expires January 4, 2010               [Page 62]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 95   |Rslt=3 |        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Alloc     |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Delegated amount = 12000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 20: Example Bandwidth Transfer Message (Success Response)

7.2.3.  Failed Autonomous Transfer With Reset

   Suppose the AN decides after an interval that it should return 2000
   kbits/s of the 4000 kbits/s that it acquired from the NAS in the
   previous transaction.  It therefore issues a Bandwidth Transfer
   message of its own.  This message differs from the message in
   Figure 20 in two ways.  First, because this is an autonomous transfer
   rather than a response, the Result field in the header is set to
   Ignore (0x0).  Secondly, the Delegated amount is reduced to 10000
   kbits/s.

   Now suppose that somehow the NAS forgot that it passed an additional
   4000 kbits/s to the AN.  Thus its current view of the amount of
   delegated bandwidth is 8000 kbits/s.  The 10000 kbits/s appearing in
   the Bandwidth Transfer message is higher than this, so there is
   clearly a disgareement between the NAS and the AN.  The NAS chooses
   to initiate the reset procedure, perhaps because it is close to
   committing all of its available video bandwidth for unicast service.
   As the initial step in this procedure, it issues a Multicast Status
   message indicating that a reset of the delegated amount is required.
   This is shown in the following figure.






Le Faucheur, et al.      Expires January 4, 2010               [Page 63]

Internet-Draft          ANCP Multicast Extensions              July 2009


   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 | 0x4   |        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Status-info-TLV=TBD    |      Status-TLV-Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Rslt Code = xx | Cmd No = 1    |    Error Message Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Message (padded to 4) if Length > 0           |
   +---------------------------------------------------------------+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Alloc     |          TLV Length = 4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Delegated amount = 8000                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Result Code field within the Status-Info TLV contains the value:
   delegated bandwidth reset required (0xTBD).

        Figure 21: Example Initiation of Delegated Bandwidth Reset

   The NAS stops processing video service requests for the given access
   line when it sends this message.  Similarly, the AN stops processing
   multicast video service requests when it receives the message.  [To
   think about: can service requests that release bandwidth be safely
   processed?  Probably.]  The next step is up to the NAS: it sends a
   Bandwidth Delegation Query Request message to the AN.  The Result
   field in the header is set to Ignore (0x0) as usual for multicast-
   related messages.  The Target TLV is a copy of the one received in
   the original Bandwidth Transfer message.  The message is shown in the
   following figure:







Le Faucheur, et al.      Expires January 4, 2010               [Page 64]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 96   |Rslt=0 |        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 22: Example Delegated Bandwidth Query Request Message

   The AN returns a Delegated Bandwidth Query Response message showing
   that it believes that the amount of delegated bandwidth is 10000
   kbits/s and it has committed 8000 kbits/s of it.  The Result field in
   the header shows Success (0x3) to distinguish the response. [... in
   case we decide to make the query bidirectional ...]


























Le Faucheur, et al.      Expires January 4, 2010               [Page 65]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | MsgTyp = 96   |Rslt=3 |        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    TLV Type = Target          |        Target-TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID=0x0001 |       Circuit-ID Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = Bandwidth-Request   |          TLV Length = 8       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Delegated amount =  10000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Committed amount =  8000                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 23: Example Delegated Bandwidth Query Response Message

   The NAS decides to reset the delegated bandwidth amount to 8000
   kbits/s.  It issues a Port Management message looking exactly like
   the one in Figure 18.  Once it sends this message, it resumes
   processing service requests for the access line concerned.
   Similarly, the AN resumes request processing after it receives the
   Port Management message and resets its view of the current delegated
   bandwidth.  In the short run, this means that it will have to ask for
   more bandwidth if it receives another Join request.  [It seems
   reasonable that the AN would not do so for a period of time after a
   reset or a response to a Bandwidth Reallocation Request that grants
   less than the preferred amount.  Should we establish a timer?]

7.3.  Example Flows For Multicast Flow Reporting

7.3.1.  Per Port Multicast Flow Reporting

   Figure 24 illustrate a message flow in the case where the NAS queries
   the AN about which multicast flow is active on port 10, on port 20
   and on port 11 of the AN.






Le Faucheur, et al.      Expires January 4, 2010               [Page 66]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +----------+    +-------+   +-----+    ANCP    +-----+
   |Subscriber|    | Home  |   | AN  |<---------->| NAS |
   +----------+    |Gateway|   +-----+            +-----+
         |         +-------+     |                   |
         |           |           |  Multicast Flow   |
         |           |           |  Query Request    |
         |           |           |      (M1)         |
         |           |           |<------------------|
         |           |           |                   |
         |           |           | Multicast Flow    |
         |           |           | Query Response    |
         |           |           |      (M2)         |
         |           |           |------------------>|
         |           |           |                   |
         |           |           |                   |



               Figure 24: Per Port Multicast Flow Reporting

   The Multicast Flow Query Request message (M1) is illustrated in
   Figure 25.





























Le Faucheur, et al.      Expires January 4, 2010               [Page 67]

Internet-Draft          ANCP Multicast Extensions              July 2009


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Msg Type = 97 |Rslt=00|        Code = 0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port10)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port20)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port11)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 25: Multicast Flow Query Request message for per-port Mulicast
                              Flow Reporting

   The Multicast Flow Query Response message (M2) is illustrated in
   Figure 26.  It indicates that there is one active multicast flow
   [(192.0.2.1, 233.252.2.4)] on port 10, no active multicast flow on
   port 20 and two active multicast flows [(192.0.2.1, 233.252.2.4) and
   (192.0.2.2, 233.252.2.10)] on port 11.


    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers  |  Sub  | Msg Type = 97 |Rslt=00|        Code = 0       |



Le Faucheur, et al.      Expires January 4, 2010               [Page 68]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Partition ID  |            Transaction Identifier             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |I|      SubMessage Number      |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port10)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port20)             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x1000 (Target)      |        Target TLV Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Access-Loop-Circuit-ID 0x0001 |        Circuit-ID Length      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    Access Loop Circuit ID (port11)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.1      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.4     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+
   |Type=0x19 (Multicast-Flow) TLV | Multicast Flow-TLV Length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Source: 192.0.2.2      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | AddrFamily 01 | EncType 0x0   |  Mcast Flow : 233.252.2.10    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+--+




Le Faucheur, et al.      Expires January 4, 2010               [Page 69]

Internet-Draft          ANCP Multicast Extensions              July 2009


       Figure 26: Multicast Flow Query Response message for per-port
                          Mulicast Flow Reporting

















































Le Faucheur, et al.      Expires January 4, 2010               [Page 70]

Internet-Draft          ANCP Multicast Extensions              July 2009


8.  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 January 4, 2010               [Page 71]

Internet-Draft          ANCP Multicast Extensions              July 2009


9.  IANA Considerations

   This document defines the following additional values within the
   GSMPv3 Message Type Name Space registry:

        +--------------------------------+--------+---------------+
        | Message                        | Number | Source        |
        +--------------------------------+--------+---------------+
        | Multicast Replication Control  | 90     | This document |
        |                                |        |               |
        | Multicast Status               | 91     | This document |
        |                                |        |               |
        | Multicast Admission Control    | 92     | This document |
        |                                |        |               |
        | Bandwidth Reallocation Request | 94     | This document |
        |                                |        |               |
        | Bandwidth Transfer             | 95     | This document |
        |                                |        |               |
        | Delegated Bandwidth Query      | 96     | This document |
        |                                |        |               |
        | Multicast Flow Query           | 97     | This document |
        +--------------------------------+--------+---------------+

   This document defines the following values for the ANCP Status-Info
   Result Code Registry :


























Le Faucheur, et al.      Expires January 4, 2010               [Page 72]

Internet-Draft          ANCP Multicast Extensions              July 2009


   +----------------------------------------------+--------+-----------+
   | Status                                       | Number | Reference |
   +----------------------------------------------+--------+-----------+
   | Command not supported                        | 0x02   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Flag set but not supported                   | 0x03   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Unsupported Address Family                   | 0x05   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Malformed flow address                       | 0x06   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Configuration error (such as Port not        | 0x0a   | This      |
   | enabled for multicast)                       |        | document  |
   |                                              |        |           |
   | Multicast flow does not exist                | 0x0b   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Unsupported address encoding                 | 0x0c   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Additional info needed to execute command    | 0x0d   | This      |
   | (payload MAY contain an indication of the    |        | document  |
   | expected info)                               |        |           |
   |                                              |        |           |
   | Multicast flow count exceeded                | 0x0e   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | M Flag set, but no IP Source address         | 0x0f   | This      |
   | provided                                     |        | document  |
   |                                              |        |           |
   | Invalid preferred bandwidth amount           | 0x11   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Bandwidth delegation not activated           | 0x12   | This      |
   |                                              |        | document  |
   |                                              |        |           |
   | Delegated bandwidth reset required           | 0x13   | This      |
   |                                              |        | document  |
   +----------------------------------------------+--------+-----------+

   This document defines the following additional values within the ANCP
   TLV Type Registry:





Le Faucheur, et al.      Expires January 4, 2010               [Page 73]

Internet-Draft          ANCP Multicast Extensions              July 2009


      +--------------------------------+-----------+---------------+
      | TLV Name                       | Type Code | Reference     |
      +--------------------------------+-----------+---------------+
      | Multicast-Service-Profile      | 0x13      | This document |
      |                                |           |               |
      | Bandwidth-Delegation-Control   | 0x14      | This document |
      |                                |           |               |
      | Bandwidth-Allocation           | 0x15      | This document |
      |                                |           |               |
      | Bandwidth-Request              | 0x16      | This document |
      |                                |           |               |
      | Bandwidth-Status               | 0x17      | This document |
      |                                |           |               |
      | Multicast-Service-Profile-Name | 0x18      | This document |
      |                                |           |               |
      | Multicast-Flow                 | 0x19      | This document |
      +--------------------------------+-----------+---------------+

   This document defines the following values for the ANCP Command Code
   registry:

   +-------------------------------------+----------------+------------+
   | Command Code Directive Name         | Command Code   | Reference  |
   |                                     | Value          |            |
   +-------------------------------------+----------------+------------+
   | Add                                 | 0x01           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Delete                              | 0x02           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Delete All                          | 0x03           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Admission Control Reject            | 0x04           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Conditional Access Reject           | 0x05           | This       |
   |                                     |                | document   |
   |                                     |                |            |
   | Admission Control and Conditional   | 0x06           | This       |
   | Access Reject                       |                | document   |
   +-------------------------------------+----------------+------------+

   This document defines the following additional values to the ANCP
   sub-TLV Type registry:





Le Faucheur, et al.      Expires January 4, 2010               [Page 74]

Internet-Draft          ANCP Multicast Extensions              July 2009


            +--------------------+-----------+---------------+
            | sub-TLV Name       | Type Code | Reference     |
            +--------------------+-----------+---------------+
            | Request-Source-IP  | 0x92      | This document |
            |                    |           |               |
            | Request-Source-MAC | 0x93      | This document |
            +--------------------+-----------+---------------+












































Le Faucheur, et al.      Expires January 4, 2010               [Page 75]

Internet-Draft          ANCP Multicast Extensions              July 2009


10.  Acknowledgements

   The authors would like to acknowledge Wojciech Dec for providing
   useful input to this document, Robert Rennison for his help in
   shaping the definition of the Multicast-Service-Profile TLV, Shridhar
   Rao for his comments and suggestions and Aniruddha A for his proposal
   that formed the base of the Multicast Flow Reporting solution.
   Philippe Champagne, Sanjay Wadhwa and Stefaan De Cnodder provided
   substantial contributions on the solution for the NAS initiated
   multicast control use case.









































Le Faucheur, et al.      Expires January 4, 2010               [Page 76]

Internet-Draft          ANCP Multicast Extensions              July 2009


11.  References

11.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-10 (work in progress), May 2009.

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

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

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

11.2.  Informative References

   [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-07 (work in progress),
              March 2009.

   [I-D.morin-mboned-igmpmld-error-feedback]
              Morin, T. and B. Haberman, "IGMP/MLD Error Feedback",
              draft-morin-mboned-igmpmld-error-feedback-02 (work in
              progress), November 2008.

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




Le Faucheur, et al.      Expires January 4, 2010               [Page 77]

Internet-Draft          ANCP Multicast Extensions              July 2009


   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.
















































Le Faucheur, et al.      Expires January 4, 2010               [Page 78]

Internet-Draft          ANCP Multicast Extensions              July 2009


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 January 4, 2010               [Page 79]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/