idnits 2.17.1 draft-ietf-bier-use-cases-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 27, 2015) is 3258 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-04 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-01 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Kumar 3 Internet-Draft R. Asati 4 Intended status: Informational Cisco 5 Expires: October 29, 2015 M. Chen 6 X. Xu 7 Huawei 8 A. Dolganow 9 Alcatel-Lucent 10 T. Przygienda 11 Ericsson 12 A. Gulko 13 Thomson Reuters 14 D. Robinson 15 id3as-company Ltd 16 April 27, 2015 18 BIER Use Cases 19 draft-ietf-bier-use-cases-00.txt 21 Abstract 23 Bit Index Explicit Replication (BIER) is an architecture that 24 provides optimal multicast forwarding through a "BIER domain" without 25 requiring intermediate routers to maintain any multicast related per- 26 flow state. BIER also does not require any explicit tree-building 27 protocol for its operation. A multicast data packet enters a BIER 28 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 29 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 30 The BFIR router adds a BIER header to the packet. The BIER header 31 contains a bit-string in which each bit represents exactly one BFER 32 to forward the packet to. The set of BFERs to which the multicast 33 packet needs to be forwarded is expressed by setting the bits that 34 correspond to those routers in the BIER header. 36 This document describes some of the use-cases for BIER. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on October 29, 2015. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 74 3. BIER Use Cases . . . . . . . . . . . . . . . . . . . . . . . 3 75 3.1. Multicast in L3VPN Networks . . . . . . . . . . . . . . . 3 76 3.2. BUM in EVPN . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.3. IPTV and OTT Services . . . . . . . . . . . . . . . . . . 5 78 3.4. Multi-service, converged L3VPN network . . . . . . . . . 6 79 3.5. Control-plane simplification and SDN-controlled networks 7 80 3.6. Data center Virtualization/Overlay . . . . . . . . . . . 7 81 3.7. Financial Services . . . . . . . . . . . . . . . . . . . 8 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 87 7.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 Bit Index Explicit Replication (BIER) 93 [I-D.wijnands-bier-architecture] is an architecture that provides 94 optimal multicast forwarding through a "BIER domain" without 95 requiring intermediate routers to maintain any multicast related per- 96 flow state. BIER also does not require any explicit tree-building 97 protocol for its operation. A multicast data packet enters a BIER 98 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 99 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 100 The BFIR router adds a BIER header to the packet. The BIER header 101 contains a bit-string in which each bit represents exactly one BFER 102 to forward the packet to. The set of BFERs to which the multicast 103 packet needs to be forwarded is expressed by setting the bits that 104 correspond to those routers in the BIER header. 106 The obvious advantage of BIER is that there is no per flow multicast 107 state in the core of the network and there is no tree building 108 protocol that sets up tree on demand based on users joining a 109 multicast flow. In that sense, BIER is potentially applicable to 110 many services where Multicast is used and not limited to the examples 111 described in this draft. In this document we are describing a few 112 use-cases where BIER could provide benefit over using existing 113 mechanisms. 115 2. Specification of Requirements 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. BIER Use Cases 123 3.1. Multicast in L3VPN Networks 125 The Multicast L3VPN architecture [RFC6513] describes many different 126 profiles in order to transport L3 Multicast across a providers 127 network. Each profile has its own different tradeoffs (see section 128 2.1 [RFC6513]). When using "Multidirectional Inclusive" "Provider 129 Multicast Service Interface" (MI-PMSI) an efficient tree is build per 130 VPN, but causes flooding of egress PE's that are part of the VPN, but 131 have not joined a particular C-multicast flow. This problem can be 132 solved with the "Selective" PMSI to build a special tree for only 133 those PE's that have joined the C-multicast flow for that specific 134 VPN. The more S-PMSI's, the less bandwidth is wasted due to 135 flooding, but causes more state to be created in the providers 136 network. This is a typical problem network operators are faced with 137 by finding the right balance between the amount of state carried in 138 the network and how much flooding (waste of bandwidth) is acceptable. 139 Some of the complexity with L3VPN's comes due to providing different 140 profiles to accommodate these trade-offs. 142 With BIER there is no trade-off between State and Flooding. Since 143 the receiver information is explicitly carried within the packet, 144 there is no need to build S-PMSI's to deliver multicast to a sub-set 145 of the VPN egress PE's. Due to that behaviour, there is no need for 146 S-PMSI's. 148 Mi-PMSI's and S-PMSI's are also used to provide the VPN context to 149 the Egress PE router that receives the multicast packet. Also, in 150 some MVPN profiles it is also required to know which Ingress PE 151 forwarded the packet. Based on the PMSI the packet is received from, 152 the target VPN is determined. This also means there is a requirement 153 to have a least a PMSI per VPN or per VPN/Ingress PE. This means the 154 amount of state created in the network is proportional to the VPN and 155 ingress PE's. Creating PMSI state per VPN can be prevented by 156 applying the procedures as documented in [RFC5331]. This however has 157 not been very much adopted/implemented due to the excessive flooding 158 it would cause to Egress PE's since *all* VPN multicast packets are 159 forwarded to *all* PE's that have one or more VPN's attached to it. 161 With BIER, the destination PE's are identified in the multicast 162 packet, so there is no flooding concern when implementing [RFC5331]. 163 For that reason there is no need to create multiple BIER domain's per 164 VPN, the VPN context can be carry in the multicast packet using the 165 procedures as defined in [RFC5331]. Also see 166 [I-D.rosen-l3vpn-mvpn-bier] for more information. 168 With BIER only a few MVPN profiles will remain relevant, simplifying 169 the operational cost and making it easier to be interoperable among 170 different vendors. 172 3.2. BUM in EVPN 174 The current widespread adoption of L2VPN services [RFC4664], 175 especially the upcoming EVPN solution [I-D.ietf-l2vpn-evpn] which 176 transgresses many limitations of VPLS, introduces the need for an 177 efficient mechanism to replicate broadcast, unknown and multicast 178 (BUM) traffic towards the PEs that participate in the same EVPN 179 instances (EVIs). As simplest deployable mechanism, ingress 180 replication is used but poses accordingly a high burden on the 181 ingress node as well as saturating the underlying links with many 182 copies of the same frame headed to different PEs. Fortunately 183 enough, EVPN signals internally P-Multicast Service Interface (PMSI) 184 [RFC6513] attribute to establish transport for BUM frames and with 185 that allows to deploy a plethora of multicast replication services 186 that the underlying network layer can provide. It is therefore 187 relatively simple to deploy BIER P-Tunnels for EVPN and with that 188 distribute BUM traffic without building of P-router state in the core 189 required by PIM, mLDP or comparable solutions. 191 Specifically, the same I-PMSI attribute suggested for mVPN can be 192 used easily in EVPN and given EVPN can multiplex and disassociate BUM 193 frames on p2mp and mp2mp trees using upstream assigned labels, BIER 194 P-Tunnel will support BUM flooding for any number of EVIs over a 195 single sub-domain for maximum scalability but allow at the other 196 extreme of the spectrum to use a single BIER sub-domain per EVI if 197 such a deployment is necessary. 199 Multiplexing EVIs onto the same PMSI forces the PMSI to span more 200 than the necessary number of PEs normally, i.e. the union of all PEs 201 participating in the EVIs multiplexed on the PMSI. Given the 202 properties of BIER it is however possible to encode in the receiver 203 bitmask only the PEs that participate in the EVI the BUM frame 204 targets. In a sense BIER is an inclusive as well as a selective tree 205 and can allow to deliver the frame to only the set of receivers 206 interested in a frame even though many others participate in the same 207 PMSI. 209 As another significant advantage, it is imaginable that the same BIER 210 tunnel needed for BUM frames can optimize the delivery of the 211 multicast frames though the signaling of group memberships for the 212 PEs involved has not been specified as of date. 214 3.3. IPTV and OTT Services 216 IPTV is a service, well known for its characteristics of allowing 217 both live and on-demand delivery of media traffic over end-to-end 218 Managed IP network. 220 Over The Top (OTT) is a similar service, well known for its 221 characteristics of allowing live and on-demand delivery of media 222 traffic between IP domains, where the source is often on an external 223 network relative to the receivers. 225 Content Delivery Networks (CDN) operators provide layer 4 226 applications, and often some degree of managed layer 3 IP network, 227 that enable media to be securely and reliably delivered to many 228 receivers. In some models they may place applications within third 229 party networks, or they may place those applications at the edges of 230 their own managed network peerings and similar inter-domain 231 connections. CDNs provide capabilities to help publishers scale to 232 meet large audience demand. Their applications are not limited to 233 audio and video delivery, but may include static and dynamic web 234 content, or optimized delivery for Massive Multiplayer Gaming and 235 similar. Most publishers will use a CDN for public Internet 236 delivery, and some publishers will use a CDN internally within their 237 IPTV networks to resolve layer 4 complexity. 239 In a typical IPTV environment the egress routers connecting to the 240 receivers will build the tree towards the ingress router connecting 241 to the IPTV servers. The egress routers would rely on IGMP/MLD 242 (static or dynamic) to learn about the receiver's interest in one or 243 more multicast group/channels. Interestingly, BIER could allows 244 provisioning any new multicast group/channel by only modifying the 245 channel mapping on ingress routers. This is deemed beneficial for 246 the linear IPTV video broadcasting in which every receivers behind 247 every egress PE routers would receive the IPTV video traffic. 249 With BIER in IPTV environment, there is no need of tree building from 250 egress to ingress. Further, any addition of new channel or new 251 egress routers can be directly controlled from ingress router. When 252 a new channel is included, the multicast group is mapped to Bit 253 string that includes all egress routers. Ingress router would start 254 sending the new channel and deliver it to all egress routers. As it 255 can be observed, there is no need for static IGMP provisioning in 256 each egress routers whenever a new channel/stream is added. Instead, 257 it can be controlled from ingress router itself by configuring the 258 new group to Bit Mask mapping on ingress router. 260 With BIER in OTT environment, these edge routers in CDN domain 261 terminating the OTT user session connect to the Ingress BIER routers 262 connecting content provider domains or a local cache server and 263 leverage the scalability benefit that BIER could provide. This may 264 rely on MBGP interoperation (or similar) between the egress of one 265 domain and the ingress of the next domain, or some other SDN control 266 plane may prove a more effective and simpler way to deploy BIER. For 267 a single CDN operator this could be well managed in the Layer 4 268 applications that they provide and it may be that the initial 269 receiver in a remote domain is actually an application operated by 270 the CDN which in turn acts as a source for the Ingress BIER router in 271 that remote domain, and by doing so keeps the BIER more descrete on a 272 domain by domain basis. 274 3.4. Multi-service, converged L3VPN network 276 Increasingly operators deploy single networks for multiple-services. 277 For example a single Metro Core network could be deployed to provide 278 Residential IPTV retail service, residential IPTV wholesale service, 279 and business L3VPN service with multicast. It may often be desired 280 by an operator to use a single architecture to deliver multicast for 281 all of those services. In some cases, governing regulations may 282 additionally require same service capabilities for both wholesale and 283 retail multicast services. To meet those requirements, some 284 operators use multicast architecture as defined in [RFC5331]. 285 However, the need to support many L3VPNs, with some of those L3VPNs 286 scaling to hundreds of egress PE's and thousands of C-multicast 287 flows, make scaling/efficiency issues defined in earlier sections of 288 this document even more prevalent. Additionally support for ten's of 289 millions of BGP multicast A-D and join routes alone could be required 290 in such networks with all consequences such a scale brings. 292 With BIER, again there is no need of tree building from egress to 293 ingress for each L3VPN or individual or group of c-multicast flows. 294 As described earlier on, any addition of a new IPTV channel or new 295 egress router can be directly controlled from ingress router and 296 there is no flooding concern when implementing [RFC5331]. 298 3.5. Control-plane simplification and SDN-controlled networks 300 With the advent of Software Defined Networking, some operators are 301 looking at various ways to reduce the overall cost of providing 302 networking services including multicast delivery. Some of the 303 alternatives being consider include minimizing capex cost through 304 deployment of network-elements with simplified control plane 305 function, minimizing operational cost by reducing control protocols 306 required to achieve a particular service, etc. Segment routing as 307 described in [I-D.ietf-spring-segment-routing] provides a solution 308 that could be used to provide simplified control-plane architecture 309 for unicast traffic. With Segment routing deployed for unicast, a 310 solution that simplifies control-plane for multicast would thus also 311 be required, or operational and capex cost reductions will not be 312 achieved to their full potential. 314 With BIER, there is no longer a need to run control protocols 315 required to build a distribution tree. If L3VPN with multicast, for 316 example, is deployed using [RFC5331] with MPLS in P-instance, the 317 MPLS control plane would no longer be required. BIER also allows 318 migration of C-multicast flows from non-BIER to BIER-based 319 architecture, which makes transition to control-plane simplified 320 network simpler to operationalize. Finally, for operators, who would 321 desire centralized, offloaded control plane, multicast overlay as 322 well as BIER forwarding could migrate to controller-based 323 programming. 325 3.6. Data center Virtualization/Overlay 327 Virtual eXtensible Local Area Network (VXLAN) [RFC7348] is a kind of 328 network virtualization overlay technology which is intended for 329 multi-tenancy data center networks. To emulate a layer2 flooding 330 domain across the layer3 underlay, it requires to have a mapping 331 between the VXLAN Virtual Network Instance (VNI) and the IP multicast 332 group in a ratio of 1:1 or n:1. In other words, it requires to 333 enable the multicast capability in the underlay. For instance, it 334 requires to enable PIM-SM [RFC4601] or PIM-BIDIR [RFC5015] multicast 335 routing protocol in the underlay. VXLAN is designed to support 16M 336 VNIs at maximum. In the mapping ratio of 1:1, it would require 16M 337 multicast groups in the underlay which would become a significant 338 challenge to both the control plane and the data plane of the data 339 center switches. In the mapping ratio of n:1, it would result in 340 inefficiency bandwidth utilization which is not optimal in data 341 center networks. More importantly, it is recognized by many data 342 center operators as a unaffordable burden to run multicast in data 343 center networks from network operation and maintenance perspectives. 344 As a result, many VXLAN implementations are claimed to support the 345 ingress replication capability since ingress replication eliminates 346 the burden of running multicast in the underlay. Ingress replication 347 is an acceptable choice in small-sized networks where the average 348 number of receivers per multicast flow is not too large. However, in 349 multi-tenant data center networks, especially those in which the NVE 350 functionality is enabled on a high amount of physical servers, the 351 average number of NVEs per VN instance would be very large. As a 352 result, the ingress replication scheme would result in a serious 353 bandwidth waste in the underlay and a significant replication burden 354 on ingress NVEs. 356 With BIER, there is no need for maintaining that huge amount of 357 multicast states in the underlay anymore while the delivery 358 efficiency of overlay BUM traffic is the same as if any kind of 359 stateful multicast protocols such as PIM-SM or PIM-BIDIR is enabled 360 in the underlay. 362 3.7. Financial Services 364 Financial services extensively rely on IP Multicast to deliver stock 365 market data and its derivatives, and critically require optimal 366 latency path (from publisher to subscribers), deterministic 367 convergence (so as to deliver market data derivatives fairly to each 368 client) and secured delivery. 370 Current multicast solutions e.g. PIM, mLDP etc., however, don't 371 sufficiently address the above requirements. The reason is that the 372 current solutions are primarily subscriber driven i.e. multicast tree 373 is setup using reverse path forwarding techniques, and as a result, 374 the chosen path for market data may not be latency optimal from 375 publisher to the (market data) subscribers. 377 As the number of multicast flows grows, the convergence time might 378 increase and make it somewhat nondeterministic from the first to the 379 last flow depending on platforms/implementations. Also, by having 380 more protocols in the network, the variability to ensure secured 381 delivery of multicast data increases, thereby undermining the overall 382 security aspect. 384 BIER enables setting up the most optimal path from publisher to 385 subscribers by leveraging unicast routing relevant for the 386 subscribers. With BIER, the multicast convergence is as fast as 387 unicast, uniform and deterministic regardless of number of multicast 388 flows. This makes BIER a perfect multicast technology to achieve 389 fairness for market derivatives per each subscriber. 391 4. Security Considerations 393 There are no security issues introduced by this draft. 395 5. IANA Considerations 397 There are no IANA consideration introduced by this draft. 399 6. Acknowledgments 401 The authors would like to thank IJsbrand Wijnands, Greg Shepherd and 402 Christian Martin for their contribution. 404 7. References 406 7.1. Normative References 408 [I-D.rosen-l3vpn-mvpn-bier] 409 Rosen, E., Sivakumar, M., Wijnands, I., Aldrin, S., 410 Dolganow, A., and T. Przygienda, "Multicast VPN Using 411 BIER", draft-rosen-l3vpn-mvpn-bier-02 (work in progress), 412 December 2014. 414 [I-D.wijnands-bier-architecture] 415 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 416 S. Aldrin, "Multicast using Bit Index Explicit 417 Replication", draft-wijnands-bier-architecture-04 (work in 418 progress), February 2015. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, March 1997. 423 7.2. Informative References 425 [I-D.ietf-l2vpn-evpn] 426 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 427 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 428 evpn-11 (work in progress), October 2014. 430 [I-D.ietf-spring-segment-routing] 431 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 432 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 433 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 434 spring-segment-routing-01 (work in progress), February 435 2015. 437 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 438 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 439 Protocol Specification (Revised)", RFC 4601, August 2006. 441 [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual 442 Private Networks (L2VPNs)", RFC 4664, September 2006. 444 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 445 "Bidirectional Protocol Independent Multicast (BIDIR- 446 PIM)", RFC 5015, October 2007. 448 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 449 Label Assignment and Context-Specific Label Space", RFC 450 5331, August 2008. 452 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 453 VPNs", RFC 6513, February 2012. 455 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 456 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 457 eXtensible Local Area Network (VXLAN): A Framework for 458 Overlaying Virtualized Layer 2 Networks over Layer 3 459 Networks", RFC 7348, August 2014. 461 Authors' Addresses 463 Nagendra Kumar 464 Cisco 465 7200 Kit Creek Road 466 Research Triangle Park, NC 27709 467 US 469 Email: naikumar@cisco.com 470 Rajiv Asati 471 Cisco 472 7200 Kit Creek Road 473 Research Triangle Park, NC 27709 474 US 476 Email: rajiva@cisco.com 478 Mach(Guoyi) Chen 479 Huawei 481 Email: mach.chen@huawei.com 483 Xiaohu Xu 484 Huawei 486 Email: xuxiaohu@huawei.com 488 Andrew Dolganow 489 Alcatel-Lucent 490 600 March Road 491 Ottawa, ON K2K2E6 492 Canada 494 Email: andrew.dolganow@alcatel-lucent.com 496 Tony Przygienda 497 Ericsson 498 300 Holger Way 499 San Jose, CA 95134 500 USA 502 Email: antoni.przygienda@ericsson.com 504 Arkadiy Gulko 505 Thomson Reuters 506 195 Broadway 507 New York NY 10007 508 USA 510 Email: arkadiy.gulko@thomsonreuters.com 511 Dom Robinson 512 id3as-company Ltd 513 UK 515 Email: Dom@id3as.co.uk