Subject: mboned: AAA issue in Well Managed IP Multicast

From: Tsunemasa Hayashi <[email-masked]>
Date: Thu, 22 Sep 2005 20:47:51 +0900 (JST)

Hi All,

We were planning to present the updated I-D
draft-ietf-mboned-maccnt-req-00.txt
at IETF 63 but as most of you know because of scheduling difficulties
the mboned session was not able to be held.

http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-00.txt
"Accounting, Authentication and Authorization Issues in Well Managed IP Multicasting Services".

Summary of draft:
draft-ietf-mboned-maccnt-req-00.txt goes into more detail for the
following high-level requirements introduced in the companinion draft
draft-ietf-mboned-rac-issues-00.txt:

1) user tracking per Join/Leave and billing capability
    - user identification
2) need for network access control and/or content access control
    - user authentication and authorization for both NP and CSP to 
      each user access
    - issues of network resource protection such  as access control,
control of number of groups and total bandwidth delivered from edge
router
    NSP: Network Service Provider,  CP: Content Provider (Holder)
3) methods for sharing information between the NSP and CP, 
   when they are different entities.
    - matching users of NSP and CP for accounting, authorization, etc.

In July Hiroaki Satou sent a description of the changes to the draft
(see below.)   

As more large scale IPTV projects, etc are in planning around the world
we think it is necessary for the IETF to clearly produce a list of
requirements for multicasting AAA issues. The draft seems to be
stabilizing, and we would appreciate people's feedback here on the
mailing list in case any further iterations are necessary before IETF 64. 

Thanks

----------------------- Original Message -----------------------
 From:    Hiroaki Satou <[email-masked]>
 To:      [email-masked]
 Date:    Thu, 07 Jul 2005 19:58:33 +0900
 Subject: mboned: updated multicast AAA  draft
----

Hello

Since the last IETF session we have updated two drafts:

1) In April we updated I-D "Accounting, Authentication and Authorization 
Issues in Well Managed IP Multicasting Services"
http://www.ietf.org/internet-drafts/draft-ietf-mboned-maccnt-req-00.txt

2) and last week we updated the companion draft, I-D "Issues Related to 
Receiver Access Control in the Current Multicast Protocols"
http://www.ietf.org/internet-drafts/draft-ietf-mboned-rac-issues-00.txt

Primarily we removed redundancies between the drafts by consolidating 
requirements in draft-ietf-mboned-maccnt-req-00.txt.

A few specific changes/additions to draft-ietf-mboned-maccnt-req-00.txt
which we would like to hilite and receive feedback about are:

---------------------------------
4(2) We rearranged a number of points under a larger category of "Issue of 
network resource protection." And added subsections 4.2.2 and 4.2.3 about 
bandwidth control for the physical port of the edge router or the links 
between routers and between content servers and multicast routers

---------------------------------
4(6) We add a section "Notification to users of the result of the join request"

      It should be possible to provide information to the user about the
      status of his/her join request(granted/denied/other).

   <note this will likely need more elaboration>

---------------------------------
4(12)  Small impact on the existing products
We added a paragraph stating that there should not be an impact on "triple 
play" services

      Impact on the existing products (e.g., protocols, software, etc.)
      should be as minimal as possible.

      Ideally the NSP should be able to use the same infrastructure (such
      as access control) to support commercial multicast services for the
      so called "triple play" services: voice (VoIP), video, and
      broadband Internet access services.

---------------------------------
4(13) We added this section "Deployable as alternative to Unicast"

      IP Multicasting would ideally be available as an alternative to IP
      unicasting when the "on-demand" nature of unicasting is not
      required. Therefore interfaces to multicasting should allow for
      easy integration into CDS systems that support unicasting.
      Especially equivalent interfaces for authorization, access control
      and accounting capabilities should be provided.

---------------------------------

We would appreciate any input and feedback about these two drafts (either 
about the above
points or otherwise)

Thank you 

-- 
Tsunemasa Hayashi (NTT Network Innovation Labs.)
Tel: +81-46-859-8790
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/