idnits 2.17.1 draft-asaeda-pim-mldproxy-multif-01.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 25, 2013) is 4078 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group H. Asaeda 3 Internet-Draft NICT 4 Expires: August 29, 2013 S. Jeon 5 Institute de Telecomunicacoes 6 February 25, 2013 8 Multiple Upstream Interface Support for IGMP/MLD Proxy 9 draft-asaeda-pim-mldproxy-multif-01 11 Abstract 13 This document describes the way of supporting multiple upstream 14 interfaces for an IGMP/MLD proxy device. The proposed extension 15 enables that an IGMP/MLD proxy device receives multicast packets 16 through multiple upstream interfaces. The upstream interface is 17 selected with manually configured supported address prefixes and 18 interface priority value. A take-over operation switching from an 19 inactive upstream interface to an active upstream interface is also 20 considered. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 29, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Per-Channel Load Balancing . . . . . . . . . . . . . . . . . . 4 59 4. Candidate Upstream Interface Configuration . . . . . . . . . . 5 60 4.1. Supported Address Prefix . . . . . . . . . . . . . . . . . 5 61 4.2. Interface Priority . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Default Interface . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 The Internet Group Management Protocol (IGMP) [1][2] for IPv4 and the 71 Multicast Listener Discovery Protocol (MLD) [3][2] for IPv6 are the 72 standard protocols for hosts to initiate joining or leaving of 73 multicast sessions. A proxy device performing IGMP/MLD-based 74 forwarding (as known as IGMP/MLD proxy) [4] maintains multicast 75 membership information by IGMP/MLD protocols on the downstream 76 interfaces and sends IGMP/MLD membership report messages via the 77 upstream interface to the upstream multicast routers when the 78 membership information changes (e.g., by receiving solicited/ 79 unsolicited report messages). The proxy device forwards appropriate 80 multicast packets received on its upstream interface to each 81 downstream interface based on the downstream interface's 82 subscriptions. 84 According to the specification of [4], an IGMP/MLD proxy has *a 85 single* upstream interface and one or more downstream interfaces. 86 The multicast forwarding tree must be manually configured by 87 designating upstream and downstream interfaces on an IGMP/MLD proxy 88 device, and the root of the tree is expected to be connected to a 89 wider multicast infrastructure. An IGMP/MLD proxy device hence 90 performs the router portion of the IGMP or MLD protocol on its 91 downstream interfaces, and the host portion of IGMP/MLD on its 92 upstream interface. The proxy device must not perform the router 93 portion of IGMP/MLD on its upstream interface. 95 On the other hand, there is a scenario in which an IGMP/MLD proxy 96 device enables multiple upstream interfaces and receives multicast 97 packets through these interfaces. For example, a proxy device having 98 more than one interface may want to access to different networks, 99 such as Internet and Intranet. Or, a proxy device having wired link 100 (e.g., ethernet) and high-speed wireless link (e.g., WiMAX or LTE) 101 may want to have the capability to connect to the Internet through 102 both links. These proxy devices shall receive multicast packets from 103 the different upstream interfaces and forward to the downstream 104 interface(s). 106 This document adds the way to manually configure candidate upstream 107 interfaces for an IGMP/MLD proxy device and select "one" single 108 upstream interface from candidate upstream interfaces per session/ 109 channel. When the selected upstream interface is down or disabled, 110 one of the other candidate upstream interfaces takes over the 111 upstream interface (if configured). This enables "per-channel load 112 balancing". 114 Note that this document only specifies the way to configure per- 115 channel load balancing; it does not specify any intelligent 116 mechanism/algorithm (e.g., based on link or network condition/usage) 117 or threshold value to select an upstream interface from candidate 118 upstream interfaces to improve data reception quality. Also, an 119 IGMP/MLD proxy device does not select multiple upstream interfaces 120 for the same channels/sessions simultaneously; enabling redundant 121 paths to receive duplicate packets via multiple upstream interfaces 122 to improve data reception quality or robustness for a session/channel 123 is out of scope of this document. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 128 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 129 this document are to be interpreted as described in RFC 2119 [5]. 131 In addition, the following terms are used in this document. 133 Upstream interface (or selected upstream interface): 134 A proxy device's interface in the direction of the root of the 135 multicast forwarding tree. An upstream interface is selected by 136 either manual or automatic configuration. 138 Downstream interface: 139 Each of a proxy device's interfaces that is not in the direction of 140 the root of the multicast forwarding tree. 142 Candidate upstream interface: 143 An interface that potentially becomes an upstream interface of the 144 proxy device. Candidate upstream interfaces are manually set up on 145 an IGMP/MLD proxy. 147 Supported address prefix: 148 The supported address prefix is the address prefix for which a 149 candidate upstream interface supposes to be an upstream interface. 150 The supported source address prefix and the supported multicast 151 address prefix an IGMP/MLD proxy device can configure. The supported 152 address prefix in this document means both source and multicast 153 address prefixes, unless otherwise specified. 155 3. Per-Channel Load Balancing 157 An IGMP/MLD proxy device enables "per-channel load balancing" using 158 multiple upstream interfaces to receive different multicast sessions/ 159 channel through the different upstream interfaces. Per-channel load 160 balancing makes an IGMP/MLD proxy device select "one" single upstream 161 interface from candidate upstream interfaces per session/channel, 162 based on the configurations, which will be described in Section 4. 164 If an IGMP proxy recognizes that an adjacent upstream router is not 165 working, the selected upstream interface attached to that router can 166 be taken over with the different candidate upstream interface. Or, 167 if the selected upstream interface is going down, the proxy would 168 switch from the inactive interface to the other active upstream 169 interface. This "take-over operation" recursively examines the 170 configurations of the candidate upstream interfaces (except the 171 disabled interface) and decides a new upstream interface from them. 173 Whether the upstream router is active or not would be decided by 174 checking a link condition or IGMP/MLD query message transmission. 175 However, this document does not describe how an IGMP/MLD proxy can 176 detect the upstream router's condition and when it takes that 177 interface over the different candidate upstream interface. 179 The take-over operation is enabled by default. When it is disabled 180 (by operation), even if no data comes from the selected upstream 181 interface, the IGMP/MLD proxy device keeps using that interface as 182 the upstream interface for the corresponding sessions/channels. 184 Per-channel load balancing does not implement duplicate packet 185 reception from redundant paths using multiple upstream interfaces to 186 improve data reception quality or robustness for a session/channel; 187 therefore IGMP/MLD report messages containing the same IGMP/MLD 188 records are not transmitted from different upstream interfaces 189 simultaneously. 191 4. Candidate Upstream Interface Configuration 193 Candidate upstream interfaces are the interfaces from which an IGMP/ 194 MLD proxy device selects as an upstream interface. They are manually 195 enabled. The upstream interface selection is done based on 196 "supported address prefix" and "interface priority" value. 198 4.1. Supported Address Prefix 200 An IGMP/MLD proxy device MAY configure the "supported address prefix" 201 for each candidate upstream interface. A proxy selects an upstream 202 interface from its candidate upstream interfaces based on the 203 configured supported address prefix. The supported address prefix is 204 manually configured. The supported address prefix consists of the 205 following information: 207 (source address prefix, multicast address prefix) 209 When the proxy device transmits an IGMP/MLD report message, it 210 examines the source and multicast addresses in the IGMP/MLD records 211 of the report message and transmits the appropriate IGMP/MLD report 212 message(s) from the selected upstream interface(s) that are 213 configured with the range of the supported source and multicast 214 address prefixes. 216 The default values of both source and multicast address prefixes are 217 a wildcard. If no address prefix value is configured on a candidate 218 upstream interface, the default value is implicitly set up for the 219 candidate upstream interface. The wildcard multicast address prefix 220 is represented by the entire multicast address range (i.e., 221 '224.0.0.0/4' for IPv4 or 'ff00::/8' for IPv6). The wildcard source 222 address prefix is represented by any host. If the default value is 223 set up on a candidate upstream interface, the decision whether the 224 candidate upstream interface is selected as the upstream interface or 225 not is made by the "interface priority" value described in 226 Section 4.2. 228 The same address prefix may be configured on different candidate 229 upstream interfaces. As well as the above-mentioned default 230 configuration, when the same address prefix is configured on 231 different candidate upstream interfaces, an upstream interface for 232 that address prefix is selected based on each interface priority 233 value described in Section 4.2. 235 For upstream interface selection, source address prefix takes 236 priority over multicast address prefix. This avoids conflict of 237 upstream interface selection. For example, consider the case that an 238 IGMP/MLD proxy device has a configuration with source address prefix 239 S_p for the candidate upstream interface A and multicast address 240 prefix G_p for the candidate upstream interface B. When it deals with 241 an IGMP/MLD record whose source address, let's say S, is in the range 242 of S_p, and whose multicast address, let's say G, is in the range of 243 G_p, the proxy device selects the candidate upstream interface A, 244 which supports the source address prefix, as the upstream interface, 245 and transmits the (S,G) record via the interface A. 247 Obviously, an IGMP/MLD proxy selects a candidate upstream interface 248 having supported source and multicast address prefixes that include 249 both source and multicast address, rather than the other one whose 250 supported source and multicast address prefixes includes either 251 source or multicast address. 253 4.2. Interface Priority 255 An IGMP/MLD proxy device MAY configure the "interface priority" value 256 for each candidate upstream interface. It is an integer value and 257 manually configured. The default value of the interface priority is 258 the lowest value. 260 The interface priority value effects only when the following 261 conditions are satisfied. 263 o None of the candidate upstream interfaces configure the supported 264 address prefix. 266 o Both source and multicast addresses are included in the supported 267 address prefixes configured by more than one candidate upstream 268 interface. 270 o Neither source nor multicast address is included in the supported 271 address prefixes configured by any of the candidate upstream 272 interfaces. 274 o The supported source address prefix is not configured or does not 275 include the source address, but (on the other hand) the multicast 276 address is included in the supported multicast address prefix 277 configured by more than one candidate upstream interface. 279 In these conditions, the candidate upstream interface with the 280 highest priority is chosen as the upstream interface. 282 4.3. Default Interface 284 In the following conditions, the candidate upstream interface whose 285 IPv4/v6 address is lowest is selected as the upstream interface for 286 that session/channel. 288 o None of the candidate upstream interfaces configure the supported 289 address prefix and interface priority value. 291 o Both source and multicast addresses are included in the supported 292 address prefixes configured by more than one candidate upstream 293 interfaces, and these candidate upstream interfaces' priorities 294 are identical. 296 o Neither source nor multicast address is included in the supported 297 address prefixes configured by any of the candidate upstream 298 interfaces, and all candidate upstream interfaces' priorities are 299 identical. 301 o The supported source address prefix is not configured or does not 302 include the source address, and the multicast address is included 303 in the supported multicast address prefix configured by more than 304 one candidate upstream interface, yet these candidate upstream 305 interfaces' priorities are identical. 307 5. IANA Considerations 309 This document has no actions for IANA. 311 6. Security Considerations 313 This document neither provides new functions nor modifies the 314 standard functions defined in [1][3][2]. Therefore there is no 315 additional security consideration provided for these protocols. 317 7. Normative References 319 [1] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 320 Thyagarajan, "Internet Group Management Protocol, Version 3", 321 RFC 3376, October 2002. 323 [2] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 324 Management Protocol Version 3 (IGMPv3) and Multicast Listener 325 Discovery Version 2 (MLDv2) Protocols", RFC 5790, February 2010. 327 [3] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 328 (MLDv2) for IPv6", RFC 3810, June 2004. 330 [4] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 331 Group Management Protocol (IGMP) / Multicast Listener Discovery 332 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 333 RFC 4605, August 2006. 335 [5] Bradner, S., "Key words for use in RFCs to indicate requirement 336 levels", RFC 2119, March 1997. 338 Authors' Addresses 340 Hitoshi Asaeda 341 National Institute of Information and Communications Technology (NICT) 342 Network Architecture Laboratory 343 4-2-1 Nukui-Kitamachi 344 Koganei, Tokyo 184-8795 345 Japan 347 Email: asaeda@nict.go.jp 349 Seil Jeon 350 Institute de Telecomunicacoes 351 Campus Universitario de Santiago 352 Aveiro 3810-193 353 Portugal 355 Email: seiljeon@av.it.pt