MBONED Working Group H. Asaeda
Internet-Draft K. Mishima
Expires: January 7, 2009 Keio University
V. Roca
INRIA
July 6, 2008
Requirements for IP Multicast Session Announcement in the Internet
draft-asaeda-mboned-session-announcement-req-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2009.
Asaeda, et al. Expires January 7, 2009 [Page 1]
Internet-Draft Req. IP Multicast Session Announcement July 2008
Abstract
The Session Announcement Protocol (SAP) [3] was used to announce
information for all available multicast sessions to the prospective
receiver in an experimental network. It is usefull and easy to use,
but difficult to control the SAP message transmission in a wide area
network. This document describes the several major limitations SAP
has and the requirement of multicast session announcement in the
global Internet.
Asaeda, et al. Expires January 7, 2009 [Page 2]
Internet-Draft Req. IP Multicast Session Announcement July 2008
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 5
2.1. Announcement Interval vs. Latency . . . . . . . . . . . . 5
2.2. Difficulties in Scope Definition . . . . . . . . . . . . . 5
2.3. Communication Dependency . . . . . . . . . . . . . . . . . 6
2.4. Lack of Sender and Receiver Control . . . . . . . . . . . 7
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Asaeda, et al. Expires January 7, 2009 [Page 3]
Internet-Draft Req. IP Multicast Session Announcement July 2008
1. Introduction
The Session Announcement Protocol (SAP) [3] was a necessary component
to announce information for all available multicast sessions to the
prospective receiver in the experimental MBone. In a SAP
announcement procedure, the entire session information must be
periodically transmitted and all active session descriptions
(described with the Session Description Protocol (SDP) [4] syntax)
must be continuously refreshed. If ever a session is no longer
announced, its description eventually times out and is deleted from
the available session list. This is a major property of a "soft-
state" protocol.
SAP enables to keep the session information active and refresh it,
and builds robust and fault-tolerant systems. However, it requires
the periodic message transmission (i.e. message flooding) that may
cause major overheads or overloads. Although this strategy keeps the
implementation simple, it rises costs and further reduces its
scalability.
Another issue is closely related to a security or policy management.
As with the above issue, it is difficult to control a data sender or
a receiver and the amount of traffic or the data distribution area
even with existing scoping techniques.
This document explains the issues SAP has been raised and clarifies
the requirements that should fulfill an ideal session announcement
system. This document describes work originally published by Asaeda
and Roca in IEICE Transactions on Information and Systems [2].
Asaeda, et al. Expires January 7, 2009 [Page 4]
Internet-Draft Req. IP Multicast Session Announcement July 2008
2. Potential Problems in SAP
2.1. Announcement Interval vs. Latency
SAP improves the robustness and data consistency in front of packet
losses by transmitting each message several times. However,
transmitting a large number of active multicast sesssion information
in a flooding manner may cause major overheads. The solution defined
in [3] is the time period between repetitions of an announcement.
This period is chosen such that the total bandwidth used by all
announcements on a single SAP group remains below a preconfigured
limit, and the bandwidth limit should be assumed to be 4000 bits per
second, if not specified.
However, this solution largely increases the latency experienced by
end users especially when the number of sessions increases. In its
definition, since the minimum interval of SAP message transmission is
200 seconds, end users experience a minimum waiting time of 200
seconds to obtain the entire session list, irrespective of the number
of observed multicast sessions, message size of multicast session
information, and bandwidth SAP uses. Let us assume the average
message size of a single multicast session information is about 300
bytes. When there are more than 500 active multicast sessions, an
interval time of each session announcement becomes greater than 300
seconds and the average announcement interval increases accordingly.
For instance, if 2000 multicast sessions are active in the Internet,
each session announcement interval is between 800 seconds and 1600
seconds. In this case, if some SAP message is lost, users may need
to wait 1600 seconds for the next announcement as maximum.
Obviously, it is possible to make the announcement interval shorter
by changing the SAP configuration on a sender side and provide
shorter latency for the sender-receiver communication. However, it
makes the total ammount of SAP messages transmitted larger and may
increase the probability of creating congestions.
2.2. Difficulties in Scope Definition
Multicast data senders or network administrators may want to define
an area where data packets sent within a session will be confined.
This area is called "scope area". An end user who belongs to the
scope area can receive the session data.
When IP multicast was initially deployed in the MBone, the Time-To-
Live (TTL) field of the IP header was used to control the
distribution of multicast traffic. A multicast router configured
with a TTL threshold drops any multicast packet in which the TTL
falls below the threshold. For instance, a router at the boundary of
Asaeda, et al. Expires January 7, 2009 [Page 5]
Internet-Draft Req. IP Multicast Session Announcement July 2008
an organization configures the threshold to 32 which denotes an
"organization" scope boundary.
The drawbacks of this "TTL scoping" are: 1) the senders must be
sufficiently aware of the network topology to determine the TTL value
to use, and 2) complex scope areas cannot be defined (e.g., between
overlapped areas). Especially the first point becomes big obstacles
for general end users to precisely set up the data distribution area.
TTL scoping, which only defines a rough granularity, does not provide
a complete solution.
The "administratively scoped IP multicast" approach [5] provides
clear and simple semantics such as scope boundaries are associated to
multicast addresses. With IPv4, packets addressed to the
administratively scoped multicast address range 239/8 (i.e. from
239.0.0.0 to 239.255.255.255) cannot cross the configured
administrative boundaries. Since scoped addresses are defined
locally, the same multicast address can be used in different non-
overlapping areas. Oppositely, an administrator can define multiple
areas overlap by dividing the administratively scoped address range,
which is not possible with TTL scoping.
However, administrative scoping has several major limitations. An
administrator may want to partition the scope area to disjoint areas
on a per receiver basis, or he may want to limit data distribution
according to the transmission rate or the content category of each
session, or he may want to use the data sender's address as a keyword
to set up the scope. Note that the latter aspect is nowadays
feasible since Source-Specific Multicast (SSM) [6] requires that a
join request specifies both the multicast and source addresses.
SSM highlights another contradiction in the administrative scoping
approach: the address range dedicated to SSM, 232/8 with IPv4, cannot
cover the address range dedicated to administrative scoping, 239/8.
Although the problem can be solved by defining yet another SSM
specific administrative scoping address range, defining a new
addressing architecture requires modifying application, end host, and
router implementations or configurations. Hence, using multicast
addresses to define a scope is not a complete solution either.
2.3. Communication Dependency
SAP relies on the ASM model, since every SAP instance can send
announcements in the SAP announcement group. For instance, to
receive SAP announcement messages for the global scope IPv4 multicast
sessions, all prospective receivers must join session 224.2.127.254
(without specifying any source address). This is another major
limitation of SAP since some Internet Service Providers (ISPs) may
Asaeda, et al. Expires January 7, 2009 [Page 6]
Internet-Draft Req. IP Multicast Session Announcement July 2008
want to provide only SSM multicast routing. It is known that a
versatile announcement protocol should not rely on any specific
routing architecture.
Moreover, this communication model is subject to a Denial-of-Service
attack. If malicious hosts flood high bandwidth stream to this
global announcement address, 224.2.127.254, then all prospective
receivers including multicast routers listening SAP messages take in
the stream and their networks may be corrupted or destroyed
unintentionally.
2.4. Lack of Sender and Receiver Control
Network administrators or service providers may want to define
approved senders and restrict multicast data transmissions or
announcement only from them. However, it is difficult to configure
approved senders only who can send SAP messages or non-approved
senders who are disabled to send SAP messages.
In addition, it is diffucult to hide multicast session information
announced by SAP from non-approved receivers if they are inside the
scoped network. SAP messages might be encrypted to prevent non
authorized client from reading it. However, it adds more complexity
to SAP by combining with a key sharing mechanism.
Asaeda, et al. Expires January 7, 2009 [Page 7]
Internet-Draft Req. IP Multicast Session Announcement July 2008
3. Requirements
According to the SAP analysis aforementioned, the requirements for IP
multicast session announcement are defined as follows;
o Information consistency: Information consistency, which warrants
that end users have a consistant view of session announcement, is
of major importance.
o Low information update latency: IP multicast session would be
fully dynamic. The list of sessions should be updated rapidly
after the creation, modification, or removal of the session
information.
o Low bandwidth consumption: IP multicast session announcement
should effectively consume the network bandwidth so that it does
not affect other communications or services.
o Scalability: Session announcement can be used by a large number of
end users spread throughout the Internet, and can manage a very
large number of sessions.
o High availability: The scheme must be robust in front of host/link
failures and packet losses. This can be fulfilled either by
transmitting messages periodically or by keeping track of failures
and recovering them.
o Scope control: Scope control is required to preserve bandwidth
resources and offer a certain level of confidentiality in IP
multicast communication.
o No dependency on a routing architecture: The session announcement
scheme must accommodate (or be independent of) any kind of
multicast routing protocol or communication model.
o Sender and receiver control: Administrators must be able to allow
to announce multicast sessions only from approved multicast
senders and only to approved multicast data receivers in their
network. They must be able to filter out malicious users.
Asaeda, et al. Expires January 7, 2009 [Page 8]
Internet-Draft Req. IP Multicast Session Announcement July 2008
4. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[2] Asaeda, H. and V. Roca, "Policy and Scope Management for
Multicast Channel Announcement", IEICE Trans. on Information and
Systems Vol.E88-D, No.7, July 2005.
[3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[5] Mayer, D., "Administratively scoped IP multicast", RFC 2365,
July 1998.
[6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
Asaeda, et al. Expires January 7, 2009 [Page 9]
Internet-Draft Req. IP Multicast Session Announcement July 2008
Authors' Addresses
Hitoshi Asaeda
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: asaeda@wide.ad.jp
Kazuhiro Mishima
Keio University
Graduate School of Media and Governance
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Email: three@sfc.wide.ad.jp
Vincent Roca
INRIA
Planete Research Team
655, Avenue de l'Europe
Montbonnot - Saint Martin, Saint Ismier 38334
France
Email: vincent.roca@inrialpes.fr
Asaeda, et al. Expires January 7, 2009 [Page 10]
Internet-Draft Req. IP Multicast Session Announcement July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Asaeda, et al. Expires January 7, 2009 [Page 11]