idnits 2.17.1 draft-cassen-access-right-distribution-protocol-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 9 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 239: '...lity reasons NSP MUST protect/hide its...' RFC 2119 keyword, line 488: '... protocol. SUBSP MUST be a protocol of...' RFC 2119 keyword, line 676: '...y CP back-office MUST and NEED to send...' RFC 2119 keyword, line 679: '... : Any CP ARDP Server MUST send Access...' RFC 2119 keyword, line 1000: '... whether the AVP MAY be encrypted. For...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2009) is 5449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RMT' is mentioned on line 773, but not defined == Unused Reference: 'HMAC' is defined on line 1484, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2437 (Obsoleted by RFC 3447) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Alexandre Cassen 3 Internet-Draft Freebox S.A. 4 Intended status: Informational May 25, 2009 5 Expires: November 26, 2009 7 Access Right Distribution Protocol (ARDP) 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a protocol using multicast to securely 47 distribute IPTV management elements such as IPTV customer's access 48 rights. The protocol typically runs on any piece of equipments to 49 locally store owned customers IPTV service access right. This design 50 provides access control at aggregation level. 52 Table of Contents 54 1. Introduction .............................................. 4 55 1.1. Scope ................................................. 5 56 1.2. Definitions ........................................... 5 57 2. ARDP framework ............................................ 7 58 2.1. NSP/CP Hierarchy ...................................... 7 59 2.2. Using Multicast to convey ARDP datagrams .............. 7 60 2.3. An ID and attributes oriented protocol ................ 8 61 2.4. CP Service Plane ...................................... 8 62 2.5. ClientID ............................................. 10 63 2.6. Conditional Access Right ............................. 10 64 2.7. Attributes inheritance ............................... 11 65 3. ARDP Architecture ........................................ 11 66 3.1. Interface with NE routing stack ...................... 13 67 3.2. Adaptive zapping ..................................... 14 68 3.3. Confidentiality and security considerations .......... 15 69 3.4. NSP ARDP Server ...................................... 16 70 3.5. CP ARDP Server ....................................... 17 71 3.6. NE ARDP Client ....................................... 17 72 3.7. NSP ARDP Report ...................................... 18 73 3.8. NSP ARDP Accounting .................................. 18 74 3.9. Make it reliable ! ................................... 19 75 3.10. ARDP stream bitrate ? ............................... 20 76 3.11. Global Operation workflow ........................... 20 77 4. Multicast Protocol Part .................................. 21 78 4.1. IP/UDP packet field descriptions ..................... 21 79 4.2. ARDP header Packet Format ............................ 21 80 4.3. ARDP AVP Packet Format ............................... 24 81 5. ARDP Base Protocol AVPs .................................. 24 82 6. Unicast Protocol Part .................................... 30 83 7. ARDP Server Operations ................................... 30 84 8. NE ARDP Client Operations ................................ 31 85 8.1. Initialize State ..................................... 31 86 8.2. Learning State ....................................... 33 87 9. Sending and receiving ARDP datagram ...................... 34 88 9.1. Sending .............................................. 34 89 9.2. Receiving ............................................ 34 90 10. Acknowledgments ......................................... 34 91 11. References ............................................... 35 92 12. Authors' Address ......................................... 36 94 1. Introduction 96 Standard digital TV security models are based on smartcard 97 intelligence at the end user CPE side. We will not present global 98 goal and design of Conditional Access System since this is not the 99 scope of this document. We can simply remind that digital pay TV is 100 based on such a system where EMM (Entitlement Management Message), an 101 encrypted message, provides private conditional access information 102 concerning the broadcast services one viewer is allowed to receive. 103 The challenge of such an architecture is to provide strong 104 cryptographic systems to protect EMM messages against piracy since 105 EMM are stored directly into the CPE/smartcard. If this system can be 106 considered as good for regular broadcasting design where no upstream 107 (on CPE side) is available, this design can be enhanced on network 108 (xDSL, FTTx) offering upstream feedback channel. 110 The very first security consideration rely more on trust aggregation 111 network or any routing equipements and reduce end user CPE 112 intelligence/complexity. Networking architecture provides a way to 113 dissociate Conditionnal Acces and video content protection. While 114 stream can still use standard DVB-CSA scrambling design, EMM 115 equivalent can be stored into aggregation equipment. CPE is 116 considered as no trust equipement and the idea is to reduce to the 117 max the action it may have. CPE intelligence and operations on 118 security side can be emulated which open the door to reverse 119 engineering. For services like IPTV, this design offers a secure 120 conditional access design by physically dissociating both security 121 components. Stream access is controled during stream subscribtion 122 stage. The CPE simply requests for a video stream and the aggregation 123 equipment grants or not access according to its local access database 124 (local access right cache). 126 The challenge for now is to find a secure and scalable way to 127 populate aggregation equipments access database. We can be inspired 128 from the broadcasting model by using multicast transmission to 129 distribute access rights over a network backbone. The following 130 document will present a protocol used on top of IP to securely 131 distribute those access rights. 133 1.1 Scope 135 The remainder of this document describes the features, design goals, 136 and theory of operation of Access Right Distribution Protocol - The 137 message format, protocol processing rules and state machine that 138 guarantee safe and secure operations. 140 1.2 Definitions 142 In this document we will use same Definitions/Abbreviations as 143 present in [AAA] document. 145 ChannelID An abstraction modelizing a CP pieces of 146 informations identifying a CP IPTV streaming 147 service (multicast group and any other 148 low-level related attributes). 150 ServiceID An abstraction modelizing a CP pieces of 151 informations identifying a CP IPTV set of 152 ChannelID. 154 ClassID An abstraction modelizing a CP pieces of 155 informations identifying a CP IPTV set of 156 ServiceID. 158 Service Plane An abstraction modelizing the CP set of 159 ClassID / ServiceID. 161 ClientID An abstraction modelizing association between 162 customer Identification number and physical 163 IP address (or MAC address or phone number). 164 Each IP address (or MAC or phone number) can 165 have multiple ClientID, each one is unique to 166 each CP namespace. 168 Access Right An abstraction modelizing a customer 169 conditional access on a specific ServiceID or 170 ClassID. It determines whether or not a 171 ClientID 172 can access a specific ServiceID or ClassID. 174 CP Content Provider is in charge of multicast 175 content streaming. Each CP is also in charge 176 of distributing Service Plane, ClientID, 177 Access Right over ARDP backbone. 179 ARDP Backbone A Wide Area Network made of lot of ARDP 180 clients. 182 NSP Network Service Provider owns ARDP Backbone 183 and is in charge of any administration related 184 operations over it. 186 NE Network Equipment is runing an ARDP Client and 187 is storing Access Right. It controls and 188 maintains multicast subscription. 190 ARDP Client A Software component running ARDP protocol on 191 network aggregation routing equipments. It is 192 responsible for NE local right cache 193 management and is interacting with NSP ARDP 194 Server. It stores all CP Service Plane, 195 ClientID, associated security elements (RSA 196 public key) and customer Access Right. 198 CP ARDP Server Each CP stores an RSA keypair and uses RSA 199 private key to sign all ARDP protocol 200 datagrams sent to ARDP Backbone. The RSA 201 public key is exported to all NE ARDP Clients. 202 It manages Service Plane and Access Right 203 flooding. 205 NSP ARDP Server A server running ARDP protocol and acting as 206 root authority. This server distributes 207 ClientID over ARDP backbone and forwards ARDP 208 requests to CP ARDP servers. 210 ARDP Session A connection issued by NSP ARDP Server to 211 CP ARDP Server to request Access Right 212 flooding for a set of CP ClientID. 214 NSP Accounting Srv A server listening and handling any 215 accounting reports sent by NE. 217 NSP Report Srv A server acting as a proxy between 218 NE and Back-office management systems. 219 Use to fetch/verify Access Right 220 bound to a specific ClientID. 222 CDS Content Delivery Services. 224 CPE Customer Premise Equipment. 226 2. ARDP framework 228 ARDP provides secure, scalable and reliable facilities to distribute 229 IPTV management elements. Those elements are : 231 . CP Service Plane (ClassID/ServiceID) 232 . ClientID 233 . Access Right 235 2.1. NSP/CP Hierarchy 237 ARDP design tend to create a hierarchy between NSP and CP. NSP trust 238 CP with point of presence in its ARDP Backbone, but for 239 security/maintenability reasons NSP MUST protect/hide its low-level 240 topology. NSP is in charge with administration and operations all 241 over its backbone, each NE can change/migrate to a different routing 242 plane, each customer can roam from NE to NE and consequently change 243 their routing related elements and path (change of IP address for 244 example). 246 NSP is responsible for keeping accurate association between ClientID 247 and IP Address in all CP namespace. 249 CP operations are CDS centralized, it manages informations needed to 250 run its business : ServiceID/ClassID/Access Right. 252 2.2. Using Multicast to convey ARDP datagrams 254 ARDP is running over multicast. ARDP Servers are a only multicast 255 sending source while NE ARDP Client are a only multicast receiver. 257 Every CP are network low-level topology agnostic, using multicast 258 provides a simple and scalable answer to offer a full and realtime 259 distribution of Access Right to each CP. 261 IPTV makes extensive use of multicast, using multicast for ARDP and 262 localizing it into same networking plane as other regular streamed 263 contents will provide an accurate feedback on multicast reliability 264 until NE. As presented in section 4.5, ARDP architecture defines an 265 accounting server used to handle ARDP protocol reliability, any 266 trouble occuring on ARDP multicast flow can be extrapolated to other 267 multicast flows into the same networking plane. 269 Finally, using multicast as distribution vector offers to ARDP 270 protocol a very short convergence time since one change will be 271 learnt and affect every NE at a time. For example, changing any 272 Service Plane piece of informations (multicast group, ...) will be 273 quite realtime. 275 2.3. An ID and attributes oriented protocol 277 ARDP is network topology agnostic by making extensive use of ID for 278 addressing every low-level elements. IDs are key-elements just like 279 those found in DVB satellite architecture. Using IDs create an 280 abstraction between managed and target elements leading to a very 281 short (optimum) convergence time needed while updating those target 282 elements. 284 CP Service Plane is the ARDP fundation element. Every CP are 285 permanently flooding over ARDP backbone all of their ServiceID and 286 ClassID elements. On its own, NSP is flooding ClientID elements. 287 Service Plane and ClientID open the road to CP Access Right flooding, 288 in other words: setting an Access Right for a ServiceID or ClassID to 289 a target ClientID. An Access Right is thus a binding between a 290 ClientID and a ServiceID or a ClassID. 292 The others ARDP key-elements are attributes. Every IDs are filled 293 with a set of attributes like presented in section 4.3.1. ServiceID, 294 ClassID, ClientID are a set of attributes. 296 Creating ID abstraction provides flexibility while managing 297 attributes. Attributes values updates (over ClassID, ServiceID, 298 ClientID, ....) will not impact any ARDP operations since Access 299 Right binding is made on ID. 301 2.4. CP Service Plane 303 Service Plane is managed by a CP, it defines low-level elements CP 304 will use to run its business. A Service Plane is thus a set of 305 ServiceID and ClassID learnt by NE ARDP Client. Service Plane brings 306 an important flexibility for CP since it can change any elements in 307 quite realtime. It provides functional flexibility like defining 308 playlist based ServiceID, adaptive zapping, ... 310 2.4.1. ServiceID 312 A ServiceID is compounded by a set of ChannelID and is unique in CP 313 ARDP namespace. Its management representation is an ID and is filled 314 using the following ABNF notation as in [RFC4234]: 316 ServiceID ::= { Auth-Service-Id } 317 * [ AVP ] 318 { Service-Profile } 319 [ Channel-Id [ AVP ] ] 320 { Service-Profile-fallback } 321 [ Channel-Id [ AVP ] ] 323 Detailed AVPs declaration and specifications can be found in section 324 5. 326 A live IPv4 only example can be : 328 SvcID | Service Attributes 329 ---------+--------------------------------------- 330 201 | . Service Name : IETF IPTV Room1 331 | . PC Redirect : 1 332 | . Number of Decoder : 2 333 | . Accounting-Zap : 192.168.200.10 334 | . Profile : 335 | . ChannelID : 419 336 | . Service Name : IETF IPTV HD 337 | . Multicast Group : 239.1.2.3 338 | . Unicast Source : 192.168.200.1 339 | . Capabilities : 0x0002 340 | . Bitrate : 5500 341 | . ChannelID : 32 342 | . Service Name : IETF IPTV SD 343 | . Multicast Group : 239.1.2.4 344 | . Unicast Source : 192.168.200.2 345 | . Capabilities : 0x0004 346 | . Bitrate : 3600 347 | . ChannelID : 347 348 | . Service Name : IETF IPTV H264 349 | . Multicast Group : 239.1.2.5 350 | . Unicast Source : 192.168.200.3 351 | . Capabilities : 0x0008 352 | . Bitrate : 2000 353 | . Profile Fallback : 354 | . ChannelID : 519 355 | . Service Name : IETF FB HD 356 | . Multicast Group : 239.1.2.6 357 | . Unicast Source : 192.168.200.4 358 | . Capabilities : 0x0002 359 | . Bitrate : 5500 360 | . ChannelID : 132 361 | . Service Name : IETF FB SD 362 | . Multicast Group : 239.1.2.7 363 | . Unicast Source : 192.168.200.5 364 | . Capabilities : 0x0004 365 | . Bitrate : 3600 366 | . ChannelID : 447 367 | . Service Name : IETF FB H264 368 | . Multicast Group : 239.1.2.8 369 | . Unicast Source : 192.168.200.6 370 | . Capabilities : 0x0008 371 | . Bitrate : 2000 373 In this example ServiceID 201 defines "IETF IPTV Room1" service. 375 2.4.2. ClassID 377 A ClassID is managed by a CP, it defines a set of ServiceID and is 378 filled using the following ABNF notation as in [RFC4234]: 380 ClassID ::= { Auth-Class-Id } 381 * [ AVP ] 382 [ Auth-Service-Id ] 384 A live example can be : 386 ClassID | Class Attributes 387 ---------+--------------------------------------- 388 74 | . Class Name : IETF IPTV Area 389 | . Number of Decoder : 3 390 | . Service : 391 | 201 202 203 204 205 206 207 208 393 2.5. ClientID 395 A ClientID defines an NSP low-level binding between Client networking 396 informations and its ARDP representation. A ClientID is filled using 397 the following ABNF notation as in [RFC4234]: 399 ClientID ::= { Auth-Client-Id } 400 * [ AVP ] 402 A live IPv4 only example can be : 404 ClientID | Client Attributes 405 ----------+--------------------------------------- 406 100 | . IP-Address : 10.1.1.1 407 | . Number of Decoder : 5 408 | . Accounting-Zap : 192.168.200.150 410 2.6. Conditional Access Right 412 A conditional Access Right defines a binding between 413 (ClientID,ServiceID) or (ClientID,ClassID). CP is setting those 414 bindings for every ClientID it manages. If a Client is subscribing to 415 a marketing offer modelized in ARDP by ClassID 74 then CP simply send 416 an ARDP datagram to set/create this binding. 418 2.7. Attributes inheritance 420 ARDP provides attributes inheritance design between every element it 421 manages. Inheritance tree is : 423 ServiceID 424 ^ 425 | 426 ClassID 427 ^ 428 | 429 ClientID 431 ServiceID is surcharging ClassID attributes surcharging ClientID 432 attributes. 434 If we use the live example presented in previous sections, "Number of 435 Decoder" attributes will finally have the value of 2. 437 3. ARDP Architecture 439 We can localize each ARDP architecture component on the following 440 diagram : 442 +-----------+ +-----------+ 443 | | | | 444 __________| CP ARDP 1 |________| CP ARDP 2 |________________ 445 / | | | | \ 446 / +-----------+ +-----------+ \ 447 | | 448 | ARDP Backbone | 449 | | 450 \ +-------+ +------+ +------+ +------+ / 451 \__| NSP |_______________| NE 1 |___| NE 2 |..| NE n |_____/ 452 | ARDP | +------+ +------+ +------+ 453 +-------+ ^ ^ ^ ^ 454 ................ . . . 455 . . . . 456 +--------- v + +---------- v + . . 457 | NSP ARDP | | NSP ARDP |<...... . 458 | Accounting | | Report |<............... 459 +------------+ +-------------+ 461 NSP ARDP : NSP ARDP Server 462 CP ARDP 1 : CP 1 running CP 1 ARDP Server 463 CP ARDP 2 : CP 2 running CP 2 ARDP Server 464 NE 1 : NE 1 running NE 1 ARDP Client 465 NE 2 : NE 2 running NE 2 ARDP Client 466 NE n : NE n running NE n ARDP Client 467 NSP ARDP Accounting : NSP Accounting Server 468 NSP ARDP Report : NSP Back-Office Report Server 470 All customer ClientID are flooded from NSP ARDP Server. All customer 471 Access Right are flooded from CP ARDP Server. Every CP ARDP Server 472 are flooding Service Plane and Access Right for ServiceID/ClassID 473 they manage. NE ARDP Client is then filtering received multicast 474 datagrams to only store Access Right, for customers it hosts 475 (ClientID). 477 ARDP finality is then to maintain Access Right cache integrity on NE 478 ARDP Client side and to offer any CP the ability to flood directly 479 Service Plane and Access Right over ARDP Backbone. 481 3.1. Interface with NE routing stack 483 In IPTV architectures, stream subscription is most of the time done 484 through IGMP (as described in [RFC3376]) since streaming is done via 485 multicast. In IGMP there is a lake of feedback while performing JOIN 486 or LEAVE operation, in this document we will not use IGMP as 487 subscription protocol, we will rather use SUBSP acronym to identify 488 this subscription protocol. SUBSP MUST be a protocol offering 489 feedback/error reporting and using transactionnal design to benefit 490 any ARDP features and flexibilities. SUBSP can be : 492 - RTSP as described in [RFC2326] 493 - SIP/RTSP as descibed in [SIPRTSP] 495 ARDP operates close to aggregation equipment stack at subscription 496 protocol level. The diagram below shows general ARDP operations : 498 +--------------------------------------------------------+ 499 | NE Routing Software | 500 | +--------------------+ | 501 | | ARDP | | 502 | | Information Base | | 503 | +------------------------+ +----------^---------+ | 504 | | CORE Routing Stack | | | 505 | | +-------+ +------v-----+ | 506 | | | SUBSP |<------>| ARDP Stack | | 507 | +----------------+---^---+ +------------+ | 508 +------------------------|-------------------------------+ 509 | 510 | 511 +------v------+ 512 | CPE | 513 +-------------+ 515 When CPE requests for a ServiceID, it generates an Access Request 516 caught by NE routing stack. Before processing the subscription 517 operation, SUBSP stack requests authorisation to ARDP Stack. If 518 access is granted by ARDP then SUBSP stack proceeds to perform stream 519 subscription and any routing related task. SUBSP is thus sending 520 Access Request to ARDP Stack. 522 Authentication workflow between CPE and NE Routing Software is 523 defined as : 525 +------+ +-------+ +------+ 526 | CPE | | SUBSP | | ARDP | 527 +------+ +-------+ +------+ 528 | | | 529 | JOIN / LEAVE | | 530 |-------------------->| Access-Request | 531 | |-------------------->| 532 | | | 533 | | Access-Response | 534 | |<--------------------| 535 | ACK / NAK | (DENY / ACCEPT) | 536 |<--------------------| | 537 | | | 539 Using ABNF notation as in [RFC4234] SUBSP Access-Request and Access- 540 Response can be specified as : 542 Access-Request ::= { Namespace } 543 { Auth-Client-Id / IP-Address } 544 { Auth-Service-Id } 546 Access-Response ::= { DENY / ACCEPT } 547 [ Channel-Id [ AVP ] ] 549 While handling Access-Response ARDP stack will append ServiceID's 550 Profile or Profile Fallback rather it is an ACCEPT or a DENY. 552 3.2. Adaptive zapping 554 An important feature provided by ARDP Service Plane is to offer 555 adaptive zapping. As described in section 3.1 customer zapping in 556 translated into sending an Access Request to ARDP for a specific 557 ServiceID. As described in section 2.4.1, ServiceID is a set of 558 ChannelID filled with a set of attributes. While performing 559 conditionnal Access Right operations, NE routing software can 560 adaptively select a ChannelID based on attribute matching. 562 A specific use case of this feature is to select a ChannelID based on 563 bitrate attribute value so that zapping will be dynamic/adaptive 564 according to available bandwitdh between CPE and NE. If a CPE is 565 feeded with multiple streams at a time then this mecanism can 566 optimize bandwidth usage. 568 3.3. Confidentiality and security considerations 570 First of all, ARDP operates in a separate/dedicated network plane 571 without any physical link with the CPE network. It is mandatory to 572 separate the ARDP network plane from the CPE network plane. Only 573 aggregation equipment can access the ARDP plane and CPE plane; 574 however no routings or forwardings rules may exist between the two 575 planes. 577 ARDP protocol is disigned to operate in a multi-operator fashion. 578 From the networking point of view it is running multiple multicast 579 sending sources at a time. One of the goals of the protocol is to 580 give CP full control of Service Plane and Access Right for running 581 its business. NSP provides a Namespace and a point of presence in 582 ARDP backbone to each CP. Using ARDP, a CP can manage Service Plane 583 and Access Right through head-end in realtime using flexibility of 584 multicast. 586 ARDP architecture defines a hierarchy between NSP and CP. On the one 587 hand NSP, formerly an IPTV operator owning network infrastructure, 588 has a role of arbitration and root authority : 590 - Distributes all CP ClientID over ARDP Backbone. Each CP 591 has its own namespace for ClientID but the association 592 between a CP ClientID and a physical client (customer) 593 identification (IP address, MAC address, phone number, ...) is 594 only known by NSP. 596 - Requests CP ARDP Server to distribute Access Right to 597 a particular ClientID. 599 On the other hand, CP is a supervisor authority for distributing ARDP 600 Service Plane and Access Right it manages : 602 - Handles NSP ClientID request by flooding in response 603 the associated ARDP Access Right. 605 - Permanently flood Service Plane. 607 A RSA signature is used to guaranty protocol datagram authenticity 608 and integrity using a RSA keypair. Each ARDP Server stores its RSA 609 private key and CP ARDP Client stores all RSA exported public key. A 610 Public Key Infrastructure can be used to distribute RSA pubkey, we 611 will not detail this part since it is out of the scope of this 612 document. 614 On the other hand ARDP is using sequence numbers in every datagram 615 and generated at server side which prevent against any kind of replay 616 attack. ARDP protocol replay attack is not intrinsec possible since 617 ARDP message contains validity range. If a malicious source try to 618 replay any previously recorded datagrams, the final effect will just 619 be a forced update at NE side, that will end on a no effect 620 injection. The benefit brought by sequence number, when used with 621 authenticated datagrams (HMAC-MD5-96bit or RSA), resides in the key 622 decision it provides to drop any incoming malicious datagram and thus 623 prevent against any time consuming task induced by datagram handling. 624 In addition ARDP AVPs can be encrypted. 626 3.4 NSP ARDP Server 628 The main goal of this server is to distribute CP ClientID over ARDP 629 backbone and issue ARDP Sessions with CP ARDP Server. Main functional 630 elements blocks can be represented as following : 632 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633 . . 634 . . 635 . . 636 | ARDP Backbone | 637 | | 638 | | 639 | +-----------+ ^(MCAST) | 640 \ | | . +------+ +------+ +------+ / 641 \___| CP ARDP |______._______| NE 1 |___| NE 2 |..| NE n |__/ 642 | | . +------+ +------+ +------+ 643 +-----------+ . . . 644 ^ . . (TCP) .(TCP) 645 .(TCP) . ............. .... 646 . . . . 647 +----- . --------------- . -------------- v -- v -------+ 648 | +--------------+ +----------------+ +-------------+ | 649 | | ARDP Session | | ClientID Flood | | NE Listener | | 650 | +--------------+ +----------------+ +-------------+ | 651 | +------------------+ | 652 | | Subscribers's DB | | 653 | | Interface | | 654 | NSP ARDP Server +------------------+ | 655 +-------------------------------------------------------+ 657 NSP ARDP Server fonctionnalities are : 659 - ARDP Session : Peering, using TCP, ClientID to CP ARDP Server 660 to request CP Access Right flooding accordingly. 662 - ClientID Flooding : Flooding, using multicast, ClientID of every 663 CP. 665 - NE Listener : Listening, on TCP, to any NE flooding requests. 667 - Subscriber's DB Interface : It is closely linked to subscriber's 668 database to fetch accurate informations 669 for ClientID flooding and Session 670 with every CP ARDP Servers. 672 3.5 CP ARDP Server 674 This server is managed by CP and operates two major tasks: 676 - Autonomous ARDP flooding : Any CP back-office MUST and NEED to send 677 Access Right whenever it is needed. 679 - Sollicited ARDP flooding : Any CP ARDP Server MUST send Access 680 Right over ARDP Backbone upon NSP ARP Server request received by ARDP 681 session. 683 3.6 NE ARDP Client 685 Is running on NE and is managing NE ARDP information base. Main 686 functional elements blocks can be represented as following : 688 . . . . . . . . . . . . . . . . . . . . . . . . . . . 689 . . 690 . . 691 | ARDP Backbone | 692 | | 693 \ +------+ +------+ / 694 \___| CP |_| NSP |________________________________.______/ 695 | ARDP | | ARDP |<.................. . 696 +------+ +------+ . . 697 . . 698 +-------------+ +--------------- . ----------- . ------+ 699 | NSP ARDP | | +----------+ +-.----+ +----v-----+ | 700 | Report |<........>| Report | | NSP | | MCAST | | 701 +-------------+ | | Listener | | Req. | | Listener | | 702 | +----------+ +------+ +----------+ | 703 +-------------+ | | 704 | NSP ARDP | | +------------+ +------------------+ | 705 | Accounting |<.........| Accounting | | Routing Software | | 706 +-------------+ | | Notifier | | Interface | | 707 | +------------+ +------------------+ | 708 | | 709 | NE ARDP Client | 710 +--------------------------------------+ 712 NE ARDP Client fonctionnalities are : 714 - MCAST Listener : Multicast listener handling incoming ARDP 715 datagram received from ARDP Backbone. 717 - NSP Requester : Send ARDP flooding request to NSP ARDP Server. 718 ARDP ClientID and Access Right flooding requests. 720 - Routing Software interface : A TCP listener handling Access-Request 721 coming from SUBSP (as presented in 722 section 3.1.) 724 - Report Listener : A TCP listener, listening to NSP ARDP Report 725 server Access Right fetching request. 727 - Accounting notifier : Periodically notify, using TCP, NSP 728 Accounting 729 Server to internal informations and states. 731 3.7 NSP ARDP Report 733 The main goal of this server is to provide an interface to customer's 734 management back-office in order to fetch ClientID Access Right 735 bindings and thus providing an accurate feedback on internal ARDP NE 736 storage. For exemple it can provides facilities to customer's hotline 737 in order to verify customer Access Right. 739 3.8 NSP ARDP Accounting 741 The main goal of this server is to provide ARDP protocol accounting 742 facilities. NE ARDP Client push periodically internal informations to 743 this central node. This accounting server offers a centralized 744 consolidation point. NE ARDP Client can push informations like : 746 - ARDP Stream discontinuity. 747 - Customer zapping request rate. 748 - ServiceID zap auditing. 749 - ... 751 In this document we will not detail protocol framing used to push 752 accounting informations to NSP ARDP Accounting server, but it is 753 mainly using the ARDP protocol header with ARDP AVPs append. 755 Due to its push design fashion, NE ARDP Client needs to add a skew 756 factor to its internal timer pushing informations to workaroung any 757 flooding side-effect. IPTV customer's uses are impulsive and 758 periodical, pushing timer needs to be short in order to consider and 759 consolidate accurate informations. 761 3.9 Make it reliable ! 763 ARDP is using multicast to distribute protocol datagrams. The main 764 constraint using multicast is to make it reliable since it is not 765 connected. Any datagram can be lost in transit especially when 766 running on a very large network. There is multiple way found into 767 litterature to handle reliability of multicast stream. 769 The very first design is to retransmit lost sequences. As presented 770 in section 4.2.7, ARDP datagrams are sequenced so that ARDP Client 771 can learn how many ARDP datagrams have been lost and request for 772 retransmission. Retransmission can also be operated by agnostic 773 protocol like presented into [RMT] IETF Working Group. The main side 774 effect of such an architecture is to lead to massive restransmission 775 flooding. Actually, on large operator network it is most likely any 776 operationnal actions on routings or network equipments will lead to 777 lost datagram into network regions where operations took place. It 778 can be extrapolated to a massive retransmission request if drops are 779 localized close to multicast streaming source. This design can be 780 considered for multicast stream where lost of datagram is critical 781 and irreversible, if lost datagram can be recomputed and 782 retransmitted later on then we can investigate others alternatives 783 offering flexibility of delayed operations. 785 An alternative to previous design would be to completely ignore lost 786 datagrams and, instead, periodically flood global ARDP protocol 787 informations (ClientID + Access Right). The main advantage with this 788 approach is its simplicity but its cost resides in flooding time 789 increase accordingly to number of ARDP datagram to be sent. On one 790 hand we have the flexibility of delayed operations, on the other hand 791 we increase convergence time and impact scalability. 793 Another alternative would be to mix both approaches. NE ARDP Client 794 is periodically pushing back to NSP ARDP Accounting Server protocol 795 stream discontinuity so that if NSP ARDP Server is notified 796 accordingly it can flood back to NE any ARDP protocol related 797 informations (ClientID + Access Right). NSP ARDP Server can 798 selectively flood ARDP protocol informations by NE. This approch will 799 scale and provide flexibility of mass flooding. This document will 800 prefer this approach. 802 3.10. ARDP stream bitrate ? 804 ARDP is a multicast streamed protocol so that its bitrate will 805 directly impact receiving processing, even more since it is using 806 crypto. Controlling ARDP sending source will control any NE ARDP 807 Client time computing ressources. Making ARDP stream Constant BitRate 808 will transitively induce a maximum time computing threshold tweakable 809 at sending source. 811 3.11. Global Operation workflow 813 The following diagram gives the general workflow of ARDP protocol. 815 +-----------+ +-----------+ 816 | | | | 817 __________| CP ARDP 1 |________| CP ARDP 2 |________________ 818 / +---->| | | | \ 819 / | +-----------+ +-----------+ \ 820 | | \ | 821 | | \(d) | 822 | | \ | 823 | |(c) ^ v ARDP Backbone | 824 | | / | 825 | | /(b) | 826 | | / | 827 \ +-------+ +------+ +------+ +------+ / 828 \__| NSP |______________| NE 1 |___| NE 2 |..| NE n |______/ 829 | ARDP | +------+ +------+ +------+ 830 +---^---+ | 831 +----------------------+ 832 (a) 834 This sample configuration illustrates ARDP operation workflow from ARDP 835 protocol boot-up state (a) through ClientID and Access Right flooding stage 836 (b), (c) and (d). Protocol operates at both Multicast and 837 Unicast levels such as follows : 839 (a) Unicast message : NE 1 informs NSP ARDP Server of its 840 initialization state. It requests for ClientID and right 841 flooding. 843 (b) Multicast message : NSP ARDP Server floods ClientID for each 844 customer hosted by NE 1 in each CP ClientID namespace. 846 (c) Unicast message : NSP ARDP Server requests Access Right flooding 847 to each remote CP ARDP Server for given ClientID in each 848 CP ClientID namespace. 850 (d) Multicast message : In response to (c) each CP ARDP Server 851 floods Access Right requested by NSP ARDP Server. 853 4. Multicast Protocol Part 855 ARDP protocol operates at multicast level and runs over UDP. 856 ARDP packet are encapsulated in IP/UDP packets and sent to a 857 routed multicast IPv4 address over ARDP Backbone. Multicast offers 858 a many-to-many entities discussion. Using UDP encapsulation offers 859 the ability to run multiple ARDP plane using the same multicast 860 routing ressource. 862 4.1. IP/UDP packet field descriptions 864 For the current ARDP version 1 there is no layer3/4 restrictions. 865 Multicast TTL must be set with a proper value permitting 866 backbone traversal. 868 4.2. ARDP header packet format 870 Each ARDP protocoal datagram starts with ARDP header as follows. 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Ver | Hl | Msg Type | Size | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Count Msg |E| Auth Type | Sequence Number | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Source CP ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Namespace | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | NE ID | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | . | 886 | CP Signature | 887 | . | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | ARDP AVPs... 890 +-+-+-+-+-+-+-+-+-+-+-+-+- 892 4.2.1. Version field 894 Specifies the ARDP protocol version a packet belongs to. Our current 895 document describes Version 1. 897 4.2.2. Header Length field 899 Specifies the length of the ARDP header. 901 4.2.3. Message Type field 903 Specifies the type of ARDP packet data part following the ARDP 904 header. ARDP message types are : 906 - 0x01 : CP Conditional Access Attributes message 907 - 0x02 : CP ServiceID Attributes message 908 - 0x03 : CP ClassID Attributes message 909 - 0x04 : ClientID Attributes message 911 4.2.4. Size field 913 Specifies the total size of the ARDP packet including ARDP header and 914 message data. 916 4.2.5. Count Messages field 918 Specifies the number of ARDP message data included in the global ARDP 919 packet. 921 4.2.6. Encryption flag 923 Specifies, if set to 1, that ARDP AVPs are encrypted using [AES]. 925 4.2.6. Authentication Type field 927 Specifies kind of authentication used to sign the ARDP packet. 928 Mandatory Authentication Type are : 930 - 0x01 : No authentication signature 931 - 0x02 : Use HMAC-MD5-96bit signature as described in [RFC2104] 932 - 0x03 : Use RSA signature as described in [RFC2437] 934 4.2.8. Sequence Number field 936 This 16-bit field contains a monotonically increasing counter value 937 managed at ARDP Server side. Each ARDP Server maintains a sequence 938 counter for every ARDP Message Types it may send. This sequence 939 number is legitimated by 2 points. 941 4.2.9. Source CP ID field 943 Specifies the CP origin of the ARDP packet. This gives ARDP Client 944 side the possibility to select authentication to be used as sanity 945 check. An Operator ID is a 32bit value identifying in a unique way 946 any CP. This can be an IPv4 IP address used as point of presence in 947 ARDP Backbone. 949 4.2.10. Namespace field 951 This field is used during ClientID flooding to indicate which CP the 952 ClientID flooding message belongs to. 954 4.2.11. NE ID field 956 This field is used during flooding to indicate which NE the 957 ClientID/Access Right flooding messages belongs to. This field 958 prevent against filtering every AVPs in every datagram while 959 processing. NE will process datagram if NE ID field found in ARDP 960 header is matching its locally configured ID. If field is zeroed then 961 NE will process inconditionnally datagram. 963 4.2.12. CP Signature field 965 Includes the digital signature (if used) to authenticate ARDP packet. 966 On ARDP Client side, Source CP ID field indicates which CP secret or 967 key to be used. Depending on authentication type used, this field is 968 96bit length long for HMAC-MD5-96bit signature or larger for RSA 969 signature. 971 4.3. ARDP AVP Packet Format 973 ARDP AVPs carry specific authentication, accounting, authorization, 974 routing and security information as well as configuration details for 975 a specific ServiceID, ClassID and ClientID. This message refers to 976 format and paradigm as presented in [RFC3588]. Every ARDP AVPs are 977 using the following Header specification as described in section 4.1 978 of [RFC3588]: 980 0 1 2 3 981 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 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | AVP Code | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 |V M P r r r r r| AVP Length | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Vendor-ID (opt) | 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Data ... 990 +-+-+-+-+-+-+-+-+ 992 In following sections we will define specifics AVPs for use in ARDP 993 protocol using Basic AVP data formats and Derived/Grouped AVP data 994 formats as in section 4.2 and 4.3 of [RFC3588]. 996 5. ARDP Base Protocol AVPs 998 The following table describes the ARDP AVPs defined in the base 999 protocol, their AVP Code Values, types, possible flag values and 1000 whether the AVP MAY be encrypted. For the the originator of a ARDP 1001 message, "Encr" (Encryption) means that if a message containing that 1002 AVP is to be sent via an ARDP server then the message MUST NOT be 1003 sent unless there is a end-to-end security between the originator and 1004 the recipient (eg: between ARDP Server and ARDP Client). 1006 +---------------------+ 1007 | AVP Flag rules | 1008 |----+-----+----+-----|----+ 1009 AVP Section | | |SHLD| MUST| | 1010 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 1011 -----------------------------------------|----+-----+----+-----|----| 1012 Auth-Service- 65536 3.3.3 Unsigned32 | M | P | | V | N | 1013 Id | | | | | | 1014 Auth-Class- 65537 3.3.4 Unsigned32 | M | P | | V | N | 1015 Id | | | | | | 1016 Auth-Client- 65538 3.3.5 Unsigned32 | M | P | | V | N | 1017 Id | | | | | | 1018 Auth-Client- 65539 3.7.3 Address | M | P | | V | N | 1019 Address | | | | | | 1020 Auth-Begin- 65540 3.3.6 Time | M | P | | V | N | 1021 Validity | | | | | | 1022 Auth-End- 65541 3.3.7 Time | M | P | | V | N | 1023 Validity | | | | | | 1024 Accounting- 65542 3.3.8 Address | M | P | | V | N | 1025 Server | | | | | | 1026 Multicast- 65543 3.5.3 Address | M | P | | V | N | 1027 Group | | | | | | 1028 Unicast- 65544 3.5.4 Address | M | P | | V | N | 1029 Source | | | | | | 1030 Bitrate 65545 3.5.7 Unsigned32 | M | P | | V | N | 1031 Capabilities 65546 3.5.8 Unsigned32 | M | P | | V | N | 1032 Service-Name 65547 3.5.9 UTF8String | M | P | | V | N | 1033 Version-Code 65558 3.5.10 Unsigned32 | M | P | | V | N | 1034 -----------------------------------------|----+-----+----+-----|----| 1036 ARDP Grouped AVPs are set of Base Protocol AVPs: 1038 +---------------------+ 1039 | AVP Flag rules | 1040 |----+-----+----+-----|----+ 1041 AVP Section | | |SHLD| MUST| | 1042 Attribute Name Code Defined Data Type |MUST| MAY | NOT| NOT|Encr| 1043 -----------------------------------------|----+-----+----+-----|----| 1044 Access-Right- 65580 3.4.1 Grouped | M | P | | V | N | 1045 Add | | | | | | 1046 Access-Right- 65581 3.4.2 Grouped | M | P | | V | N | 1047 Delete | | | | | | 1048 Accounting- 65582 3.4.3 Grouped | M | P | | V | N | 1049 Zap | | | | | | 1050 ServiceID-Add 65583 3.5.1 Grouped | M | P | | V | N | 1051 ServiceID- 65584 3.5.2 Grouped | M | P | | V | N | 1052 Delete | | | | | | 1053 ClassID-Add 65587 3.6.1 Grouped | M | P | | V | N | 1054 ClassID-Delete 65588 3.6.2 Grouped | M | P | | V | N | 1055 ClientID-Add 65589 3.7.1 Grouped | M | P | | V | N | 1056 ClientID- 65590 3.7.2 Grouped | M | P | | V | N | 1057 Delete | | | | | | 1058 -----------------------------------------|----+-----+----+-----|----| 1060 5.1. AVP Auth-Service-Id 1062 The Auth-Service-Id AVP (AVP code 65536) is of type Unsigned32 and 1063 refers to an ARDP ServiceID. 1065 5.2. AVP Auth-Class-Id 1067 The Auth-Class-Id AVP (AVP code 65537) is of type Unsigned32 and 1068 refers to an ARDP ClassID. 1070 5.3. AVP Auth-Client-Id 1072 The Auth-Client-Id AVP (AVP code 65538) is of type Unsigned32 and 1073 refers to an ARDP ClientID. 1075 5.5. AVP Auth-Begin-Validity 1077 The Auth-End-Validity AVP (AVP code 65540) is of type Time and 1078 identifies begin of a validity of Access right. 1080 5.6. AVP Auth-End-Validity 1082 The Auth-End-Validity AVP (AVP code 65541) is of type Time and 1083 identifies end of a validity of Access right. 1085 5.7. AVP Accounting-Server 1087 The Accounting-Server AVP (AVP code 65542) is of type Address and 1088 informs to ARDP client the remote accounting server it MUST send 1089 recorded zapping events (join, leave). 1091 5.8. AVP Access-Right-Add 1093 The Access-Right-Add AVP (AVP code 65580) is of type Grouped. It adds 1094 a positive access right for a ClientID to a specific ServiceID into 1095 ARDP Conditional Access cache. If received by NE then ClientID will 1096 have ability to zap and receive specified ServiceID (CP IPTV 1097 streaming service: multicast group) stream until its CPE. 1099 The Grouped Data field has the following ABNF grammar as in 1100 [RFC4234]: 1102 Access-Right-Add ::= < AVP Header: 65580 > 1103 { Auth-Client-Id } 1104 { Auth-Service-Id } / { Auth-Class-Id } 1105 { Auth-Begin-Validity } 1106 { Auth-End-Validity } 1107 * [ AVP ] 1109 This AVP allow ARDP sending source to append optional AVPs. 1111 5.9. AVP Access-Right-Delete 1113 The Access-Right-Delete AVP (AVP code 65581) is of type Grouped. It 1114 removes access right for a ClientID to a specific ServiceID from ARDP 1115 Conditional Access cache. If received by NE then ClientID will no 1116 longer have ability to zap and receive specified ServiceID. 1118 The Grouped Data field has the following ABNF grammar as in 1119 [RFC4234]: 1121 Access-Right-Delete ::= < AVP Header: 65581 > 1122 { Auth-Service-Id } 1123 { Auth-Client-Id } 1125 5.10. AVP Accounting-Zap 1127 The Accounting-Zap AVP (AVP code 65582) is of type Grouped. It 1128 defines accounting server for zapping event accounting. Every Zap 1129 events for a specified ClientID to a specific ServiceID or ClassID or 1130 set of ServiceID/ClassID will be traced to the specified Server. 1132 The Grouped Data field has the following ABNF grammar as in 1133 [RFC4234]: 1135 Accounting-Zap ::= < AVP Header: 65582 > 1136 { Auth-Client-Id } 1137 { Accounting-Server } 1138 * [{ Auth-Service-Id } / { Auth-Class-Id }] 1140 5.11. CP ServiceID Attributes message format 1142 This message type refers to a unary CP service definition and apply 1143 to ARDP header message Type as presented in section 3.2.3. 1145 5.12. AVP ServiceID-Add 1147 The ServiceID-Add AVP (AVP code 65583) is of type Grouped. It adds 1148 into CP namespace a ServiceID with its optional attributes. 1150 The Grouped Data field has the following ABNF grammar as in 1151 [RFC4234]: 1153 ServiceID-Add ::= < AVP Header: 65583 > 1154 { Auth-Service-Id } 1155 { Version-Code } 1156 { Multicast-Group } 1157 * { Unicast-Source } 1158 * { Multicast-Fallback-Group } 1159 * { Unicast-Fallback-Source } 1160 * { Bitrate } 1161 * { Capabilities } 1162 * { Service-Name } 1164 This AVP allow ARDP sending source to append ServiceID and optional 1165 AVPs. 1167 5.13. AVP ServiceID-Delete 1169 The ServiceID-Delete AVP (AVP code 65584) is of type Grouped. It 1170 removes from CP namespace a ServiceID. 1172 The Grouped Data field has the following ABNF grammar as in 1173 [RFC4234]: 1175 ServiceID-Add ::= < AVP Header: 65584 > 1176 { Auth-Service-Id } 1177 { Version-Code } 1179 5.14. AVP Multicast-Group 1181 The Multicast-Group AVP (AVP code 65543) is of type Address and is 1182 specific to ServiceID AVPs (Add and Delete). It specifies a unique ID 1183 into the TV Operator namespace. 1185 5.15. AVP Unicast-Source 1187 The Multicast-Group AVP (AVP code 65544) is of type Address and is 1188 specific to ServiceID AVPs (Add and Delete). It specifies an IPv4 IP 1189 address source of streaming refering to Multicast Group field. This 1190 is useful information when using SSM for wide-area multicast as 1191 described in [RFC3569]. 1193 5.16. AVP Capabilities 1195 The Capabilities AVP (AVP code 65548) is of type Unsigned32 and is 1196 specific to ServiceID AVPs (Add and Delete). It specifies ServiceID 1197 capabilities. 1199 5.17. AVP Service-Name 1201 The Service-Name AVP (AVP code 65549) is of type UTF8String and is 1202 specific to ServiceID AVPs (Add and Delete). It specifies Service 1203 description. 1205 5.18. AVP Version-Code 1207 The Version-Code AVP (AVP code 65550) is of type Unsigned32 and is 1208 specific to ServiceID AVPs (Add and Delete). It specifies a version 1209 number to identify the service plan this Service ID belongs to. 1211 5.19. CP ClassID Attributes message format 1213 This message type refers to a unary CP Class definition and apply to 1214 ARDP header message Type as presented in section 3.2.3. 1216 5.20. AVP ClassID-Add 1218 The ServiceID-Add AVP (AVP code 65587) is of type Grouped. It adds 1219 into CP namespace a ClassID. 1221 The Grouped Data field has the following ABNF grammar as in 1222 [RFC4234]: 1224 ClassID-Add ::= < AVP Header: 65587 > 1225 { Auth-Class-Id } 1226 { Version-Code } 1227 { Auth-Service-Id } 1229 This AVP allow ARDP sending source to append ClassID AVPs. 1231 5.21. AVP ClassID-Delete 1233 The ServiceID-Add AVP (AVP code 65588) is of type Grouped. It removes 1234 from CP namespace a ClassID. 1236 The Grouped Data field has the following ABNF grammar as in 1237 [RFC4234]: 1239 ClassID-Add ::= < AVP Header: 65588 > 1240 { Auth-Class-Id } 1242 5.22. ClientID Attributes message format 1244 This message type refers to a unary ClientID association and apply to 1245 ARDP header message Type as presented in section 3.2.3. 1247 5.23. AVP ClientID-Add 1249 The ClientID-Add AVP (AVP code 65589) is of type Grouped. It adds 1250 into CP namespace a ClientID. 1252 The Grouped Data field has the following ABNF grammar as in 1254 [RFC4234]: 1256 ClientID-Add ::= < AVP Header: 65589 > 1257 { Auth-Client-Id } 1258 { Auth-Client-Address } 1259 * [ AVP ] 1261 This AVP allow ARDP sending source to append any optional AVPs. 1263 5.24. AVP ClientID-Delete 1265 The ClientID-Delete AVP (AVP code 65590) is of type Grouped. It 1266 removes from CP namespace a ClientID. 1268 The Grouped Data field has the following ABNF grammar as in 1269 [RFC4234]: 1271 ClientID-Delete ::= < AVP Header: 65590 > 1272 { Auth-Client-Id } 1274 5.25. AVP Auth-Client-Address 1276 The ClientID-Delete AVP (AVP code 65539) is of type Address. It 1277 specifies the NE Client IP Address. 1279 6. Unicast Protocol Part 1281 ARDP Unicast datagrams are used by NE ARDP Client to request ARDP NSP 1282 Server for right cache feeding. Those messages are using general ARDP 1283 protocol header presented in section 3.2. Authentication is not 1284 mandatory since flows are local to private ARDP Backbone from NE to 1285 NSP ARDP Server. Unicast messages are vehiculed over IP/TCP and are : 1287 - 0x01 : NE Access Right populate request 1288 - 0x02 : NE ClientID populate request 1290 NE ARDP Client fills the NE ID field with its own ID. Formerly it 1291 used the IPv4 IP Address provided for ARDP Backbone point of 1292 presence. 1294 7. ARDP Server Operations 1296 The global goal of ARDP architecture is to focus protocol complexity 1297 onto the ARDP server instead of ARDP client. ARDP protocol reduce CPE 1298 complexity by deporting conditional access to aggregation equipment. 1299 The same statement is used for ARDP Server. It is responsible for 1300 ARDP protocol messages flooding and scheduled flooding jobs. In this 1301 many-to-many networking scheme it is convenient to centralize 1302 complexity onto the server side for maintenance and scalability 1303 reasons. 1305 ARDP Server MUST perform the following operations : 1307 - MUST permanently flood CP Service ID plane. If new 1308 Service ID plane is flooded then send all Access Right 1309 (of this CP). 1311 - If ARDP server is NSP ARDP Server then: 1313 o Only accept Unicast requests from NE ARDP Client 1315 o Only send Unicast request to remote CP ARDP Server 1317 Else 1319 o Only accept unicast requests from NSP ARDP Server 1321 Endif 1323 - MUST periodically flood whole Access Right 1325 - MUST flood ClientID before any Access Right related to this 1326 ClientID. 1328 - MUST monotonically increment sequences counters for every 1329 message type while sending ARDP datagrams. 1331 8. NE ARDP Client Operations 1333 ARDP Client side manages local access right cache. Its finite state machine 1334 is divided into 2 states as follows : 1336 +------------------+ +------------------+ 1337 | |------------------------>| | 1338 | Initialize | | Learning | 1339 | |<------------------------| | 1340 +------------------+ +------------------+ 1342 8.1. Initialize State 1344 The purpose of this state is to boot up ARDP protocol. While in this 1345 state, ARDP client MUST perform the following operations : 1347 - If Authentication is used then MUST load CP secrets 1348 for HMAC-MD5-96bit authentication or load RSA public key if 1349 RSA authentication is used. In addition it load CP secrets 1350 for AVPs AES encryption. 1352 - MUST wait until CP Service IDs are received. While receiving 1353 Service IDs update local ServiceID sequence counter. 1355 - MUST wait until CP Class IDs are received. While receiving 1356 Class IDs update local ClassID sequence counter. 1358 - MUST connect to NSP ARDP Server only to request for 1359 ClientID flooding. 1361 - If ClientID table is empty then: 1363 o Re-schedule a new ClientID flooding request to 1364 NSP ARDP Server. 1366 o If ClientID table still empty until max_retry then: 1367 . Disable scheduling ClientID flooding retry. 1368 . Re-schedule a new ClientID request with a longer 1369 delay 1370 Endif 1372 Else 1374 o Schedule Access Right flooding request to NSP ARDP Server. 1376 Endif 1378 - If Access Right Table is empty then: 1380 o Re-schedule a new Access Right flooding request to 1381 NSP ARDP Server. 1383 o If Access Right table still empty until max_retry then: 1384 . Disable scheduling Access Right flooding retry. 1385 . Re-schedule a new Access Right request with a longer 1386 delay 1387 Endif 1389 Else 1391 o Transit to Learning state. 1393 Endif 1395 In this pseudo code we can note that "Re-schedule" can mean inhibit 1396 flooding request since NSP ARDP Server can schedule any request since 1397 it has the knowledge of the whole ARDP Backbone point of presence. 1399 8.2. Learning State 1401 The purpose of this state is to enter a long time listening stage. 1402 While in this state, ARDP client MUST perform the following 1403 operations : 1405 - If Authentication is used then MUST drop any datagram 1406 received with a lower sequence number than currently 1407 stored sequence counter related to incoming ARDP 1408 message type. 1410 - When receiving ARDP datagram then MUST update local ARDP message 1411 type sequence counter with ARDP header sequence number field. 1413 - When receiving ClientID message, if ClientID is refering to a 1414 local NE IP Address then store this new correspondance. 1416 - When receiving ClientID message then MUST remove any Access 1417 Right associated if already exists. 1419 - When receiving Access Right message then MUST replace any Access 1420 Right related to the same ClientID/ServiceID. 1422 - When receiving new ServiceID, means when "Version Code" field is 1423 different from current ARDP Client Service version code then 1424 remove any Access Right related to the CP source of the message. 1426 - If Access Right Table is empty then: 1428 o Transit to Initialize state. 1430 Endif 1432 - When NE ARDP stack is looking for Access Right or TimeSlot 1433 in Access Right cache as describe in section 2.1, it MUST 1434 expire CP Access Right and CP Free Access TimeSlot according 1435 to Validity learnt during ARDP message flooding as presented in 1436 section 3.3.5/3.3.6 for CP Access Right and 3.7.3/3.7.4 for 1437 CP Free Access TimeSlot. If Access Right or Free Access TimeSlot 1438 has expired, then it is removed from local Access Right cache. 1440 9. Sending and receiving ARDP datagram 1442 9.1. Sending 1444 Any ARDP sending source MUST perform the following operations: 1446 - MUST fill ARDP protocol header in accordance with protocol 1447 specification in section 3. 1449 - If Authentication is used then sign ARDP datagram. 1451 - If E-flag is set then encrypt ARDP AVPs. 1453 9.2. Receiving 1455 Any ARDP received datagram MUST perform the following operations: 1457 - MUST perform sanity check over datagram to conform ARDP header 1458 elements with real data content. 1460 - If Authentication is used then: 1462 o MUST verify HMAC-MD5-96bit or RSA signature. If signature 1463 is not valid then: 1465 . Drop incoming datagram. 1467 Endif 1469 Endif 1471 - If E-flag is set then: 1473 o MUST Decrypt AVPs. 1475 Endif 1477 10. Acknowledgments 1479 Funding for the RFC Editor function is provided by the IETF 1480 Administrative Support Activity (IASA). 1482 11. References 1484 [HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within 1485 ESP and AH", Work in Progress. 1487 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 1488 (AES)," November 2001. 1489 http://csrc.nist.gov/publications/fips/fips197/ 1490 fips-197.{ps,pdf} 1492 [RFC2104] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing 1493 for Message Authentication", RFC 2104, February 1997. 1495 [RFC2437] B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography 1496 Specifications Version 2.0", RFC 2437, October 1998. 1498 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko 1499 "Diameter Base Protocol", RFC 3588, September 2003. 1501 [RFC4234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax 1502 Specifications: ABNF", RFC 4234, October 2005. 1504 [RFC3376] B. Cain, S. Deering, I. Kouvelas, B. Fenner, 1505 A. Thyagarajan, "Internet Group Management Protocol, 1506 Version 3", RFC 3376, October 2002. 1508 [RFC3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific 1509 Multicast (SSM)", RFC 3569, July 2003. 1511 [RFC2326] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming 1512 Protocol (RTSP)", RFC 2326, April 1998. 1514 [SIPRTSP] X. Marjou, J. Lindquist, P. Rajagopal, M. Said, S. Ganesan 1515 "Session Description Protocol (SDP) Offer/Answer Model For 1516 Media Control Protocol", Internet Draft. 1518 [AAA] Hiroaki Satou, Hiroshi Ohta, Christian Jacquenet, 1519 Tsunemasa Hayashi, Haixiang He, 1520 "AAA Framework for Multicasting", Internet Draft. 1522 12. Authors' Address 1524 Alexandre Cassen 1525 Freebox S.A. 1526 8, Rue de la Ville l Eveque 1527 75008 Paris 1528 FR 1530 EMail: acassen@freebox.fr