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

Versions: 00 01 02 03 04 05 06

Internet Engineering Task Force                         Alexandre Cassen
Internet-Draft                                              Freebox S.A.
Intended status: Informational                              May 25, 2009
Expires: November 26, 2009


               Access Right Distribution Protocol (ARDP)
        <draft-cassen-access-right-distribution-protocol-06.txt>


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on November 26, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   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.








Cassen                 Expires November 26, 2009                [Page 1]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


Abstract

   This document describes a protocol using multicast to securely
   distribute IPTV management elements such as IPTV customer's access
   rights. The protocol typically runs on any piece of equipments to
   locally store owned customers IPTV service access right. This design
   provides access control at aggregation level.


Table of Contents

     1.  Introduction .............................................. 4
        1.1. Scope ................................................. 5
        1.2. Definitions ........................................... 5
     2.  ARDP framework ............................................ 7
        2.1. NSP/CP Hierarchy ...................................... 7
        2.2. Using Multicast to convey ARDP datagrams .............. 7
        2.3. An ID and attributes oriented protocol ................ 8
        2.4. CP Service Plane ...................................... 8
        2.5. ClientID ............................................. 10
        2.6. Conditional Access Right ............................. 10
        2.7. Attributes inheritance ............................... 11
     3.  ARDP Architecture ........................................ 11
        3.1. Interface with NE routing stack ...................... 13
        3.2. Adaptive zapping ..................................... 14
        3.3. Confidentiality and security considerations .......... 15
        3.4. NSP ARDP Server ...................................... 16
        3.5. CP ARDP Server ....................................... 17
        3.6. NE ARDP Client ....................................... 17
        3.7. NSP ARDP Report ...................................... 18
        3.8. NSP ARDP Accounting .................................. 18
        3.9. Make it reliable ! ................................... 19
        3.10. ARDP stream bitrate ? ............................... 20
        3.11. Global Operation workflow ........................... 20
     4.  Multicast Protocol Part .................................. 21
        4.1. IP/UDP packet field descriptions ..................... 21
        4.2. ARDP header Packet Format ............................ 21
        4.3. ARDP AVP Packet Format ............................... 24
     5.  ARDP Base Protocol AVPs .................................. 24
     6.  Unicast Protocol Part .................................... 30
     7.  ARDP Server Operations ................................... 30
     8.  NE ARDP Client Operations ................................ 31
        8.1. Initialize State ..................................... 31
        8.2. Learning State ....................................... 33
     9.  Sending and receiving ARDP datagram ...................... 34
        9.1. Sending .............................................. 34
        9.2. Receiving ............................................ 34
     10.  Acknowledgments ......................................... 34



Cassen                 Expires November 26, 2009                [Page 2]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


     11. References ............................................... 35
     12. Authors' Address ......................................... 36

















































Cassen                 Expires November 26, 2009                [Page 3]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


1. Introduction

   Standard digital TV security models are based on smartcard
   intelligence at the end user CPE side. We will not present global
   goal and design of Conditional Access System since this is not the
   scope of this document. We can simply remind that digital pay TV is
   based on such a system where EMM (Entitlement Management Message), an
   encrypted message, provides private conditional access information
   concerning the broadcast services one viewer is allowed to receive.
   The challenge of such an architecture is to provide strong
   cryptographic systems to protect EMM messages against piracy since
   EMM are stored directly into the CPE/smartcard. If this system can be
   considered as good for regular broadcasting design where no upstream
   (on CPE side) is available, this design can be enhanced on network
   (xDSL, FTTx) offering upstream feedback channel.

   The very first security consideration rely more on trust aggregation
   network or any routing equipements and reduce end user CPE
   intelligence/complexity.  Networking architecture provides a way to
   dissociate Conditionnal Acces and video content protection. While
   stream can still use standard DVB-CSA scrambling design, EMM
   equivalent can be stored into aggregation equipment.  CPE is
   considered as no trust equipement and the idea is to reduce to the
   max the action it may have. CPE intelligence and operations on
   security side can be emulated which open the door to reverse
   engineering. For services like IPTV, this design offers a secure
   conditional access design by physically dissociating both security
   components. Stream access is controled during stream subscribtion
   stage. The CPE simply requests for a video stream and the aggregation
   equipment grants or not access according to its local access database
   (local access right cache).

   The challenge for now is to find a secure and scalable way to
   populate aggregation equipments access database. We can be inspired
   from the broadcasting model by using multicast transmission to
   distribute access rights over a network backbone. The following
   document will present a protocol used on top of IP to securely
   distribute those access rights.













Cassen                 Expires November 26, 2009                [Page 4]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


1.1 Scope

   The remainder of this document describes the features, design goals,
   and theory of operation of Access Right Distribution Protocol - The
   message format, protocol processing rules and state machine that
   guarantee safe and secure operations.

1.2 Definitions

   In this document we will use same Definitions/Abbreviations as
   present in [AAA] document.

   ChannelID              An abstraction modelizing a CP pieces of
                          informations identifying a CP IPTV streaming
                          service (multicast group and any other
                          low-level related attributes).

   ServiceID              An abstraction modelizing a CP pieces of
                          informations identifying a CP IPTV set of
                          ChannelID.

   ClassID                An abstraction modelizing a CP pieces of
                          informations identifying a CP IPTV set of
                          ServiceID.

   Service Plane          An abstraction modelizing the CP set of
                          ClassID / ServiceID.

   ClientID               An abstraction modelizing association between
                          customer Identification number and physical
                          IP address (or MAC address or phone number).
                          Each IP address (or MAC or phone number) can
                          have multiple ClientID, each one is unique to
                          each CP namespace.

   Access Right           An abstraction modelizing a customer
                          conditional access on a specific ServiceID or
                          ClassID. It determines whether or not a
   ClientID
                          can access a specific ServiceID or ClassID.

   CP                     Content Provider is in charge of multicast
                          content streaming. Each CP is also in charge
                          of distributing Service Plane, ClientID,
                          Access Right over ARDP backbone.

   ARDP Backbone          A Wide Area Network made of lot of ARDP
                          clients.



Cassen                 Expires November 26, 2009                [Page 5]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   NSP                    Network Service Provider owns ARDP Backbone
                          and is in charge of any administration related
                          operations over it.

   NE                     Network Equipment is runing an ARDP Client and
                          is storing Access Right. It controls and
                          maintains multicast subscription.

   ARDP Client            A Software component running ARDP protocol on
                          network aggregation routing equipments. It is
                          responsible for NE local right cache
                          management and is interacting with NSP ARDP
                          Server. It stores all CP Service Plane,
                          ClientID, associated security elements (RSA
                          public key) and customer Access Right.

   CP ARDP Server         Each CP stores an RSA keypair and uses RSA
                          private key to sign all ARDP protocol
                          datagrams sent to ARDP Backbone. The RSA
                          public key is exported to all NE ARDP Clients.
                          It manages Service Plane and Access Right
                          flooding.

   NSP ARDP Server        A server running ARDP protocol and acting as
                          root authority. This server distributes
                          ClientID over ARDP backbone and forwards ARDP
                          requests to CP ARDP servers.

   ARDP Session           A connection issued by NSP ARDP Server to
                          CP ARDP Server to request Access Right
                          flooding for a set of CP ClientID.

   NSP Accounting Srv     A server listening and handling any
                          accounting reports sent by NE.

   NSP Report Srv         A server acting as a proxy between
                          NE and Back-office management systems.
                          Use to fetch/verify Access Right
                          bound to a specific ClientID.

   CDS                    Content Delivery Services.

   CPE                    Customer Premise Equipment.








Cassen                 Expires November 26, 2009                [Page 6]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


2. ARDP framework

   ARDP provides secure, scalable and reliable facilities to distribute
   IPTV management elements. Those elements are :

     . CP Service Plane (ClassID/ServiceID)
     . ClientID
     . Access Right

2.1. NSP/CP Hierarchy

   ARDP design tend to create a hierarchy between NSP and CP. NSP trust
   CP with point of presence in its ARDP Backbone, but for
   security/maintenability reasons NSP MUST protect/hide its low-level
   topology. NSP is in charge with administration and operations all
   over its backbone, each NE can change/migrate to a different routing
   plane, each customer can roam from NE to NE and consequently change
   their routing related elements and path (change of IP address for
   example).

   NSP is responsible for keeping accurate association between ClientID
   and IP Address in all CP namespace.

   CP operations are CDS centralized, it manages informations needed to
   run its business : ServiceID/ClassID/Access Right.

2.2. Using Multicast to convey ARDP datagrams

   ARDP is running over multicast. ARDP Servers are a only multicast
   sending source while NE ARDP Client are a only multicast receiver.

   Every CP are network low-level topology agnostic, using multicast
   provides a simple and scalable answer to offer a full and realtime
   distribution of Access Right to each CP.

   IPTV makes extensive use of multicast, using multicast for ARDP and
   localizing it into same networking plane as other regular streamed
   contents will provide an accurate feedback on multicast reliability
   until NE. As presented in section 4.5, ARDP architecture defines an
   accounting server used to handle ARDP protocol reliability, any
   trouble occuring on ARDP multicast flow can be extrapolated to other
   multicast flows into the same networking plane.

   Finally, using multicast as distribution vector offers to ARDP
   protocol a very short convergence time since one change will be
   learnt and affect every NE at a time. For example, changing any
   Service Plane piece of informations (multicast group, ...) will be
   quite realtime.



Cassen                 Expires November 26, 2009                [Page 7]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


2.3. An ID and attributes oriented protocol

   ARDP is network topology agnostic by making extensive use of ID for
   addressing every low-level elements. IDs are key-elements just like
   those found in DVB satellite architecture. Using IDs create an
   abstraction between managed and target elements leading to a very
   short (optimum) convergence time needed while updating those target
   elements.

   CP Service Plane is the ARDP fundation element. Every CP are
   permanently flooding over ARDP backbone all of their ServiceID and
   ClassID elements. On its own, NSP is flooding ClientID elements.
   Service Plane and ClientID open the road to CP Access Right flooding,
   in other words: setting an Access Right for a ServiceID or ClassID to
   a target ClientID. An Access Right is thus a binding between a
   ClientID and a ServiceID or a ClassID.

   The others ARDP key-elements are attributes. Every IDs are filled
   with a set of attributes like presented in section 4.3.1. ServiceID,
   ClassID, ClientID are a set of attributes.

   Creating ID abstraction provides flexibility while managing
   attributes. Attributes values updates (over ClassID, ServiceID,
   ClientID, ....) will not impact any ARDP operations since Access
   Right binding is made on ID.

2.4. CP Service Plane

   Service Plane is managed by a CP, it defines low-level elements CP
   will use to run its business. A Service Plane is thus a set of
   ServiceID and ClassID learnt by NE ARDP Client. Service Plane brings
   an important flexibility for CP since it can change any elements in
   quite realtime. It provides functional flexibility like defining
   playlist based ServiceID, adaptive zapping, ...

2.4.1. ServiceID

   A ServiceID is compounded by a set of ChannelID and is unique in CP
   ARDP namespace. Its management representation is an ID and is filled
   using the following ABNF notation as in [RFC4234]:

     ServiceID ::= { Auth-Service-Id }
                 * [ AVP ]
                   { Service-Profile }
                   [ Channel-Id [ AVP ] ]
                   { Service-Profile-fallback }
                   [ Channel-Id [ AVP ] ]




Cassen                 Expires November 26, 2009                [Page 8]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   Detailed AVPs declaration and specifications can be found in section
   5.

   A live IPv4 only example can be :

     SvcID  | Service Attributes
   ---------+---------------------------------------
        201 | . Service Name : IETF IPTV Room1
            | . PC Redirect : 1
            | . Number of Decoder : 2
            | . Accounting-Zap : 192.168.200.10
            | . Profile :
            |   . ChannelID : 419
            |     . Service Name : IETF IPTV HD
            |     . Multicast Group : 239.1.2.3
            |     . Unicast Source : 192.168.200.1
            |     . Capabilities : 0x0002
            |     . Bitrate : 5500
            |   . ChannelID : 32
            |     . Service Name : IETF IPTV SD
            |     . Multicast Group : 239.1.2.4
            |     . Unicast Source : 192.168.200.2
            |     . Capabilities : 0x0004
            |     . Bitrate : 3600
            |   . ChannelID : 347
            |     . Service Name : IETF IPTV H264
            |     . Multicast Group : 239.1.2.5
            |     . Unicast Source : 192.168.200.3
            |     . Capabilities : 0x0008
            |     . Bitrate : 2000
            | . Profile Fallback :
            |   . ChannelID : 519
            |     . Service Name : IETF FB HD
            |     . Multicast Group : 239.1.2.6
            |     . Unicast Source : 192.168.200.4
            |     . Capabilities : 0x0002
            |     . Bitrate : 5500
            |   . ChannelID : 132
            |     . Service Name : IETF FB SD
            |     . Multicast Group : 239.1.2.7
            |     . Unicast Source : 192.168.200.5
            |     . Capabilities : 0x0004
            |     . Bitrate : 3600
            |   . ChannelID : 447
            |     . Service Name : IETF FB H264
            |     . Multicast Group : 239.1.2.8
            |     . Unicast Source : 192.168.200.6
            |     . Capabilities : 0x0008



Cassen                 Expires November 26, 2009                [Page 9]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


            |     . Bitrate : 2000

   In this example ServiceID 201 defines "IETF IPTV Room1" service.

2.4.2. ClassID

   A ClassID is managed by a CP, it defines a set of ServiceID and is
   filled using the following ABNF notation as in [RFC4234]:

     ClassID ::= { Auth-Class-Id }
               * [ AVP ]
                 [ Auth-Service-Id ]

   A live example can be :

    ClassID | Class Attributes
   ---------+---------------------------------------
         74 | . Class Name : IETF IPTV Area
            | . Number of Decoder : 3
            | . Service :
            |    201 202 203 204 205 206 207 208

2.5. ClientID

   A ClientID defines an NSP low-level binding between Client networking
   informations and its ARDP representation. A ClientID is filled using
   the following ABNF notation as in [RFC4234]:

     ClientID ::= { Auth-Client-Id }
                * [ AVP ]

   A live IPv4 only example can be :

    ClientID | Client Attributes
   ----------+---------------------------------------
         100 | . IP-Address : 10.1.1.1
             | . Number of Decoder : 5
             | . Accounting-Zap : 192.168.200.150

2.6. Conditional Access Right

   A conditional Access Right defines a binding between
   (ClientID,ServiceID) or (ClientID,ClassID). CP is setting those
   bindings for every ClientID it manages. If a Client is subscribing to
   a marketing offer modelized in ARDP by ClassID 74 then CP simply send
   an ARDP datagram to set/create this binding.





Cassen                 Expires November 26, 2009               [Page 10]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


2.7. Attributes inheritance

   ARDP provides attributes inheritance design between every element it
   manages. Inheritance tree is :

      ServiceID
          ^
          |
       ClassID
          ^
          |
       ClientID

   ServiceID is surcharging ClassID attributes surcharging ClientID
   attributes.

   If we use the live example presented in previous sections, "Number of
   Decoder" attributes will finally have the value of 2.

3. ARDP Architecture

   We can localize each ARDP architecture component on the following
   diagram :




               +-----------+        +-----------+
               |           |        |           |
     __________| CP ARDP 1 |________| CP ARDP 2 |________________
    /          |           |        |           |                \
   /           +-----------+        +-----------+                 \
   |                                                              |
   |                        ARDP Backbone                         |
   |                                                              |
   \   +-------+               +------+   +------+  +------+      /
    \__|  NSP  |_______________| NE 1 |___| NE 2 |..| NE n |_____/
       |  ARDP |               +------+   +------+  +------+
       +-------+                ^    ^        ^        ^
                 ................    .        .        .
                 .                   .        .        .
      +--------- v +     +---------- v +      .        .
      | NSP ARDP   |     |  NSP ARDP   |<......        .
      | Accounting |     |   Report    |<...............
      +------------+     +-------------+






Cassen                 Expires November 26, 2009               [Page 11]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   NSP ARDP            : NSP ARDP Server
   CP ARDP 1           : CP 1 running CP 1 ARDP Server
   CP ARDP 2           : CP 2 running CP 2 ARDP Server
   NE 1                : NE 1 running NE 1 ARDP Client
   NE 2                : NE 2 running NE 2 ARDP Client
   NE n                : NE n running NE n ARDP Client
   NSP ARDP Accounting : NSP Accounting Server
   NSP ARDP Report     : NSP Back-Office Report Server

   All customer ClientID are flooded from NSP ARDP Server. All customer
   Access Right are flooded from CP ARDP Server. Every CP ARDP Server
   are flooding Service Plane and Access Right for ServiceID/ClassID
   they manage. NE ARDP Client is then filtering received multicast
   datagrams to only store Access Right, for customers it hosts
   (ClientID).

   ARDP finality is then to maintain Access Right cache integrity on NE
   ARDP Client side and to offer any CP the ability to flood directly
   Service Plane and Access Right over ARDP Backbone.
































Cassen                 Expires November 26, 2009               [Page 12]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


3.1. Interface with NE routing stack

   In IPTV architectures, stream subscription is most of the time done
   through IGMP (as described in [RFC3376]) since streaming is done via
   multicast. In IGMP there is a lake of feedback while performing JOIN
   or LEAVE operation, in this document we will not use IGMP as
   subscription protocol, we will rather use SUBSP acronym to identify
   this subscription protocol. SUBSP MUST be a protocol offering
   feedback/error reporting and using transactionnal design to benefit
   any ARDP features and flexibilities. SUBSP can be :

      - RTSP as described in [RFC2326]
      - SIP/RTSP as descibed in [SIPRTSP]

   ARDP operates close to aggregation equipment stack at subscription
   protocol level. The diagram below shows general ARDP operations :

   +--------------------------------------------------------+
   | NE Routing Software                                    |
   |                                 +--------------------+ |
   |                                 |        ARDP        | |
   |                                 |  Information Base  | |
   |   +------------------------+    +----------^---------+ |
   |   |   CORE Routing Stack   |               |           |
   |   |                +-------+        +------v-----+     |
   |   |                | SUBSP |<------>| ARDP Stack |     |
   |   +----------------+---^---+        +------------+     |
   +------------------------|-------------------------------+
                            |
                            |
                     +------v------+
                     |     CPE     |
                     +-------------+

   When CPE requests for a ServiceID, it generates an Access Request
   caught by NE routing stack. Before processing the subscription
   operation, SUBSP stack requests authorisation to ARDP Stack. If
   access is granted by ARDP then SUBSP stack proceeds to perform stream
   subscription and any routing related task. SUBSP is thus sending
   Access Request to ARDP Stack.







   Authentication workflow between CPE and NE Routing Software is



Cassen                 Expires November 26, 2009               [Page 13]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   defined as :

          +------+             +-------+             +------+
          | CPE  |             | SUBSP |             | ARDP |
          +------+             +-------+             +------+
             |                     |                     |
             |    JOIN / LEAVE     |                     |
             |-------------------->|    Access-Request   |
             |                     |-------------------->|
             |                     |                     |
             |                     |   Access-Response   |
             |                     |<--------------------|
             |    ACK / NAK        |   (DENY / ACCEPT)   |
             |<--------------------|                     |
             |                     |                     |

   Using ABNF notation as in [RFC4234] SUBSP Access-Request and Access-
   Response can be specified as :

     Access-Request ::= { Namespace }
                        { Auth-Client-Id / IP-Address }
                        { Auth-Service-Id }

     Access-Response ::= { DENY / ACCEPT }
                         [ Channel-Id [ AVP ] ]

   While handling Access-Response ARDP stack will append ServiceID's
   Profile or Profile Fallback rather it is an ACCEPT or a DENY.

3.2. Adaptive zapping

   An important feature provided by ARDP Service Plane is to offer
   adaptive zapping. As described in section 3.1 customer zapping in
   translated into sending an Access Request to ARDP for a specific
   ServiceID. As described in section 2.4.1, ServiceID is a set of
   ChannelID filled with a set of attributes. While performing
   conditionnal Access Right operations, NE routing software can
   adaptively select a ChannelID based on attribute matching.

   A specific use case of this feature is to select a ChannelID based on
   bitrate attribute value so that zapping will be dynamic/adaptive
   according to available bandwitdh between CPE and NE. If a CPE is
   feeded with multiple streams at a time then this mecanism can
   optimize bandwidth usage.







Cassen                 Expires November 26, 2009               [Page 14]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


3.3. Confidentiality and security considerations

   First of all, ARDP operates in a separate/dedicated network plane
   without any physical link with the CPE network. It is mandatory to
   separate the ARDP network plane from the CPE network plane. Only
   aggregation equipment can access the ARDP plane and CPE plane;
   however no routings or forwardings rules may exist between the two
   planes.

   ARDP protocol is disigned to operate in a multi-operator fashion.
   From the networking point of view it is running multiple multicast
   sending sources at a time.  One of the goals of the protocol is to
   give CP full control of Service Plane and Access Right for running
   its business.  NSP provides a Namespace and a point of presence in
   ARDP backbone to each CP. Using ARDP, a CP can manage Service Plane
   and Access Right through head-end in realtime using flexibility of
   multicast.

   ARDP architecture defines a hierarchy between NSP and CP.  On the one
   hand NSP, formerly an IPTV operator owning network infrastructure,
   has a role of arbitration and root authority :

     - Distributes all CP ClientID over ARDP Backbone. Each CP
       has its own namespace for ClientID but the association
       between a CP ClientID and a physical client (customer)
       identification (IP address, MAC address, phone number, ...) is
       only known by NSP.

     - Requests CP ARDP Server to distribute Access Right to
       a particular ClientID.

   On the other hand, CP is a supervisor authority for distributing ARDP
    Service Plane and Access Right it manages :

     - Handles NSP ClientID request by flooding in response
       the associated ARDP Access Right.

     - Permanently flood Service Plane.

   A RSA signature is used to guaranty protocol datagram authenticity
   and integrity using a RSA keypair. Each ARDP Server stores its RSA
   private key and CP ARDP Client stores all RSA exported public key. A
   Public Key Infrastructure can be used to distribute RSA pubkey, we
   will not detail this part since it is out of the scope of this
   document.

   On the other hand ARDP is using sequence numbers in every datagram
   and generated at server side which prevent against any kind of replay



Cassen                 Expires November 26, 2009               [Page 15]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   attack. ARDP protocol replay attack is not intrinsec possible since
   ARDP message contains validity range. If a malicious source try to
   replay any previously recorded datagrams, the final effect will just
   be a forced update at NE side, that will end on a no effect
   injection. The benefit brought by sequence number, when used with
   authenticated datagrams (HMAC-MD5-96bit or RSA), resides in the key
   decision it provides to drop any incoming malicious datagram and thus
   prevent against any time consuming task induced by datagram handling.
   In addition ARDP AVPs can be encrypted.

3.4 NSP ARDP Server

   The main goal of this server is to distribute CP ClientID over ARDP
   backbone and issue ARDP Sessions with CP ARDP Server. Main functional
   elements blocks can be represented as following :

        . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .                                                         .
     .                                                            .
    .                                                              .
   |                         ARDP Backbone                          |
   |                                                                |
   |                                                                |
   |    +-----------+    ^(MCAST)                                   |
   \    |           |     .        +------+   +------+  +------+   /
    \___|  CP ARDP  |______._______| NE 1 |___| NE 2 |..| NE n |__/
        |           |        .     +------+   +------+  +------+
        +-----------+         .        .                   .
             ^                 .       .  (TCP)            .(TCP)
              .(TCP)            .      .............    ....
               .                 .                 .    .
         +----- . --------------- . -------------- v -- v -------+
         |  +--------------+  +----------------+ +-------------+ |
         |  | ARDP Session |  | ClientID Flood | | NE Listener | |
         |  +--------------+  +----------------+ +-------------+ |
         |                               +------------------+    |
         |                               | Subscribers's DB |    |
         |                               |     Interface    |    |
         | NSP ARDP Server               +------------------+    |
         +-------------------------------------------------------+

   NSP ARDP Server fonctionnalities are :

   - ARDP Session : Peering, using TCP, ClientID to CP ARDP Server
                    to request CP Access Right flooding accordingly.

   - ClientID Flooding : Flooding, using multicast, ClientID of every
                         CP.



Cassen                 Expires November 26, 2009               [Page 16]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   - NE Listener : Listening, on TCP, to any NE flooding requests.

   - Subscriber's DB Interface : It is closely linked to subscriber's
                                 database to fetch accurate informations
                                 for ClientID flooding and Session
                                 with every CP ARDP Servers.

3.5 CP ARDP Server

   This server is managed by CP and operates two major tasks:

   - Autonomous ARDP flooding : Any CP back-office MUST and NEED to send
   Access Right whenever it is needed.

   - Sollicited ARDP flooding : Any CP ARDP Server MUST send Access
   Right over ARDP Backbone upon NSP ARP Server request received by ARDP
   session.

3.6 NE ARDP Client

   Is running on NE and is managing NE ARDP information base. Main
   functional elements blocks can be represented as following :

        . . . . . . . . . . . . . . . . . . . . . . . . . . .
     .                                                          .
    .                                                            .
   |                         ARDP Backbone                        |
   |                                                              |
   \    +------+ +------+                                        /
    \___| CP   |_| NSP  |________________________________.______/
        | ARDP | | ARDP |<..................             .
        +------+ +------+                  .             .
                                           .             .
   +-------------+        +--------------- . ----------- . ------+
   |  NSP ARDP   |        | +----------+ +-.----+   +----v-----+ |
   |   Report    |<........>| Report   | | NSP  |   | MCAST    | |
   +-------------+        | | Listener | | Req. |   | Listener | |
                          | +----------+ +------+   +----------+ |
   +-------------+        |                                      |
   |  NSP ARDP   |        | +------------+  +------------------+ |
   |  Accounting |<.........| Accounting |  | Routing Software | |
   +-------------+        | | Notifier   |  | Interface        | |
                          | +------------+  +------------------+ |
                          |                                      |
                          | NE ARDP Client                       |
                          +--------------------------------------+





Cassen                 Expires November 26, 2009               [Page 17]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   NE ARDP Client fonctionnalities are :

   - MCAST Listener : Multicast listener handling incoming ARDP
                      datagram received from ARDP Backbone.

   - NSP Requester : Send ARDP flooding request to NSP ARDP Server.
                     ARDP ClientID and Access Right flooding requests.

   - Routing Software interface : A TCP listener handling Access-Request
                                  coming from SUBSP (as presented in
                                  section 3.1.)

   - Report Listener : A TCP listener, listening to NSP ARDP Report
                       server Access Right fetching request.

   - Accounting notifier : Periodically notify, using TCP, NSP
   Accounting
                           Server to internal informations and states.

3.7 NSP ARDP Report

   The main goal of this server is to provide an interface to customer's
   management back-office in order to fetch ClientID Access Right
   bindings and thus providing an accurate feedback on internal ARDP NE
   storage. For exemple it can provides facilities to customer's hotline
   in order to verify customer Access Right.

3.8 NSP ARDP Accounting

   The main goal of this server is to provide ARDP protocol accounting
   facilities. NE ARDP Client push periodically internal informations to
   this central node. This accounting server offers a centralized
   consolidation point. NE ARDP Client can push informations like :

    - ARDP Stream discontinuity.
    - Customer zapping request rate.
    - ServiceID zap auditing.
    - ...

   In this document we will not detail protocol framing used to push
   accounting informations to NSP ARDP Accounting server, but it is
   mainly using the ARDP protocol header with ARDP AVPs append.

   Due to its push design fashion, NE ARDP Client needs to add a skew
   factor to its internal timer pushing informations to workaroung any
   flooding side-effect. IPTV customer's uses are impulsive and
   periodical, pushing timer needs to be short in order to consider and
   consolidate accurate informations.



Cassen                 Expires November 26, 2009               [Page 18]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


3.9 Make it reliable !

   ARDP is using multicast to distribute protocol datagrams. The main
   constraint using multicast is to make it reliable since it is not
   connected. Any datagram can be lost in transit especially when
   running on a very large network. There is multiple way found into
   litterature to handle reliability of multicast stream.

   The very first design is to retransmit lost sequences. As presented
   in section 4.2.7, ARDP datagrams are sequenced so that ARDP Client
   can learn how many ARDP datagrams have been lost and request for
   retransmission. Retransmission can also be operated by agnostic
   protocol like presented into [RMT] IETF Working Group. The main side
   effect of such an architecture is to lead to massive restransmission
   flooding. Actually, on large operator network it is most likely any
   operationnal actions on routings or network equipments will lead to
   lost datagram into network regions where operations took place. It
   can be extrapolated to a massive retransmission request if drops are
   localized close to multicast streaming source. This design can be
   considered for multicast stream where lost of datagram is critical
   and irreversible, if lost datagram can be recomputed and
   retransmitted later on then we can investigate others alternatives
   offering flexibility of delayed operations.

   An alternative to previous design would be to completely ignore lost
   datagrams and, instead, periodically flood global ARDP protocol
   informations (ClientID + Access Right). The main advantage with this
   approach is its simplicity but its cost resides in flooding time
   increase accordingly to number of ARDP datagram to be sent. On one
   hand we have the flexibility of delayed operations, on the other hand
   we increase convergence time and impact scalability.

   Another alternative would be to mix both approaches. NE ARDP Client
   is periodically pushing back to NSP ARDP Accounting Server protocol
   stream discontinuity so that if NSP ARDP Server is notified
   accordingly it can flood back to NE any ARDP protocol related
   informations (ClientID + Access Right). NSP ARDP Server can
   selectively flood ARDP protocol informations by NE. This approch will
   scale and provide flexibility of mass flooding. This document will
   prefer this approach.











Cassen                 Expires November 26, 2009               [Page 19]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


3.10. ARDP stream bitrate ?

   ARDP is a multicast streamed protocol so that its bitrate will
   directly impact receiving processing, even more since it is using
   crypto. Controlling ARDP sending source will control any NE ARDP
   Client time computing ressources. Making ARDP stream Constant BitRate
   will transitively induce a maximum time computing threshold tweakable
   at sending source.

3.11. Global Operation workflow

   The following diagram gives the general workflow of ARDP protocol.

               +-----------+        +-----------+
               |           |        |           |
     __________| CP ARDP 1 |________| CP ARDP 2 |________________
    /    +---->|           |        |           |                \
   /     |     +-----------+        +-----------+                 \
   |     |               \                                        |
   |     |                \(d)                                    |
   |     |                 \                                      |
   |     |(c)    ^          v      ARDP Backbone                  |
   |     |      /                                                 |
   |     |     /(b)                                               |
   |     |    /                                                   |
   \   +-------+              +------+   +------+  +------+       /
    \__|  NSP  |______________| NE 1 |___| NE 2 |..| NE n |______/
       | ARDP  |              +------+   +------+  +------+
       +---^---+                  |
           +----------------------+
                   (a)

   This sample configuration illustrates ARDP operation workflow from ARDP
   protocol boot-up state (a) through ClientID and Access Right flooding stage
   (b), (c) and (d). Protocol operates at both Multicast and
   Unicast levels such as follows :

      (a) Unicast message : NE 1 informs NSP ARDP Server of its
          initialization state. It requests for ClientID and right
          flooding.

      (b) Multicast message : NSP ARDP Server floods ClientID for each
          customer hosted by NE 1 in each CP ClientID namespace.

      (c) Unicast message : NSP ARDP Server requests Access Right flooding
          to each remote CP ARDP Server for given ClientID in each
          CP ClientID namespace.




Cassen                 Expires November 26, 2009               [Page 20]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


      (d) Multicast message : In response to (c) each CP ARDP Server
          floods Access Right requested by NSP ARDP Server.

4. Multicast Protocol Part

   ARDP protocol operates at multicast level and runs over UDP.
   ARDP packet are encapsulated in IP/UDP packets and sent to a
   routed multicast IPv4 address over ARDP Backbone. Multicast offers
   a many-to-many entities discussion. Using UDP encapsulation offers
   the ability to run multiple ARDP plane using the same multicast
   routing ressource.

4.1. IP/UDP packet field descriptions

   For the current ARDP version 1 there is no layer3/4 restrictions.
   Multicast TTL must be set with a proper value permitting
   backbone traversal.

4.2. ARDP header packet format

   Each ARDP protocoal datagram starts with ARDP header as follows.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Ver  |   Hl  |   Msg Type    |            Size               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Count Msg    |E| Auth Type   |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Source CP ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Namespace                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            NE ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   |                          CP Signature                         |
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ARDP AVPs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-










Cassen                 Expires November 26, 2009               [Page 21]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


4.2.1. Version field

   Specifies the ARDP protocol version a packet belongs to. Our current
   document describes Version 1.

4.2.2. Header Length field

   Specifies the length of the ARDP header.

4.2.3. Message Type field

   Specifies the type of ARDP packet data part following the ARDP
   header.  ARDP message types are :

      - 0x01 : CP Conditional Access Attributes message
      - 0x02 : CP ServiceID Attributes message
      - 0x03 : CP ClassID Attributes message
      - 0x04 : ClientID Attributes message

4.2.4. Size field

   Specifies the total size of the ARDP packet including ARDP header and
   message data.

4.2.5. Count Messages field

   Specifies the number of ARDP message data included in the global ARDP
   packet.

4.2.6. Encryption flag

   Specifies, if set to 1, that ARDP AVPs are encrypted using [AES].

4.2.6. Authentication Type field

   Specifies kind of authentication used to sign the ARDP packet.
   Mandatory Authentication Type are :

      - 0x01 : No authentication signature
      - 0x02 : Use HMAC-MD5-96bit signature as described in [RFC2104]
      - 0x03 : Use RSA signature as described in [RFC2437]

4.2.8. Sequence Number field

   This 16-bit field contains a monotonically increasing counter value
   managed at ARDP Server side. Each ARDP Server maintains a sequence
   counter for every ARDP Message Types it may send. This sequence
   number is legitimated by 2 points.



Cassen                 Expires November 26, 2009               [Page 22]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


4.2.9. Source CP ID field

   Specifies the CP origin of the ARDP packet. This gives ARDP Client
   side the possibility to select authentication to be used as sanity
   check.  An Operator ID is a 32bit value identifying in a unique way
   any CP. This can be an IPv4 IP address used as point of presence in
   ARDP Backbone.

4.2.10. Namespace field

   This field is used during ClientID flooding to indicate which CP the
   ClientID flooding message belongs to.

4.2.11. NE ID field

   This field is used during flooding to indicate which NE the
   ClientID/Access Right flooding messages belongs to. This field
   prevent against filtering every AVPs in every datagram while
   processing. NE will process datagram if NE ID field found in ARDP
   header is matching its locally configured ID. If field is zeroed then
   NE will process inconditionnally datagram.

4.2.12. CP Signature field

   Includes the digital signature (if used) to authenticate ARDP packet.
   On ARDP Client side, Source CP ID field indicates which CP secret or
   key to be used. Depending on authentication type used, this field is
   96bit length long for HMAC-MD5-96bit signature or larger for RSA
   signature.






















Cassen                 Expires November 26, 2009               [Page 23]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


4.3. ARDP AVP Packet Format

   ARDP AVPs carry specific authentication, accounting, authorization,
   routing and security information as well as configuration details for
   a specific ServiceID, ClassID and ClientID. This message refers to
   format and paradigm as presented in [RFC3588]. Every ARDP AVPs are
   using the following Header specification as described in section 4.1
   of [RFC3588]:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           AVP Code                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V M P r r r r r|                  AVP Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Vendor-ID (opt)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+-+-+-+-+

   In following sections we will define specifics AVPs for use in ARDP
   protocol using Basic AVP data formats and Derived/Grouped AVP data
   formats as in section 4.2 and 4.3 of [RFC3588].

5. ARDP Base Protocol AVPs

   The following table describes the ARDP AVPs defined in the base
   protocol, their AVP Code Values, types, possible flag values and
   whether the AVP MAY be encrypted. For the the originator of a ARDP
   message, "Encr" (Encryption) means that if a message containing that
   AVP is to be sent via an ARDP server then the message MUST NOT be
   sent unless there is a end-to-end security between the originator and
   the recipient (eg: between ARDP Server and ARDP Client).

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Data Type  |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   Auth-Service-  65536 3.3.3    Unsigned32 | M  |  P  |    |  V  | N  |
     Id                                     |    |     |    |     |    |
   Auth-Class-    65537 3.3.4    Unsigned32 | M  |  P  |    |  V  | N  |
     Id                                     |    |     |    |     |    |
   Auth-Client-   65538 3.3.5    Unsigned32 | M  |  P  |    |  V  | N  |
     Id                                     |    |     |    |     |    |
   Auth-Client-   65539 3.7.3    Address    | M  |  P  |    |  V  | N  |



Cassen                 Expires November 26, 2009               [Page 24]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


     Address                                |    |     |    |     |    |
   Auth-Begin-    65540 3.3.6    Time       | M  |  P  |    |  V  | N  |
     Validity                               |    |     |    |     |    |
   Auth-End-      65541 3.3.7    Time       | M  |  P  |    |  V  | N  |
     Validity                               |    |     |    |     |    |
   Accounting-    65542 3.3.8    Address    | M  |  P  |    |  V  | N  |
     Server                                 |    |     |    |     |    |
   Multicast-     65543 3.5.3    Address    | M  |  P  |    |  V  | N  |
     Group                                  |    |     |    |     |    |
   Unicast-       65544 3.5.4    Address    | M  |  P  |    |  V  | N  |
     Source                                 |    |     |    |     |    |
   Bitrate        65545 3.5.7    Unsigned32 | M  |  P  |    |  V  | N  |
   Capabilities   65546 3.5.8    Unsigned32 | M  |  P  |    |  V  | N  |
   Service-Name   65547 3.5.9    UTF8String | M  |  P  |    |  V  | N  |
   Version-Code   65558 3.5.10   Unsigned32 | M  |  P  |    |  V  | N  |
   -----------------------------------------|----+-----+----+-----|----|


   ARDP Grouped AVPs are set of Base Protocol AVPs:

                                            +---------------------+
                                            |    AVP Flag rules   |
                                            |----+-----+----+-----|----+
                   AVP  Section             |    |     |SHLD| MUST|    |
   Attribute Name  Code Defined  Data Type  |MUST| MAY | NOT|  NOT|Encr|
   -----------------------------------------|----+-----+----+-----|----|
   Access-Right-  65580 3.4.1     Grouped   | M  |  P  |    |  V  | N  |
     Add                                    |    |     |    |     |    |
   Access-Right-  65581 3.4.2     Grouped   | M  |  P  |    |  V  | N  |
     Delete                                 |    |     |    |     |    |
   Accounting-    65582 3.4.3     Grouped   | M  |  P  |    |  V  | N  |
     Zap                                    |    |     |    |     |    |
   ServiceID-Add  65583 3.5.1     Grouped   | M  |  P  |    |  V  | N  |
   ServiceID-     65584 3.5.2     Grouped   | M  |  P  |    |  V  | N  |
     Delete                                 |    |     |    |     |    |
   ClassID-Add    65587 3.6.1     Grouped   | M  |  P  |    |  V  | N  |
   ClassID-Delete 65588 3.6.2     Grouped   | M  |  P  |    |  V  | N  |
   ClientID-Add   65589 3.7.1     Grouped   | M  |  P  |    |  V  | N  |
   ClientID-      65590 3.7.2     Grouped   | M  |  P  |    |  V  | N  |
     Delete                                 |    |     |    |     |    |
   -----------------------------------------|----+-----+----+-----|----|

5.1. AVP Auth-Service-Id

   The Auth-Service-Id AVP (AVP code 65536) is of type Unsigned32 and
   refers to an ARDP ServiceID.





Cassen                 Expires November 26, 2009               [Page 25]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


5.2. AVP Auth-Class-Id

   The Auth-Class-Id AVP (AVP code 65537) is of type Unsigned32 and
   refers to an ARDP ClassID.

5.3. AVP Auth-Client-Id

   The Auth-Client-Id AVP (AVP code 65538) is of type Unsigned32 and
   refers to an ARDP ClientID.

5.5. AVP Auth-Begin-Validity

   The Auth-End-Validity AVP (AVP code 65540) is of type Time and
   identifies begin of a validity of Access right.

5.6. AVP Auth-End-Validity

   The Auth-End-Validity AVP (AVP code 65541) is of type Time and
   identifies end of a validity of Access right.

5.7. AVP Accounting-Server

   The Accounting-Server AVP (AVP code 65542) is of type Address and
   informs to ARDP client the remote accounting server it MUST send
   recorded zapping events (join, leave).

5.8. AVP Access-Right-Add

   The Access-Right-Add AVP (AVP code 65580) is of type Grouped. It adds
   a positive access right for a ClientID to a specific ServiceID into
   ARDP Conditional Access cache. If received by NE then ClientID will
   have ability to zap and receive specified ServiceID (CP IPTV
   streaming service: multicast group) stream until its CPE.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         Access-Right-Add ::= < AVP Header: 65580 >
                              { Auth-Client-Id }
                              { Auth-Service-Id } / { Auth-Class-Id }
                              { Auth-Begin-Validity }
                              { Auth-End-Validity }
                            * [ AVP ]

   This AVP allow ARDP sending source to append optional AVPs.






Cassen                 Expires November 26, 2009               [Page 26]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


5.9. AVP Access-Right-Delete

   The Access-Right-Delete AVP (AVP code 65581) is of type Grouped. It
   removes access right for a ClientID to a specific ServiceID from ARDP
   Conditional Access cache. If received by NE then ClientID will no
   longer have ability to zap and receive specified ServiceID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         Access-Right-Delete ::= < AVP Header: 65581 >
                                 { Auth-Service-Id }
                                 { Auth-Client-Id }

5.10. AVP Accounting-Zap

   The Accounting-Zap AVP (AVP code 65582) is of type Grouped. It
   defines accounting server for zapping event accounting. Every Zap
   events for a specified ClientID to a specific ServiceID or ClassID or
   set of ServiceID/ClassID will be traced to the specified Server.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         Accounting-Zap ::= < AVP Header: 65582 >
                            { Auth-Client-Id }
                            { Accounting-Server }
                          * [{ Auth-Service-Id } / { Auth-Class-Id }]


5.11. CP ServiceID Attributes message format

   This message type refers to a unary CP service definition and apply
   to ARDP header message Type as presented in section 3.2.3.

5.12. AVP ServiceID-Add

   The ServiceID-Add AVP (AVP code 65583) is of type Grouped. It adds
   into CP namespace a ServiceID with its optional attributes.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         ServiceID-Add ::= < AVP Header: 65583 >
                           { Auth-Service-Id }
                           { Version-Code }
                           { Multicast-Group }
                         * { Unicast-Source }



Cassen                 Expires November 26, 2009               [Page 27]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


                         * { Multicast-Fallback-Group }
                         * { Unicast-Fallback-Source }
                         * { Bitrate }
                         * { Capabilities }
                         * { Service-Name }

   This AVP allow ARDP sending source to append ServiceID and optional
   AVPs.

5.13. AVP ServiceID-Delete

   The ServiceID-Delete AVP (AVP code 65584) is of type Grouped. It
   removes from CP namespace a ServiceID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         ServiceID-Add ::= < AVP Header: 65584 >
                           { Auth-Service-Id }
                           { Version-Code }

5.14. AVP Multicast-Group

   The Multicast-Group AVP (AVP code 65543) is of type Address and is
   specific to ServiceID AVPs (Add and Delete). It specifies a unique ID
   into the TV Operator namespace.

5.15. AVP Unicast-Source

   The Multicast-Group AVP (AVP code 65544) is of type Address and is
   specific to ServiceID AVPs (Add and Delete). It specifies an IPv4 IP
   address source of streaming refering to Multicast Group field. This
   is useful information when using SSM for wide-area multicast as
   described in [RFC3569].

5.16. AVP Capabilities

   The Capabilities AVP (AVP code 65548) is of type Unsigned32 and is
   specific to ServiceID AVPs (Add and Delete). It specifies ServiceID
   capabilities.

5.17. AVP Service-Name

   The Service-Name AVP (AVP code 65549) is of type UTF8String and is
   specific to ServiceID AVPs (Add and Delete). It specifies Service
   description.





Cassen                 Expires November 26, 2009               [Page 28]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


5.18. AVP Version-Code

   The Version-Code AVP (AVP code 65550) is of type Unsigned32 and is
   specific to ServiceID AVPs (Add and Delete). It specifies a version
   number to identify the service plan this Service ID belongs to.

5.19. CP ClassID Attributes message format

   This message type refers to a unary CP Class definition and apply to
   ARDP header message Type as presented in section 3.2.3.

5.20. AVP ClassID-Add

   The ServiceID-Add AVP (AVP code 65587) is of type Grouped. It adds
   into CP namespace a ClassID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         ClassID-Add ::= < AVP Header: 65587 >
                         { Auth-Class-Id }
                         { Version-Code }
                         { Auth-Service-Id }

   This AVP allow ARDP sending source to append ClassID AVPs.

5.21. AVP ClassID-Delete

   The ServiceID-Add AVP (AVP code 65588) is of type Grouped. It removes
   from CP namespace a ClassID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         ClassID-Add ::= < AVP Header: 65588 >
                         { Auth-Class-Id }

5.22. ClientID Attributes message format

   This message type refers to a unary ClientID association and apply to
   ARDP header message Type as presented in section 3.2.3.

5.23. AVP ClientID-Add

   The ClientID-Add AVP (AVP code 65589) is of type Grouped. It adds
   into CP namespace a ClientID.

   The Grouped Data field has the following ABNF grammar as in



Cassen                 Expires November 26, 2009               [Page 29]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   [RFC4234]:

         ClientID-Add ::= < AVP Header: 65589 >
                          { Auth-Client-Id }
                          { Auth-Client-Address }
                        * [ AVP ]

   This AVP allow ARDP sending source to append any optional AVPs.

5.24. AVP ClientID-Delete

   The ClientID-Delete AVP (AVP code 65590) is of type Grouped. It
   removes from CP namespace a ClientID.

   The Grouped Data field has the following ABNF grammar as in
   [RFC4234]:

         ClientID-Delete ::= < AVP Header: 65590 >
                             { Auth-Client-Id }

5.25. AVP Auth-Client-Address

   The ClientID-Delete AVP (AVP code 65539) is of type Address. It
   specifies the NE Client IP Address.

6. Unicast Protocol Part

   ARDP Unicast datagrams are used by NE ARDP Client to request ARDP NSP
   Server for right cache feeding. Those messages are using general ARDP
   protocol header presented in section 3.2. Authentication is not
   mandatory since flows are local to private ARDP Backbone from NE to
   NSP ARDP Server. Unicast messages are vehiculed over IP/TCP and are :

      - 0x01 : NE Access Right populate request
      - 0x02 : NE ClientID populate request

   NE ARDP Client fills the NE ID field with its own ID. Formerly it
   used the IPv4 IP Address provided for ARDP Backbone point of
   presence.

7. ARDP Server Operations

   The global goal of ARDP architecture is to focus protocol complexity
   onto the ARDP server instead of ARDP client. ARDP protocol reduce CPE
   complexity by deporting conditional access to aggregation equipment.
   The same statement is used for ARDP Server. It is responsible for
   ARDP protocol messages flooding and scheduled flooding jobs. In this
   many-to-many networking scheme it is convenient to centralize



Cassen                 Expires November 26, 2009               [Page 30]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


   complexity onto the server side for maintenance and scalability
   reasons.

   ARDP Server MUST perform the following operations :

      - MUST permanently flood CP Service ID plane. If new
        Service ID plane is flooded then send all Access Right
        (of this CP).

      - If ARDP server is NSP ARDP Server then:

        o Only accept Unicast requests from NE ARDP Client

        o Only send Unicast request to remote CP ARDP Server

        Else

        o Only accept unicast requests from NSP ARDP Server

        Endif

      - MUST periodically flood whole Access Right

      - MUST flood ClientID before any Access Right related to this
        ClientID.

      - MUST monotonically increment sequences counters for every
        message type while sending ARDP datagrams.

8. NE ARDP Client Operations

   ARDP Client side manages local access right cache. Its finite state machine
   is divided into 2 states as follows :

   +------------------+                         +------------------+
   |                  |------------------------>|                  |
   |    Initialize    |                         |     Learning     |
   |                  |<------------------------|                  |
   +------------------+                         +------------------+

8.1. Initialize State

   The purpose of this state is to boot up ARDP protocol. While in this
   state, ARDP client MUST perform the following operations :

      - If Authentication is used then MUST load CP secrets
        for HMAC-MD5-96bit authentication or load RSA public key if
        RSA authentication is used. In addition it load CP secrets



Cassen                 Expires November 26, 2009               [Page 31]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


        for AVPs AES encryption.

      - MUST wait until CP Service IDs are received. While receiving
        Service IDs update local ServiceID sequence counter.

      - MUST wait until CP Class IDs are received. While receiving
        Class IDs update local ClassID sequence counter.

      - MUST connect to NSP ARDP Server only to request for
        ClientID flooding.

      - If ClientID table is empty then:

        o Re-schedule a new ClientID flooding request to
          NSP ARDP Server.

        o If ClientID table still empty until max_retry then:
          . Disable scheduling ClientID flooding retry.
          . Re-schedule a new ClientID request with a longer
            delay
          Endif

        Else

        o Schedule Access Right flooding request to NSP ARDP Server.

        Endif

      - If Access Right Table is empty then:

        o Re-schedule a new Access Right flooding request to
          NSP ARDP Server.

        o If Access Right table still empty until max_retry then:
          . Disable scheduling Access Right flooding retry.
          . Re-schedule a new Access Right request with a longer
            delay
          Endif

        Else

        o Transit to Learning state.

        Endif

   In this pseudo code we can note that "Re-schedule" can mean inhibit
   flooding request since NSP ARDP Server can schedule any request since
   it has the knowledge of the whole ARDP Backbone point of presence.



Cassen                 Expires November 26, 2009               [Page 32]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


8.2. Learning State

   The purpose of this state is to enter a long time listening stage.
   While in this state, ARDP client MUST perform the following
   operations :

      - If Authentication is used then MUST drop any datagram
        received with a lower sequence number than currently
        stored sequence counter related to incoming ARDP
        message type.

      - When receiving ARDP datagram then MUST update local ARDP message
        type sequence counter with ARDP header sequence number field.

      - When receiving ClientID message, if ClientID is refering to a
        local NE IP Address then store this new correspondance.

      - When receiving ClientID message then MUST remove any Access
        Right associated if already exists.

      - When receiving Access Right message then MUST replace any Access
        Right related to the same ClientID/ServiceID.

      - When receiving new ServiceID, means when "Version Code" field is
        different from current ARDP Client Service version code then
        remove any Access Right related to the CP source of the message.

      - If Access Right Table is empty then:

        o Transit to Initialize state.

        Endif

      - When NE ARDP stack is looking for Access Right or TimeSlot
        in Access Right cache as describe in section 2.1, it MUST
        expire CP Access Right and CP Free Access TimeSlot according
        to Validity learnt during ARDP message flooding as presented in
        section 3.3.5/3.3.6 for CP Access Right and 3.7.3/3.7.4 for
        CP Free Access TimeSlot. If Access Right or Free Access TimeSlot
        has expired, then it is removed from local Access Right cache.











Cassen                 Expires November 26, 2009               [Page 33]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


9. Sending and receiving ARDP datagram

9.1. Sending

   Any ARDP sending source MUST perform the following operations:

      - MUST fill ARDP protocol header in accordance with protocol
        specification in section 3.

      - If Authentication is used then sign ARDP datagram.

      - If E-flag is set then encrypt ARDP AVPs.

9.2. Receiving

   Any ARDP received datagram MUST perform the following operations:

      - MUST perform sanity check over datagram to conform ARDP header
        elements with real data content.

      - If Authentication is used then:

        o MUST verify HMAC-MD5-96bit or RSA signature. If signature
          is not valid then:

          . Drop incoming datagram.

          Endif

        Endif

      - If E-flag is set then:

        o MUST Decrypt AVPs.

        Endif

10. Acknowledgments

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).










Cassen                 Expires November 26, 2009               [Page 34]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


11. References

   [HMAC]    Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", Work in Progress.

   [AES]     NIST, FIPS PUB 197, "Advanced Encryption Standard
             (AES)," November 2001.
             http://csrc.nist.gov/publications/fips/fips197/
             fips-197.{ps,pdf}

   [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing
             for Message Authentication", RFC 2104, February 1997.

   [RFC2437] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography
             Specifications Version 2.0", RFC 2437, October 1998.

   [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko
             "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC4234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, October 2005.

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

   [RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
             Multicast (SSM)", RFC 3569, July 2003.

   [RFC2326] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming
             Protocol (RTSP)", RFC 2326, April 1998.

   [SIPRTSP] X. Marjou, J. Lindquist, P. Rajagopal, M. Said, S. Ganesan
             "Session Description Protocol (SDP) Offer/Answer Model For
             Media Control Protocol", Internet Draft.

   [AAA]     Hiroaki Satou, Hiroshi Ohta, Christian Jacquenet,
             Tsunemasa Hayashi, Haixiang He,
             "AAA Framework for Multicasting", Internet Draft.












Cassen                 Expires November 26, 2009               [Page 35]

Internet-Draft     Access Right Distribution Protocol(ARDP)     May 2009


12. Authors' Address

   Alexandre Cassen
   Freebox S.A.
   8, Rue de la Ville l Eveque
   75008 Paris
   FR

   EMail: acassen@freebox.fr










































Cassen                 Expires November 26, 2009               [Page 36]


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