idnits 2.17.1 draft-chodorek-6man-multigroup-multicast-addr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2017) is 2636 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 3306' is mentioned on line 161, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R.R. Chodorek 2 Internet Draft AGH Univ. of Science and Technology 3 Intended status: Standards Track February 7, 2017 4 Expires: August 7, 2017 6 Multiple multicast addressing architecture 7 draft-chodorek-6man-multigroup-multicast-addr-04 9 Abstract 11 This document introduces a new class of IPv6 multicast addresses 12 called "multiple multicast". We define multiple multicast as a set 13 of multicast addresses belonging to one multicast session. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on August 7, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction ................................................ 2 56 2. Conventions used in this document ........................... 2 57 3. Multiple multicast addressing ............................... 3 58 4. Usage of multiple multicast addressing ...................... 3 59 4.1. Multimedia layered multicast ........................... 4 60 4.2. Multimedia conference systems .......................... 4 61 4.3. Multiple content from the one sender ................... 4 62 4.4. Routers ................................................ 4 63 5. Security Considerations ..................................... 4 64 6. IANA Considerations ......................................... 5 65 7. References .................................................. 5 66 7.1. Normative References ................................... 5 67 7.2. Informative References ................................. 5 69 1. Introduction 71 Multimedia services can use multiple multicast streams [ITU2009] 72 which form one multicast session. These services have been provided 73 using several multicast groups or one multicast group and user level 74 filtering. For services which have been provided using several 75 multicast groups this document introduces the new class of IPv6 76 multicast addresses called "multiple multicast". We define a 77 multiple multicast as a set of multicast addresses belonging to one 78 multicast session. Multicast addresses which belong to the one 79 multiple multicast address follow the same multicast tree. It allows 80 for identical propagation parameters for each transmitted stream 81 belonging to one multicast session. It also simplifies multicast 82 routing and the management of multiple multicast streams. 84 The new class of IPv6 multicast addresses expands the current IPv6 85 multicast addressing architecture [RFC4291]. 87 2. Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [RFC2119]. 93 3. Multiple multicast addressing 95 The new class of IPv6 multicast addresses expands the unicast- 96 prefix-based IPv6 multicast address [RFC7371][RFC3306]. 98 The group ID is divided into two fields (Figure 1). The first one is 99 session ID (20 bits). The second one is stream ID (12 bits). 101 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 20 | 12 | 102 +--------+----+----+----+----+------+---------+---------+--------+ 103 |11111111|ff1 |scop|ff2 |rsvd| plen | network | session | stream | 104 | | | | | | | prefix | ID | ID | 105 +--------+----+----+----+----+------+---------+---------+--------+ 107 Figure 1 New class of IPv6 multicast address 109 +-+-+-+-+ 110 ff2 (flag field 2) is a set of 4 flags: |r|r|G|r| 111 +-+-+-+-+ 113 where: 115 o "r" bits is for future assignment and MUST each be set to 0, 117 o G = 1 indicates a multigroup multicast address. 119 The new class of IPv6 addresses will be indicated by bit G in the 120 ff2 (flag field 2). If a new multicast session is created a new 121 session ID is generated. If within the specified session a new 122 stream is required then a new stream ID is generated. 124 A value of 0 is reserved for the field session ID. There is also a 125 value of 0 reserved for the field stream ID. 127 4. Usage of multiple multicast addressing 129 There are two main benefits to using multiple multicast addressing: 130 multimedia layered multicast (hierarchical coding) and multimedia 131 conference systems [ITU2009]. It is also possible to use the 132 proposed addressing scheme in large multicast multimedia streaming 133 services. This addressing scheme simplifies multicast routing and 134 the management of multiple multicast streams. 136 4.1. Multimedia layered multicast 138 A multimedia layered multicast hierarchically encodes multimedia 139 content into complementary layers and these are transmitted through 140 the network as separate multicast groups. Using the new addressing 141 scheme if a sender wants to send a layered multicast to recipients 142 they must first allocate a new session ID for all streams (layers). 143 Each layer is allocated a new stream ID. In a typical allocation 144 scheme for layered transmission the base layer will have the stream 145 ID set to a value of 1. 147 4.2. Multimedia conference systems 149 For the multimedia content of a conference two (audio, video) or 150 more (audio, video and additional data) multicast streams will be 151 created. Each of the conference participants will have one session 152 ID created and for each stream a stream ID is allocated. Typically: 153 base audio stream ID = 1, video stream ID = 2 and additional data 154 will have stream IDs with higher numbers. 156 4.3. Multiple content from the one sender 158 One IPTV service platform operator can sends multiple TV streams 159 (e.g. different TV channels or two or more channels that offer the 160 same content but in different resolutions and/or formats). In IPTV 161 SSM multicast is desired. According to [RFC 3306] the SSM address 162 sets plen = 0 and sets network prefix = 0. In the proposed 163 addressing scheme for all transmitted content the service provider 164 allocates the session ID. For each TV stream the service provider 165 allocates one or more stream IDs. 167 4.4. Routers 169 Routers must recognize multiple multicast addressing. For each 170 session ID the router builds one common delivery tree (common 171 multicast delivery tree is essential to provide multicast-based 172 congestion avoidance [Cho2004]). If a user wants to receive a new 173 stream with a selected stream ID the router must enable forwarding 174 for it. If a user does not need a specified stream the router must 175 disable the stream for the specified stream ID. 177 5. Security Considerations 179 The same security considerations as those discussed in [RFC3306] are 180 to be taken into account. 182 6. IANA Considerations 184 This document does not require any action from IANA. 186 7. References 188 7.1. Normative References 190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 191 Requirement Levels", BCP 14, RFC 2119, March 1997. 193 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 194 Multicast Addresses", RFC 3306, August 2002. 196 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 197 Architecture", RFC 4291, February 2006. 199 [RFC7371] Boucadair, M., and Venaas, S., "Updates to the IPv6 200 Multicast Addressing Architecture", RFC 7371, September 201 2014. 203 7.2. Informative References 205 [ITU2009] ITU-T, "Multicast functions in next generation networks", 206 ITU-T Recommendation Y.2017, 2009. 208 [Cho2004] Chodorek, A., and Chodorek, R.R., "Multigroup 209 Communication Using Active Networks Technology", 3rd 210 International Conference on Network Control and 211 Engineering for QoS, Security and Mobility (Net-Con 2004), 212 pp. 315-326, 2004. 214 Authors' Addresses 216 Robert R. Chodorek 217 AGH Univ. of Science and Technology 218 Al. Mickiewicza 30 219 30-059 Krakow 220 Poland 222 Email: chodorek@agh.edu.pl