One document matched: draft-lehtonen-mboned-dynssm-req-00.txt
Internet Engineering Task Force R. Lehtonen
Internet-Draft TeliaSonera
Expires: August 15, 2005 S. Venaas
University of Southampton
M. Hoerdt
University Louis Pasteur - LSIIT
Feb 11, 2005
Requirements for discovery of dynamic SSM sources
draft-lehtonen-mboned-dynssm-req-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft identifies the need for discovering new SSM sources in a
multicast session. It also defines the basic requirements for such
functionality.
Lehtonen, et al. Expires August 15, 2005 [Page 1]
Internet-Draft dynssm req Feb 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 General requirements . . . . . . . . . . . . . . . . . . . 5
4.2 Host requirements . . . . . . . . . . . . . . . . . . . . 5
4.3 Signalling requirements . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 10
Lehtonen, et al. Expires August 15, 2005 [Page 2]
Internet-Draft dynssm req Feb 2005
1. Introduction
Many multi-party applications make use of multicast. Multicast
offers obvious benefits when one party is sending the same content to
multiple receivers. Also traditional multicast [3] allows for a
multi-party session to be identified by a single group address.
Any participant can send to the group without knowing who the
receivers are, and all receivers can join the group without knowing
who will send. This means for e.g. a video conference, one only
needs to give the multicast group address to potential participants,
possibly making a public announcement. Participants can then come
and go as they like, and those that happen to be sending to or
receiving from the group address simultaneously will be able to reach
each other.
There are several problems with traditional multicast [6] and it's
widely believed that Source-Specific Multicast (SSM) [1] is a more
scalable and easier to deploy interdomain multicast technology in the
long term. One of the simplifications of SSM is that source
discovery is not done in the network. It's however precisely the
network source discovery (typically using MSDP and Rendezvous-points)
that allows anyone to start sending at any point and the receivers to
get the data without knowing who the sources are.
SSM requires the application to specify exactly which sources it will
receive data from. The source addresses must somehow be learned by
the receivers out-of-band. With traditional multicast the multicast
group to use must be announced out-of-band before the session is to
take place. It may be announced using e.g. SDP over HTTP or SAP.
For SSM one could also list the addresses of the sources. This works
well where all the sources (participants) are known in advance, but
this will often not be the case. Also when announcing a multi-party
session publicly and allowing anyone to join, there should be a
simple mechanism for registering a participant and getting it
announced to the others. This draft defines the basic requirements
for such functionality.
2. Problem Statement
As illustrated in the table 1, various multicast applications
requirements may require different degree of dynamics in the source
discovery process. Existing and future applications require an out
of band multicast source discovery mechanism which ideally offers the
same level of performances than the current ASM architecture is
offering now by in-band means. Distributed Interactive Simulation
(D.I.S) [4] is a good example of applications which require a very
high level of performance from multicast source discovery.
Lehtonen, et al. Expires August 15, 2005 [Page 3]
Internet-Draft dynssm req Feb 2005
.-------------------------------------------------------------------.
|Applications type|Potential transient degree |Current solution for|
| |of the sources |for source discovery|
.-------------------------------------------------------------------.
|Games, D.I.S |High (measured in seconds) |ASM or client-server|
.-------------------------------------------------------------------.
|Distributed |High |client-server |
|File Sharing | | |
.-------------------------------------------------------------------.
|Conferencing |Medium (measured in minutes)|ASM or client-server|
.-------------------------------------------------------------------.
|TV/Radio |Low (measured in days) |Static publishing |
.-------------------------------------------------------------------.
Table 1 : Transient degree of various potential multicast
applications.
Today most of the multi-party applications containing transient
source of data are client-server based and do not take advantage of
IP multicast for source discovery. This limits their efficiency and
scalability.
Operational experience and analysis [2] have shown that current ASM
model implemented with MSDP [5] for source discovery has severe
scaling and security problems in inter-domain scale. In addition to
MSDP there are other problems with the RP based source discovery
mechanisms like deployment of new mechanisms into routers, RP as the
traffic congestion point and insufficient support for both IP
versions.
SSM model provides good scaling and security properties and works for
both IP versions, but does not provide direct support for source
discovery. a typical application that requires discovery of sources
during the session is video conferencing. The solution for discovery
of new sources during the ongoing session should be standardized for
several reasons:
o Clients from different origins/vendors may participate in the same
multicast session.
o Without a standardized solution application writers may decide to
solve this problem in different non-compatible ways.
o Source discovery must be manageable, so we need a standard that is
stable and can be managed/monitored (e.g. to prevent DoS attacks
against the multicast infrastructure).
In any cases this source discovery standard will facilitate the
Lehtonen, et al. Expires August 15, 2005 [Page 4]
Internet-Draft dynssm req Feb 2005
multi-source multicast applications writers to produce new
applications with less cost and wider compatibility across the
Internet. The multi-source multicast applications deployment effort
can be improved by such a solution.
3. Applicability Statement
The source discovery mechanism and its requirements only need that
the underlying network supports SSM natively end-to-end. The source
discovery mechanism is intended to work in both inter-domain and
intra-domain cases. The source discovery mechanism should provide
required SSM channel information to receivers. Other application
specific discovery requirements are out-of-scope (e.g. discovery of
source bandwidth, supported codecs, identification, etc.).
4. Requirements
This section lists the requirements for discovery of dynamic SSM
sources. The requirements are separated into general, host and
signalling parts.
4.1 General requirements
1. Solution must provide discovery of dynamic SSM sources during the
session, offering a comparable level of performance to the
current ASM architecture.
2. Solution shouldn't introduce additional requirements on the
network (in addition to SSM support).
3. Solution must work in SSM address space.
4. Solution should be easily manageable and provide good security
and control properties.
5. Solution should allow co-existence with other source discovery
mechanisms.
6. Gradual deployment must be possible without affecting the
operation of other SSM hosts.
7. Adding AAA and related functionalities (e.g. source access
control) must be possible.
4.2 Host requirements
1. Source discovery functionality must have at least three different
Lehtonen, et al. Expires August 15, 2005 [Page 5]
Internet-Draft dynssm req Feb 2005
separatable elements; source, receiver and rendezvous elements.
Sources are required to register themselves to discovery
process. Receivers are required to understand source discovery
signalling. Rendezvous function is needed between sources and
receivers for matchmaking and control purposes, a common point
source discovery signalling.
2. Multiple applications and users on the same host must be able to
use the source discovery functionality.
3. A group of users must be able to set up their own rendezvous
function.
4. Rendezvous functionality must be able to work in routers and/or
in specific hosts if needed for redundancy, availability and
control purposes.
5. Rendezvous function should be possible to implement in the SSM
application itself.
6. Overhead of being rendezvous must not be too big in terms of
processing power, memory or signalling traffic consumption.
7. It must be possible to add rendezvous fallback and load-sharing
properties (these functions are not part of the basic
requirement set).
8. Registering sources to discovery process must be as simple as
possible.
9. There shouldn't be additional hypothesis on the receivers than
SSM already brings.
10. Discovery mechanism should provide enough information on the
sources that non-active sources and respective SSM channels can
be teared down by the receivers.
4.3 Signalling requirements
1. Source discovery signalling must be separated from the actual
multicast traffic to achieve the following advantages:
* Allow path setup before actual traffic is sent (also initial
multicast packet gets delivered to receivers).
* Allow multicast traffic patterns to be different from source
discovery. Sources might send at low or high rates
Lehtonen, et al. Expires August 15, 2005 [Page 6]
Internet-Draft dynssm req Feb 2005
independent of signalling rate. Also the source discovery
signalling might be periodical but not necessarily the traffic
itself.
* While signalling may go via a central control point the
multicast traffic should always take the optimal path (no
traffic congestion point).
2. Signalling architecture must be robust. Information about new
sources must be distributed to receivers in less than 1 second.
New receivers must get the complete source information in less
than 15 seconds (worst case).
3. Discovery mechanism must support both IP versions.
4. Minimum amount of extra state in routers for source discovery.
5. Discovery should use multicast where possible, to reduce the
overhead of hosting rendezvous function.
6. Standardized and available mechanisms and protocols should be
used where appropriate.
7. Source discovery signalling should not necessarily be
centralized, the rendezvous function may be distributed across
the network to improve the robustness of the mechanism.
5. Security Considerations
This document specifies requirements for source discovery and
introduces no new security threats. Security is an important aspect
when deciding on a solution.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
Thanks to Jean-Jacques Pansiot and Pekka Savola for review and
constructive comments.
8. References
8.1 Normative References
[1] Bhattacharyya, S., "An Overview of Source-Specific Multicast
Lehtonen, et al. Expires August 15, 2005 [Page 7]
Internet-Draft dynssm req Feb 2005
(SSM)", RFC 3569, July 2003.
8.2 Informative References
[2] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and
Deflection of DoS Attacks Against the Multicast Source Discovery
Protocol", IEEE Infocom 2003.
[3] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[4] Pullen, J., Myjak, M. and C. Bouwens, "Limitations of Internet
Protocol Suite for Distributed Simulation the Large Multicast
Environment", RFC 2502, February 1999.
[5] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol
(MSDP)", RFC 3618, October 2003.
[6] Savola, P., "IPv6 Multicast Deployment Issues",
Internet-Draft draft-ietf-mboned-ipv6-multicast-issues-01,
September 2004.
Authors' Addresses
Rami Lehtonen
TeliaSonera
Hataanpaan valtatie 20
Tampere 33100
Finland
Email: rami.lehtonen@teliasonera.com
Stig Venaas
University of Southampton
School of Electronics and Computer Science
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: stig.venaas@uninett.no
Lehtonen, et al. Expires August 15, 2005 [Page 8]
Internet-Draft dynssm req Feb 2005
Mickael Hoerdt
University Louis Pasteur - LSIIT
C422 - Pole API - Boulevard Sebastien Brant
67400 ILLKIRCH Cedex
France
Email: hoerdt@clarinet.u-strasbg.fr
Lehtonen, et al. Expires August 15, 2005 [Page 9]
Internet-Draft dynssm req Feb 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lehtonen, et al. Expires August 15, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 11:40:36 |