draft-ietf-mboned-session-announcement-req-00.txt   draft-ietf-mboned-session-announcement-req-01.txt 
MBONED Working Group H. Asaeda MBONED Working Group H. Asaeda
Internet-Draft Keio University Internet-Draft Keio University
Expires: April 30, 2009 V. Roca Intended status: Informational V. Roca
INRIA Expires: September 10, 2009 INRIA
October 27, 2008 March 9, 2009
Requirements for IP Multicast Session Announcement in the Internet Requirements for IP Multicast Session Announcement in the Internet
draft-ietf-mboned-session-announcement-req-00 draft-ietf-mboned-session-announcement-req-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
The Session Announcement Protocol (SAP) [3] was used to announce The Session Announcement Protocol (SAP) [3] was used to announce
information for all available multicast sessions to the prospective information for all available multicast sessions to the prospective
receiver in an experimental network. It is useful and easy to use, receiver in an experimental network. It is easy to use, but not
but difficult to control the SAP message transmission in a wide area scalable and difficult to control the SAP message transmission in a
network. This document describes the several major limitations SAP wide area network. This document describes the major limitations SAP
has and the requirements for multicast session announcement in the has and the requirements for multicast session announcement in the
global Internet. global Internet.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [1]. this document are to be interpreted as described in RFC 2119 [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 5 2. Potential Problems in SAP . . . . . . . . . . . . . . . . . . 6
2.1. Announcement Interval vs. Latency . . . . . . . . . . . . 5 2.1. Announcement Interval vs. Latency . . . . . . . . . . . . 6
2.2. Difficulties in Scope Definition . . . . . . . . . . . . . 5 2.2. Difficulties in Scope Definition . . . . . . . . . . . . . 6
2.3. Communication Dependency . . . . . . . . . . . . . . . . . 6 2.3. ASM Dependency . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Lack of Sender and Receiver Control . . . . . . . . . . . 7 2.4. Lack of Sender and Receiver Control . . . . . . . . . . . 8
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Potential Problems in Server-Based Solutions . . . . . . . . . 9
4. Normative References . . . . . . . . . . . . . . . . . . . . . 9 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The Session Announcement Protocol (SAP) [3] was a necessary component The Session Announcement Protocol (SAP) [3] was a necessary component
to announce information for all available multicast sessions to the to announce information for all available multicast sessions to the
prospective receiver in the experimental MBone. In a SAP prospective receiver in the experimental MBone. In a SAP
announcement procedure, the entire session information must be announcement procedure, the entire session information must be
periodically transmitted and all active session descriptions periodically transmitted and all active session descriptions
(described with the Session Description Protocol (SDP) [4] syntax) (described with the Session Description Protocol (SDP) [4] syntax)
must be continuously refreshed. If ever a session is no longer must be continuously refreshed. If ever a session is no longer
skipping to change at page 4, line 30 skipping to change at page 5, line 30
the periodic message transmission (i.e. message flooding) that may the periodic message transmission (i.e. message flooding) that may
cause major overheads or overloads. Although this strategy keeps the cause major overheads or overloads. Although this strategy keeps the
implementation simple, it rises costs and further reduces its implementation simple, it rises costs and further reduces its
scalability. scalability.
Another issue is closely related to a security or policy management. 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 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 a receiver and the amount of traffic or the data distribution area
even with existing scoping techniques. even with existing scoping techniques.
This document explains the issues SAP has been raised and clarifies This document explains the issues SAP and other systems have raised
the requirements that should fulfill an ideal session announcement and clarifies the requirements that should fulfill an ideal session
system. This document describes work originally published by Asaeda announcement system. This document describes work originally
and Roca in IEICE Transactions on Information and Systems [2]. published by Asaeda and Roca in IEICE Transactions on Information and
Systems [2].
2. Potential Problems in SAP 2. Potential Problems in SAP
2.1. Announcement Interval vs. Latency 2.1. Announcement Interval vs. Latency
SAP improves the robustness and data consistency in front of packet SAP improves the robustness and data consistency in front of packet
losses by transmitting each message several times. However, losses by transmitting each message several times. However,
transmitting a large number of active multicast sesssion information transmitting a large number of active multicast sesssion information
in a flooding manner may cause major overheads. The solution defined in a flooding manner may cause major overheads. The solution defined
in [3] is the time period between repetitions of an announcement. in [3] is the time period between repetitions of an announcement.
skipping to change at page 6, line 4 skipping to change at page 7, line 4
Multicast data senders or network administrators may want to define Multicast data senders or network administrators may want to define
an area where data packets sent within a session will be confined. 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 This area is called "scope area". An end user who belongs to the
scope area can receive the session data. scope area can receive the session data.
When IP multicast was initially deployed in the MBone, the Time-To- When IP multicast was initially deployed in the MBone, the Time-To-
Live (TTL) field of the IP header was used to control the Live (TTL) field of the IP header was used to control the
distribution of multicast traffic. A multicast router configured distribution of multicast traffic. A multicast router configured
with a TTL threshold drops any multicast packet in which the TTL with a TTL threshold drops any multicast packet in which the TTL
falls below the threshold. For instance, a router at the boundary of falls below the threshold. For instance, a router at the boundary of
an organization configures the threshold to 32 which denotes an an organization configures the threshold to 32, which denotes an
"organization" scope boundary. "organization" scope boundary.
The drawbacks of this "TTL scoping" are: 1) the senders must be The drawbacks of this "TTL scoping" are: 1) the senders must be
sufficiently aware of the network topology to determine the TTL value sufficiently aware of the network topology to determine the TTL value
to use, and 2) complex scope areas cannot be defined (e.g., between to use, and 2) complex scope areas cannot be defined (e.g., between
overlapped areas). Especially the first point becomes big obstacles overlapped areas). Especially the first point becomes big obstacles
for general end users to precisely set up the data distribution area. for general end users to precisely set up the data distribution area.
TTL scoping, which only defines a rough granularity, does not provide TTL scoping, which only defines a rough granularity, does not provide
a complete solution. a complete solution.
skipping to change at page 6, line 44 skipping to change at page 7, line 44
SSM highlights another contradiction in the administrative scoping SSM highlights another contradiction in the administrative scoping
approach: the address range dedicated to SSM, 232/8 with IPv4, cannot approach: the address range dedicated to SSM, 232/8 with IPv4, cannot
cover the address range dedicated to administrative scoping, 239/8. cover the address range dedicated to administrative scoping, 239/8.
Although the problem can be solved by defining yet another SSM Although the problem can be solved by defining yet another SSM
specific administrative scoping address range, defining a new specific administrative scoping address range, defining a new
addressing architecture requires modifying application, end host, and addressing architecture requires modifying application, end host, and
router implementations or configurations. Hence, using multicast router implementations or configurations. Hence, using multicast
addresses to define a scope is not a complete solution either. addresses to define a scope is not a complete solution either.
2.3. Communication Dependency 2.3. ASM Dependency
SAP relies on the ASM model, since every SAP instance can send SAP relies on the ASM model, since every SAP instance can send
announcements in the SAP announcement group. For instance, to announcements in the SAP announcement group. For instance, to
receive SAP announcement messages for the global scope IPv4 multicast receive SAP announcement messages for the global scope IPv4 multicast
sessions, all prospective receivers must join session 224.2.127.254 sessions, all prospective receivers must join session 224.2.127.254
(without specifying any source address). This is another major (without specifying any source address). This is another major
limitation of SAP since some Internet Service Providers (ISPs) may limitation of SAP since some Internet Service Providers (ISPs) may
want to provide only SSM multicast routing. It is known that a want to provide only SSM multicast routing. It is known that a
versatile announcement protocol should not rely on any specific versatile announcement protocol should not rely on any specific
routing architecture. routing architecture.
skipping to change at page 7, line 24 skipping to change at page 8, line 24
2.4. Lack of Sender and Receiver Control 2.4. Lack of Sender and Receiver Control
Network administrators or service providers may want to define Network administrators or service providers may want to define
approved senders and restrict multicast data transmissions or approved senders and restrict multicast data transmissions or
announcement only from them. However, it is difficult to configure announcement only from them. However, it is difficult to configure
approved senders only who can send SAP messages, or non-approved approved senders only who can send SAP messages, or non-approved
senders who are disabled to send SAP messages. senders who are disabled to send SAP messages.
In addition, it is difficult to hide multicast session information In addition, it is difficult to hide multicast session information
announced by SAP from non-approved receivers if they are inside the announced by SAP from non-approved receivers if they are inside the
scoped network. SAP messages might be encrypted to prevent non scoped network. SAP messages might be encrypted to prevent non-
authorized client from reading them. However, it adds more authorized client from reading them. However, it adds more
complexity to SAP by combining with a key sharing mechanism. complexity to SAP by combining with a key sharing mechanism.
3. Requirements 3. Potential Problems in Server-Based Solutions
According to the SAP analysis aforementioned, the requirements for IP Emails, RSS (Rich Site Summary or Really Simple Syndication), and the
Web are the alternative ways of conveying session descriptions.
These applications are of wide use and can be used to carry many
kinds of information. However, to provide a multicast announcement
function, these approaches would have to rely on a central server or
a central management system. This condition reduces flexibility of
fine-grained user and session management.
Session announcement should be decided by data senders or
administrators policy, such as scoping policy [5], or content-level
or user-level access control, which defines "who can access which
contents". Defining and applying such site-local policy or user
management would be very difficult or impossible on a single server
in the global Internet. This condition contradicts the requirements
experienced in the traditional MBone and expected in current or
future use.
In addition, emails and the RSS feed are implemented with a
"subscription model". The subscription model requires end users to
know the address of service providers and have subscribed to the
services for getting session information prior to receiving the
contents information. This condition is not reasonable for session
announcement, because end users do not always know potential data
senders, and the subscription model does not enable to discover them.
Finally, server-based systems may require a large amount of
operational costs or cause scalability problems for the fine-grained
user and session management and session announcement, especially when
the systems need to support a large number of users and contents
information.
4. Requirements
According to the analyses aforementioned, the requirements for IP
multicast session announcement are defined as follows; multicast session announcement are defined as follows;
o Information consistency: Information consistency, which warrants o Information consistency: Information consistency, which warrants
that end users have a consistent view of session announcement, is that end users have a consistent view of session announcement, is
of major importance. of major importance.
o Low information update latency: IP multicast session would be o Low information update latency: IP multicast session would be
fully dynamic. The list of sessions should be updated rapidly fully dynamic. The list of sessions should be updated rapidly
after the creation, modification, or removal of the session after the creation, modification, or removal of the session
information. information.
skipping to change at page 8, line 40 skipping to change at page 10, line 40
and recovering them. and recovering them.
o Scope control: Scope control is required to preserve bandwidth o Scope control: Scope control is required to preserve bandwidth
resources and offer a certain level of confidentiality in IP resources and offer a certain level of confidentiality in IP
multicast communication. multicast communication.
o No dependency on a routing architecture: The session announcement o No dependency on a routing architecture: The session announcement
scheme must accommodate (or be independent of) any kind of scheme must accommodate (or be independent of) any kind of
multicast routing protocol or communication model. multicast routing protocol or communication model.
o No dependency on a central server: Session announcement should not
rely on a central server, because defining and applying session
scopes would be impossible.
o Sender and receiver control: Administrators must be able to allow o Sender and receiver control: Administrators must be able to allow
to announce multicast sessions only from approved multicast to announce multicast sessions only from approved multicast
senders and only to approved multicast data receivers in their senders and only to approved multicast data receivers in their
network. They must be able to filter out malicious users. network. They must be able to filter out malicious users.
o Security consideration: In order to provide secure multicast o Security consideration: In order to provide secure multicast
communication, session announcement should have a function that communication, session announcement should have a function that
enables to encrypt session information and distribute it to only enables to encrypt session information and distribute it to only
the legitimate users. the legitimate users.
4. Normative References 5. Normative References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement [1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
[2] Asaeda, H. and V. Roca, "Policy and Scope Management for [2] Asaeda, H. and V. Roca, "Policy and Scope Management for
Multicast Channel Announcement", IEICE Trans. on Information and Multicast Channel Announcement", IEICE Trans. on Information and
Systems, Vol.E88-D, No.7, July 2005. Systems, Vol.E88-D, No.7, pp.1638-1645, July 2005.
[3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [3] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [4] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[5] Mayer, D., "Administratively scoped IP multicast", RFC 2365, [5] Mayer, D., "Administratively scoped IP multicast", RFC 2365,
July 1998. July 1998.
skipping to change at page 11, line 4 skipping to change at line 359
Vincent Roca Vincent Roca
INRIA INRIA
Planete Research Team Planete Research Team
655, Avenue de l'Europe 655, Avenue de l'Europe
Montbonnot - Saint Martin, Saint Ismier 38334 Montbonnot - Saint Martin, Saint Ismier 38334
France France
Email: vincent.roca@inrialpes.fr Email: vincent.roca@inrialpes.fr
URI: http://planete.inrialpes.fr/~roca/ URI: http://planete.inrialpes.fr/~roca/
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.
 End of changes. 16 change blocks. 
33 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/