Internet Engineering Task Force                        F. Le Garrec 
  INTERNET-DRAFT                                       France Telecom 
                                                                  R&D 
  Document: draft-legarrec-mcast-mgt-as-00.txt          February 2002 
  Category: Informational                             Expires: August 
                                                                 2002 
   
   
     Applicability statement on providing solutions for IP multicast 
                           services management 
   
   
1. Status of this Memo 
   
  This document is an Internet-Draft and is in full conformance 
  with all provisions of Section 10 of RFC2026. 
   
  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. 
   
   
2. Abstract 
   
  This document describes a return of experience in trying to determine 
  a practical solution to a list of identified functional requirements 
  for managing an IP multicast network and its services. This list 
  includes information that is scattered among many IETF drafts. 
   
  This document does not pretend offering a complete overview of the 
  problems that can be encountered in setting up a management solution 
  for IP multicast networks. It only focuses on certain topics that 
  were prioritized and on the encountered difficulties. 
   
   
Table of Contents 
   
  1. Status of this Memo...........................................1 
  2. Abstract......................................................1 
  3. Introduction..................................................2 
  4. Accounting....................................................2 
      4.1. Introduction............................................2 
      4.2. Flow metering...........................................3 
      4.3. Issues..................................................3 
  5. Membership management.........................................3 
  6. Sessions management...........................................4 
  7. Performance monitoring........................................4 
      7.1. About MRM applicability.................................4 
            7.1.1. Lack of MIB.....................................4 
    
  Le Garrec    Informational - Expires August, 2002               1 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
            7.1.2. Limited lifetime................................5 
            7.1.3. Perspectives....................................5 
  8. Address allocation management.................................5 
  9. Security considerations.......................................5 
      9.1. Identified set of functions.............................5 
      9.2. Applicability...........................................5 
  10. To do 6 
  11. References...................................................6 
  12. Author's address.............................................6 
   
   
3. Introduction 
   
  Large-scale IP multicast network and services deployment leads to 
  number of management issues, some of them specific to the multicast 
  particularities. Many of these issues have already been identified in 
  documents produced by dedicated IETF and IRTF working groups. A list 
  of management requirements can thus be gathered from the drafts and 
  RFCs. 
   
  This document presents an experience in attempting: 
  - To map these requirements onto a corporate-scale network and  
  - To define practical solutions to address as many of these 
     requirements as possible. 
   
  Among the identified requirements, most of them can be grouped in 
  several management "domains" which are: 
  - Accounting 
  - Membership management 
  - Sessions management 
  - Performance management 
  - Address allocation management 
  - Security 
   
4. Accounting 
   
4.1. Introduction 
   
  According to [RFC2975], the field of accounting management is 
  concerned with the collection of resource consumption data for the 
  purposes of capacity and trend analysis, cost allocation, auditing, 
  and billing. It requires that resource consumption be measured, 
  rated, assigned, and communicated between appropriate parties. 
   
  Even without considering multicast with QoS support, charging for 
  multicast services raises challenging problems like cost sharing 
  (between senders and receivers) and correct evaluation of the network 
  load. The service provider can even choose to charge on content 
  consumption or on transport cost. 
   
  The features that are provided in the content distribution solutions 
  should facilitate the accounting task. However, it appears that, in a 
  network where sender applications originate from multiple vendors, it 
  is difficult to rely on them for logging usage/activity and offering 
  a practical usage data retrieving interface. 
   
  The hereby described proposal is to rely on flow metering for usage 
  data collection and on IGMP MIB polling for receivers determination. 
   
    
  Le Garrec    Informational - Expires August, 2002               2 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
4.2. Flow metering 
   
  A typical usage of IP multicast transport is to send real-time 
  multimedia content from a specific sender (content server) to a large 
  number of receivers. 
   
  Thus, the complete view of sent data can be obtained by activating 
  flow metering on the ingress interface of the first router connecting 
  the sending host to the network.  
   
  The flow destination IP address is the multicast group IP address. 
  Determining delivered content to receivers can be obtained by 
  activating flow metering on the egress interface of the receivers 
  gateway router. 
   
  Obtaining a better granularity (i.e. determining which end-hosts 
  received the data) requires querying the IGMP MIB of these gateway 
  routers. 
   
4.3. Issues 
   
  Even if the above method for collecting usage data relieves from 
  relying on vendors specific (and sometimes missing) usage metering 
  functionalities, it raises important issues, mainly of scalability 
  (which is critical to accounting): 
   
  - Granularity of the flow export configuration: only multicast flows 
     information are interesting, but there is a high probability that 
     it is negligible compared to unicast traffic observed on the same 
     interface. Thus, usage collection efficiency (and flow export 
     bandwidth consumption) highly depends on the flow exporter 
     capability to be customized to export only interesting flow 
     tickets. 
   
  - Scalability issue for flow export: even if the flow metering 
     devices (very often a router) can export only tickets for 
     multicast flows, it may not scale for high-end networks devices. 
     First, in case of a small number of collecting points, paths on 
     which flow tickets converge may be congested. Second, the 
     collecting device itself may not be able to sustain the amount of 
     flow tickets it receives. Dispatching the collecting devices in 
     key locations in the network may be part of the solution. 
   
  - Scalability issue for polling routers' IGMP MIB. Such issue did 
     not raise in the experiment, as the network contained a small 
     number of routers, but will become critical in a larger scale. A 
     partial solution is to lower the SNMP polling frequency, but then 
     the trade-off will be losing knowledge of receivers that joined 
     and left between two pollings. 
   
5. Membership management 
   
  Membership management should provide the following services: 
   
  - To be able to create/delete groups. 
  - To be able to obtain a list of existing groups. 
  - To be able to list the current groups' members. 
  - To be able to know which group a receiver belongs to. 
  - To be able to find a list of receivers behind a edge router. 
  - To be able to find/setup policies applying to a group/member (e.g. 
     membership criteria) 
   
    
  Le Garrec    Informational - Expires August, 2002               3 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
  (This section has yet to be written.) 
   
6. Sessions management 
   
  Sessions management should provide the following services: 
   
  - To be able to browse available sessions. 
  - To be able to find servers proposing sessions.  
  - To obtain detailed description about the session (scope, codec, 
     schedule, security policy, etc.). 
  - Provide information about the sources of the sessions. 
  - To be able to block traffic on receivers' side. 
  - To control the scope of sessions. 
   
  On the content servers, the following functions should be available: 
   
  - To be able to create and delete sessions. 
  - To be able to control an active session. 
  - To be able to modify session characteristics (scope, codec, 
     schedule, security policies, etc.). 
  - To be able to send session announcement/invitation 
   
  (This section has yet to be written.) 
   
7. Performance monitoring 
   
  The level of quality associated to the deployment of multicast 
  services is expected to rely (heavily) on real-time metrics, and so 
  jitter and packet loss are critical to control. A RTP/RTCP probe 
  could be used to provide jitter measurement. The following paragraphs 
  discuss using MRM as a source for packet loss measurement. 
   
7.1. About MRM applicability 
   
  The purpose of [MRM] is to assist in the detection and isolation of 
  network faults related to the delivery of multicast traffic. MRM is 
  specifically designed to monitor routing operation and assist in the 
  investigation of routing anomalies and connectivity problems. MRM 
  provides packets loss measurement within a multicast group. Packet 
  loss is a critical metric when evaluating the delivered QoS to 
  receivers of real-time data content. 
   
  The following information relates to one specific MRM implementation 
  available as a software feature in the routers constituting the 
  experimental network. 
   
7.1.1. Lack of MIB 
   
  The lack of a MRM MIB raises the issue of collecting statistics with 
  a SNMP manager from the MRM Manager router, thus complicating its 
  integration in the management solution. 
   
  In the routers participating to the experiment, MRM manager, sender 
  and receiver can only be configured through the CLI in privileged 
  mode. 
   
  Thus scripts have been developed that periodically perform the CLI 
  commands on the manager to collect the statistics. This is not a 
  satisfying solution for reasons of scalability and security.  
   
  It would be much more satisfying to rely on SNMP v3 for polling. 
   
    
  Le Garrec    Informational - Expires August, 2002               4 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
7.1.2. Limited lifetime 
   
  MRM probes in the routers participating to the experiment appeared to 
  have a limited lifetime, whose maximum duration is one day. Thus, it 
  cannot be set up once and for all to enable permanent monitoring of 
  the packet loss rate.  
   
  Currently, the only way to by-pass this limitation is to use scripts 
  that periodically reinitialize the MRM probes through the CLI. 
   
7.1.3. Perspectives 
   
  MRM could be an interesting monitoring tool if it could be properly 
  integrated within our classical SNMP management framework. First, a 
  MIB is yet to be designed, for purposes of both configuring the 
  probes and collecting the statistics, and second the MRM 
  implementation available within the routers should be revised so that 
  lifetime be not a limitation. 
   
8. Address allocation management 
   
  The address management relates to selection and coordination of 
  address allocation. There is a need to provide assurances against 
  "address collision" and to provide address ownership. 
   
  (This section has yet to be written) 
   
9. Security considerations 
   
  Security in IP multicast is different from security mechanisms used 
  in unicast connections, as multicast data are sent to a group of 
  receivers and not to a specific one. Furthermore, it is not possible 
  for the sender to obtain a list of receivers because all receivers 
  are identified only by using the same multicast address. 
   
  Another subject of interest is ensuring content privacy among dynamic 
  multicast groups and limiting senders. 
   
9.1. Identified set of functions 
   
  Most of the following needed features for security management have 
  been identified in [SMUG-TAXO] and [SMUG-GKM1]. 
   
  - Senders control. 
  - Group membership control. 
  - Secure group keys distribution. 
  - Integrity of sent data. 
  - Anonymity of receivers. 
  - Individual source authentication. 
  - Membership revocation: how is further group access disabled for 
     group members that leave the group? 
  - Prevent performance degradation (delay) in case of re-keying when 
     members leave, especially for large group sizes. 
  - Reliability of the key management system. 
   
9.2. Applicability 
   
  Experiments lead to notice that providing solutions to the identified 
  requirements is tightly related to vendors implementations and to 
  their content server features. This is quite an obstacle to provide 
  generic means of managing the security of the multicast services. 
   
    
  Le Garrec    Informational - Expires August, 2002               5 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
  (To be further investigated) 
   
10. To do 
   
  Among the items that are yet to be explored, we can note the 
  following: 
   
  - A way to properly integrate MRM within the SNMP framework 
  - Investigate policy-driven QoS configuration for facilitating 
  differentiated QoS among multicast sessions. 
  - A more scalable way of providing usage data. 
  - Investigate dynamic address allocation management. 
  - Security issues, which have been left aside as for now in 
  experiments. 
   
11. References 
   
  [MRM]         K. Sarac, K. Almeroth, "Supporting Multicast 
                 Deployment Efforts: A Survey of Tools for Multicast 
                 Monitoring", Journal of High Speed Networking--Special 
                 Issue on Management of Multimedia Networking, March 
                 2001. 
                  
  [MRM-USE]     draft-ietf-mboned-mrm-use-00.txt 
                  
  [RFC2975]     B. Aboba, J. Arkko, D. Harrington, "Introduction to 
                 accounting management", RFC2975, October 2000. 
                  
  [IPFIX-ARCH]  Ganesh Sadasivan, Benoit Claise, "Proposal for IPFIX 
                 Flow Export Architecture and Data Model", draft-
                 gsadasiv-ipfix-proposal-00.txt, February 2002 
                  
  [RFC2627]     D. Wallner, E. Harder, R. Agee, "Key Management for 
                 Multicast: Issues and Architectures", RFC2627, June 
                 1999 
                  
  [SMUG-GKM1]   Hardjono, Cain, "Intranet GKM management", draft-irtf-
                 smug-intragkm-00.txt, September 2000 
                  
  [SMUG-TAXO]   R. Canetti, B. Pinkas, A taxonomy of multicast 
                 security issues, draft-irtf-smug-taxonomy-01.txt, 
                 August 2000 
                  
  [IGMP-MIB]    K. McCloghrie, D. Farinacci and D. Thaler, "Internet 
                 Group Management Protocol MIB", RFC2933, October 2000 
                  
  [MCAST_APPS]  Bob Quinn, Kevin Almeroth, "IP Multicast Applications 
                 : challenges and solutions", draft-ietf-mboned-mcast-
                 apps-01.txt, June 1999 
                  
  [CONFARCH]    M. Handley, J. Crowcroft, C. Bormann, J. Ott, 
                 "Internet Multimedia Conferencing Architecture", 
                 draft-ietf-mmusic-confarch-03.txt, July 2000 
   
12. Author's address 
   
  Frederic Le Garrec 
  France Telecom R&D 
  905 rue Albert Einstein 
  06921 Sophia-Antipolis, France 
  Phone: +33 4 92 94 52 88 
  Email: frederic.legarrec@francetelecom.com 
    
  Le Garrec    Informational - Expires August, 2002               6 
  Internet Draft   draft-flg-mcast-mgt-as-00.txt       February 2002 
 
   
    
  Le Garrec    Informational - Expires August, 2002               7