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