Network Working Group                                    R.R. Chodorek
Internet Draft                     AGH Univ. of Science and Technology
Intended status: Standards Track                      February 7, 2017
Expires: August 7, 2017



                Multiple multicast addressing architecture
              draft-chodorek-6man-multigroup-multicast-addr-04


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 August 7, 2017.

Copyright Notice

   Copyright (c) 2017 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 August 7, 2017                 [Page 1]


Internet-Draft      Multiple multicast addressing        February 2017


   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 ...................... 3
      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 ..................................... 4
   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. 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 and the management of multiple multicast streams.

   The new class of IPv6 multicast addresses expands the current IPv6
   multicast addressing architecture [RFC4291].

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 August 7, 2017                 [Page 2]


Internet-Draft      Multiple multicast addressing        February 2017


3. Multiple multicast addressing

   The new class of IPv6 multicast addresses expands the unicast-
   prefix-based IPv6 multicast address [RFC7371][RFC3306].

   The group ID is divided into two fields (Figure 1). The first one is
   session ID (20 bits). The second one is stream ID (12 bits).

   |   8    |  4 |  4 |  4 |  4 |   8  |    64   |   20    |   12   |
   +--------+----+----+----+----+------+---------+---------+--------+
   |11111111|ff1 |scop|ff2 |rsvd| plen | network | session | stream |
   |        |    |    |    |    |      | prefix  | ID      | ID     |
   +--------+----+----+----+----+------+---------+---------+--------+

               Figure 1 New class of IPv6 multicast address



                                                  +-+-+-+-+
   ff2 (flag field 2) is a set of 4 flags:        |r|r|G|r|
                                                  +-+-+-+-+

   where:

   o "r" bits is for future assignment and MUST each be set to 0,

   o G = 1 indicates a multigroup multicast address.

   The new class of IPv6 addresses will be indicated by bit G 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.

   A value of 0 is reserved for the field session ID. There is also a
   value of 0 reserved for the field stream ID.

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.





Chodorek               Expires August 7, 2017                 [Page 3]


Internet-Draft      Multiple multicast addressing        February 2017


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:
   base 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
   (e.g. different TV channels or two or more channels that offer the
   same content but in different resolutions and/or formats). 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 (common
   multicast delivery tree is essential to provide multicast-based
   congestion avoidance [Cho2004]). 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.

5. Security Considerations

   The same security considerations as those discussed in [RFC3306] are
   to be taken into account.




Chodorek               Expires August 7, 2017                 [Page 4]


Internet-Draft      Multiple multicast addressing        February 2017




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.

   [RFC7371] Boucadair, M., and Venaas, S., "Updates to the IPv6
             Multicast Addressing Architecture", RFC 7371, September
             2014.

7.2. Informative References

   [ITU2009] ITU-T, "Multicast functions in next generation networks",
             ITU-T Recommendation Y.2017, 2009.

   [Cho2004] Chodorek, A., and Chodorek, R.R., "Multigroup
             Communication Using Active Networks Technology", 3rd
             International Conference on Network Control and
             Engineering for QoS, Security and Mobility (Net-Con 2004),
             pp. 315-326, 2004.



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 August 7, 2017                 [Page 5]