idnits 2.17.1 draft-rekhter-mdcs-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5575, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5575, updated by this document, for RFC5378 checks: 2007-08-15) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2013) is 3911 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) ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Jeng 3 Internet-Draft AT&T 4 Updates: 5575 (if approved) J. Haas 5 Intended status: Standards Track Y. Rekhter 6 Expires: January 15, 2014 J. Zhang 7 Juniper Networks 8 July 14, 2013 10 Multicast Distribution Control Signaling 11 draft-rekhter-mdcs-00 13 Abstract 15 This document describes a mechanism whereby the BGP Flow 16 Specification NLRI format may be utilized to distribute multicast 17 Control Plane filters. This mechanism is called Multicast 18 Distribution Control Signaling (MDCS). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 15, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Specification of Requirements . . . . . . . . . . . . . . . . . 3 56 2.1. Multicast Distribution Control Signaling . . . . . . . . . 3 57 2.2. An example of configuration on ERs . . . . . . . . . . . . 6 58 3. Summary of Updates to BGP Flowspec . . . . . . . . . . . . . . 7 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 Consider a content provider that wants to deliver a particular 70 content to a set of customers/subscribers, where the provider and the 71 subscribers are connected by an IP service provider and the content 72 is distributed using multicast connectivity. The content provider 73 may wish to restrict delivery of the content to a subset of the 74 subscribers in a centralized fashion. 76 For the purpose of this document we assume that a content provider 77 consists of one or more Content Servers, and one or more Content 78 Distribution Controllers. While this document assumes communication 79 between Content Servers and Content Distribution Controllers, the 80 procedures for implementing such communication is outside the scope 81 of this document. 83 Content Servers are connected to one or more IP service providers 84 (ISPs) that are offering multicast delivery of the content to the 85 subscribers of the content provider. Content providers use these 86 ISPs to deliver content to their subscribers. 88 Subscribers are connected to the Edge Routers (ERs) of the ISP. Note 89 that the multicast connectivity service provided by the ISP extends 90 all the way to the ERs. Such service could be provided by either 91 deploying IP multicast natively, or with some tunneling mechanism 92 like AMT, or by a combination of both within the ISP. However, 93 between the ERs and the subscribers there may, or may not be 94 multicast connectivity. 96 For further information, see [geo-dist]. 98 2. Specification of Requirements 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2.1. Multicast Distribution Control Signaling 106 Multicast distribution control signaling is intended to enforce 107 exclusion/inclusion policies of a content provider, and specifically 108 to prevent a subscriber from accessing a particular multicast channel 109 carrying a particular content provided by the content provider if the 110 subscriber obtained the information about this channel through some 111 illegitimate means. 113 Multicast distribution control signaling for a particular content is 114 originated by Content Distribution Controller(s), and uses BGP Flow 115 Spec [RFC5575] as follows: 117 For a particular content carried over a particular (S, G) multicast 118 flow the Content Distribution Controller responsible for that content 119 originates a BGP Flow Spec route. This route is carried using BGP 120 multi-protocol capabilities [RFC4760] with AFI 1 (for IPv4) or 2 (for 121 IPv6), and the MCAST-FLOWSPEC SAFI. The NLRI of the route carries S 122 in the Source Prefix component (with length of 32 for IPv4 or 128 for 123 IPv6), and G in the Destination Prefix component (with length of 32 124 for IPv4 of 128 for IPv6). 126 This route is ultimately propagated to the ER of the ISP connected to 127 the content provider. 129 An ER that receives BGP Flow Spec routes carrying the multicast 130 distribution control information applies it to PIM and/or IGMP 131 messages the ER receives from the subscribers connected to that ER. 132 (Note that such IGMP messages may be encapsulated in MDT messages.) 133 Specifically, the ER, based on the information received in the BGP 134 Flow Spec routes, decides whether to accept (or reject) a particular 135 PIM or IGMP Join received on one of its subscriber's ports, as 136 follows: 138 As a Content Distribution Controller originates a BGP Flow Spec route 139 for a particular (S, G) multicast flow, such a route will carry one 140 or more Route Targets [RFC4360], which will ultimately control 141 inclusion/exclusion of that flow on individual ports of ERs that 142 receive this route. 144 Each subscriber port on an ER is associated with one or more zones. 145 For each zone that a port belongs to, the port is provisioned with 146 two sets of RTs associated with that zone - the inclusion set is for 147 allowing to accept PIM or IGMP Join for some content (or to be more 148 precise for the (S, G) flow that carries that content), and the 149 exclusion set is for disallowing to accept PIM or IGMP Joins for some 150 other content. All those RTs (of all subscribers ports) control 151 import of BGP Flow Spec routes by the ER. 153 Note that the RTs associated with the subscriber port are ordered. 154 This permits configurations that accommodate include or exclude 155 policies of zones of differing geographic size or overlap. See below 156 for an example. 158 If the RTs carried by a given BGP Flow Spec route carrying multicast 159 distribution control signaling match the inclusion set of RTs 160 associated with a given port on an ER, then PIM or IGMP Joins for the 161 (S, G) carried in the route and received from the subscriber(s) 162 connected to that port SHOULD be accepted by the ER. If the RTs 163 carried by the route match the exclusion set, then PIM or IGMP Joins 164 for the (S, G) carried in the route MUST NOT be accepted when 165 received from the subscriber(s) connected to that port. (See example 166 section below.) 168 Each subscriber port on an ER is provisioned with the default 169 inclusion/exclusion policy that controls acceptance (or rejection) of 170 PIM or IGMP Join messages in the absence of any multicast 171 distribution control signaling. In the former case, in the absence 172 of any multicast distribution signaling, subscribers connected to 173 that port may receive any multicast flow. In the latter case, in the 174 absence of any multicast distribution control signaling, subscribers 175 connected to that port may receive no multicast flows. BGP Flow Spec 176 routes that carry multicast distribution control signaling modify 177 such default behavior. 179 Once a Content Distribution Controller determines that a particular 180 (S, G) multicast stream no longer used to carry a particular content, 181 the Content Distribution Controller withdraws the BGP Flow Spec route 182 that carries multicast distribution control information for that 183 content. 185 Note that while [RFC5575] uses the information carried in BGP Flow 186 Spec routes for the purpose of Data Plane filtering, this document 187 uses this information for the purpose of filtering multicast Control 188 Plane traffic (PIM or IGMP). 190 To constrain the distribution of BGP Flow Spec routes that carry 191 multicast distribution control information to only the relevant ERs, 192 the ERs MAY originate Route Target Constraint (RTC) routes that carry 193 the RTs that control import of the BGP Flow Spec routes on these ERs. 195 To constrain the import of these RTC routes to only the Content 196 Distribution Controllers, the Content Distribution Controllers are 197 configured with one or more RTs. These RTs control import by the 198 Content Distribution Controller(s) of the RTC routes originated by 199 the ERs. Furthermore, the Content Distribution Controllers MAY 200 themselves originate RTC routes that carry the import RT(s) 201 configured on these Content Distribution Controllers, and that 202 control import of RTC routes by these Content Distribution 203 Controllers. 205 This document assumes that if a given content provider has multiple 206 Content Distribution Controllers, then all of these Controllers are 207 provisioned with the same RT(s) that control import of the RTC routes 208 originated by the ERs. Furthermore, this document assumes that if a 209 given ISP is providing (multicast) connectivity service to more than 210 one content provider, then the RTC routes originated by any of the 211 ERs of that ISP MUST carry the set union of the import RTs used by 212 the Content Distribution Controllers of all of these content 213 providers. 215 RTs carried by routes with AFI 1 and MCAST-FLOWSPEC SAFI SHOULD NOT 216 be re-used by routes with any other AFI and/or SAFI. Likewise, RTs 217 carried by routes wiht AFI 2 and MCAST-FLOWSPEC SAFI SHOULD NOT be 218 re-used by routes with any other AFI and/or SAFI. Furthermore, RTs 219 carried by routes with AFI 1 and SAFI 132 (AFI/SAFI used by RTC 220 routes) SHOULD NOT be re-used by routes with any other AFI and/or 221 SAFI. 223 Note that while [RFC4684] uses RTC routes to constrain distribution 224 of VPN-IP routes [RFC4364], this document uses RTC routes to 225 constrain distribution of BGP Flow Spec routes, and also to 226 (recursively) constrain distribution of RTC routes themselves. 228 2.2. An example of configuration on ERs 230 Consider an ER in Manhattan that has a port that is provisioned with 231 the following import RTs: 233 236 When the ER receives a Flow Spec route with RTs, the ER first try to match "include- 238 manhattan" or "exclude-manhattan" (the first ones on the list) - and 239 the result is "include-manhattan". Therefore, the (S, G) carried in 240 the Flow Spec route is allowed on that port of the ER. 242 Consider another ER in Boston that has a port that is provisioned 243 with the following import RTs: 245 248 The above mentioned Flow Spec route will be imported (due to the 249 include-usa RT), and will result in the (S, G) carried in the flow 250 Spec route to be allowed on that port of the ER. 252 Now consider a different Flow Spec route with the RTs. The (S, G) carried 254 in the route will be disallowed in Manhattan, allowed in Boston, and 255 allowed in Queens (as the route will match the "include-nyc" RT). 257 3. Summary of Updates to BGP Flowspec 259 As described above, this document makes small changes to the BGP Flow 260 Specifcation mechanism when carried using the MCAST-FLOWSPEC SAFI: 262 o Destination addresses will contain a multicast group rather than a 263 unicast destination. 265 o Flow specification routes for this SAFI are used for filtering 266 multicast Control Plane traffic rather than the matching multicast 267 traffic itself. 269 o Flow specification routes for this SAFI will carry one or more 270 Route Target extended communities. 272 o Flow specification component types not applicable to signaling 273 multicast Control Plane traffic MUST be ignored. E.g.: ICMP type, 274 ICMP code, TCP flags, Fragment. 276 4. IANA Considerations 278 This document defines a new BGP Subsequent Address Family Identifier 279 (SAFI) value, MCAST-FLOWSPEC. The authors request assignment of a 280 value from the First Come, First Served portion of this registry. 282 5. Security Considerations 284 TBD 286 6. Acknowledgements 288 The authors would like to thank Han Nguyen for his contributions to 289 this document. 291 7. References 293 7.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 299 Communities Attribute", RFC 4360, February 2006. 301 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 302 R., Patel, K., and J. Guichard, "Constrained Route 303 Distribution for Border Gateway Protocol/MultiProtocol 304 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 305 Private Networks (VPNs)", RFC 4684, November 2006. 307 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 308 "Multiprotocol Extensions for BGP-4", RFC 4760, 309 January 2007. 311 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 312 and D. McPherson, "Dissemination of Flow Specification 313 Rules", RFC 5575, August 2009. 315 7.2. Informative References 317 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 318 Networks (VPNs)", RFC 4364, February 2006. 320 [geo-dist] 321 Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast 322 Geo Distribution Control", 323 draft-rekhter-geo-distribution-control-03.txt (work in 324 progress), 2013. 326 Authors' Addresses 328 Huajin Jeng 329 AT&T 331 Email: hj2387@att.com 333 Jeffrey Haas 334 Juniper Networks 335 1194 N. Mathida Ave. 336 Sunnyvale, CA 94089 337 US 339 Email: jhaas@juniper.net 340 Yakov Rekhter 341 Juniper Networks 342 1194 N. Mathida Ave. 343 Sunnyvale, CA 94089 344 US 346 Email: yakov@juniper.net 348 Jeffrey (Zhaohui) Zhang 349 Juniper Networks 350 1194 N. Mathida Ave. 351 Sunnyvale, CA 94089 352 US 354 Email: zzhang@juniper.net