Internet DRAFT - draft-chodorek-multigroup-multicast-addr
draft-chodorek-multigroup-multicast-addr
Network Working Group R.R. Chodorek
Internet Draft AGH Univ. of Science and Technology
Intended status: Experimental March 28, 2014
Expires: September 28, 2014
Multiple multicast addressing architecture
draft-chodorek-multigroup-multicast-addr-00.txt
Abstract
This document introduces a new class of IPv6 multicast addresses
called "multiple multicast". We define multiple multicast as a set
of multicast addresses belonging to one multicast session.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and 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 September 28, 2014.
Copyright Notice
Copyright (c) 2014 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
(http://trustee.ietf.org/license-info) in effect on the date of
Chodorek Expires September 28, 2014 [Page 1]
Internet-Draft Multiple multicast addressing March 2014
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ................................................ 2
2. Conventions used in this document ............................ 2
3. Multiple multicast addressing ................................ 3
4. Usage of multiple multicast addressing ....................... 4
4.1. Multimedia layered multicast ............................ 4
4.2. Multimedia conference systems ........................... 4
4.3. Multiple content from the one sender .................... 4
4.4. Routers ................................................ 4
5. Security Considerations ...................................... 5
6. IANA Considerations ......................................... 5
7. References .................................................. 5
7.1. Normative References .................................... 5
7.2. Informative References .................................. 5
1. Introduction
Multimedia services can use multiple multicast streams [ITU2009]
which form one multicast session. These services have been provided
using several multicast groups or one multicast group and user level
filtering. The first method is more efficient especially in a
typical heterogeneous network. For services which have been provided
using several multicast groups this document introduces the new
class of IPv6 multicast addresses called "multiple multicast". We
define a multiple multicast as a set of multicast addresses
belonging to one multicast session. Multicast addresses which belong
to the one multiple multicast address follow the same multicast
tree. It allows for identical propagation parameters for each
transmitted stream belonging to one multicast session. It also
simplifies multicast routing.
2. 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 [RFC2119].
Chodorek Expires September 28, 2014 [Page 2]
Internet-Draft Multiple multicast addressing March 2014
3. Multiple multicast addressing
In updates [Maddr] to the IPv6 multicast addressing architecture
[RFC4291] the unicast-prefix-based IPv6 multicast address [RFC3306]
has been updated. The bits 17-20 are for a new flag field 2. The
group ID is a 32 bit field (figure 1):
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+
Figure 1 Updating IPv6 multicast address.
The new class of IPv6 multicast addresses called multiple multicast
expands the current IPv6 multicast addressing architecture. The
group ID is divided into two fields (figure 2). The first one is
session ID (24 bits). The second one is stream ID (8 bits). A value
of 0 is reserved for the field session ID. There is also a value of
0 reserved for the field stream ID.
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 24 | 8 |
+--------+----+----+----+----+------+---------+---------+--------+
|11111111|ff1 |scop|ff2 |rsvd| plen | network | session | stream |
| | | | | | | prefix | ID | ID |
+--------+----+----+----+----+------+---------+---------+--------+
Figure 2 New class of IPv6 multicast address
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|M|
+-+-+-+-+
where:
o "rrr" is for future assignment as additional flag bits,
o M = 1 indicates a multigroup multicast address.
The new class of IPv6 addresses will be indicated by bit M in the
ff2 (flag field 2). If a new multicast session is created a new
session ID is generated. If within the specified session a new
stream is required then a new stream ID is generated.
Chodorek Expires September 28, 2014 [Page 3]
Internet-Draft Multiple multicast addressing March 2014
4. Usage of multiple multicast addressing
There are two main benefits to using multiple multicast addressing:
multimedia layered multicast (hierarchical coding) and multimedia
conference systems [ITU2009]. It is also possible to use the
proposed addressing scheme in large multicast multimedia streaming
services. This addressing scheme simplifies multicast routing and
the management of multiple multicast streams.
4.1. Multimedia layered multicast
A multimedia layered multicast hierarchically encodes multimedia
content into complementary layers and these are transmitted through
the network as separate multicast groups. Using the new addressing
scheme if a sender wants to send a layered multicast to recipients
they must first allocate a new session ID for all streams (layers).
Each layer is allocated a new stream ID. In a typical allocation
scheme for layered transmission the base layer will have the stream
ID set to a value of 1.
4.2. Multimedia conference systems
For the multimedia content of a conference two (audio, video) or
more (audio, video and additional data) multicast streams will be
created. Each of the conference participants will have one session
ID created and for each stream a stream ID is allocated. Typically:
audio stream ID = 1, video stream ID = 2 and additional data will
have stream IDs with higher numbers.
4.3. Multiple content from the one sender
One IPTV service platform operator can sends multiple TV streams. In
IPTV SSM multicast is desired. According to [RFC 3306] the SSM
address sets plen = 0 and sets network prefix = 0. In the proposed
addressing scheme for all transmitted content the service provider
allocates the session ID. For each TV stream the service provider
allocates one or more stream IDs.
4.4. Routers
Routers must recognize multiple multicast addressing. For each
session ID the router builds one common delivery tree. If a user
wants to receive a new stream with a selected stream ID the router
must enable forwarding for it. If a user does not need a specified
stream the router must disable the stream for the specified stream
ID.
Chodorek Expires September 28, 2014 [Page 4]
Internet-Draft Multiple multicast addressing March 2014
5. Security Considerations
Security considerations to be provided.
6. IANA Considerations
This document does not require any action from IANA.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
7.2. Informative References
[ITU2009] ITU-T, "Multicast functions in next generation networks",
ITU-T Recommendation Y.2017, 2009.
[Maddr] Boucadair, M., and Venaas, S., "Updates to the IPv6
Multicast Addressing Architecture", draft-ietf-6man-
multicast-addr-arch-update-04, Work in Progress, March
2014.
Authors' Addresses
Robert R. Chodorek
AGH Univ. of Science and Technology
Al. Mickiewicza 30
30-059 Krakow
Poland
Email: chodorek@agh.edu.pl
Chodorek Expires September 28, 2014 [Page 5]
