idnits 2.17.1 draft-yong-pim-igp-multicast-arch-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. 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 (March 9, 2015) is 3307 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) == Unused Reference: 'RFC2236' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'RFC2710' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 603, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2740 (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Yong 3 Internet-Draft D. Cheng 4 Intended status: Standards Track W. Hao 5 Expires: September 10, 2015 D. Eastlake 6 Huawei Technologies Ltd. 7 A. Qu 8 MediaTek 9 J. Hudson 10 Brocade 11 U. Chunduri 12 Ericsson Inc. 13 March 9, 2015 15 IGP Multicast Architecture 16 draft-yong-pim-igp-multicast-arch-01 18 Abstract 20 This document specifies the architecture of IP multicast routing 21 using an Interior Gateway Protocol (IGP). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 10, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Conventions used in this Document . . . . . . . . . . . . 4 67 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. An Overview of IGP . . . . . . . . . . . . . . . . . . . . . 5 69 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Routing IP Multicast Packets . . . . . . . . . . . . . . . . 6 71 4.1. Multicast Distribution Tree . . . . . . . . . . . . . . . 7 72 4.1.1. Bidirectional Distribution Tree . . . . . . . . . . . 8 73 4.2. Advertising Multicast Group Membership . . . . . . . . . 9 74 4.3. Requirements of Edge Routers . . . . . . . . . . . . . . 9 75 4.4. Intra-Area Multicast Routing . . . . . . . . . . . . . . 10 76 4.5. Inter-Area Multicast Routing . . . . . . . . . . . . . . 10 77 4.5.1. Behavior of IS-IS Level 2 Router . . . . . . . . . . 11 78 4.5.2. Behavior of OSPF ABR . . . . . . . . . . . . . . . . 11 79 4.6. Heterogeneous Environment . . . . . . . . . . . . . . . . 11 80 4.7. TE (Traffic Engineering) Support . . . . . . . . . . . . 12 81 4.8. Applications to Overlay Model . . . . . . . . . . . . . . 12 82 4.9. IPv6 and IPv4 . . . . . . . . . . . . . . . . . . . . . . 12 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 7.2. Informative References . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 90 1. Introduction 92 1.1. Overview 94 In an IP network, an IGP is used to route and forward IP unicast 95 packets. In doing so, the routers collect and maintain the network 96 information and store it in their database. The network information 97 includes the identity of the routers and their interconnections. In 98 a traffic engineering enabled network, the information also includes 99 traffic related parameters such as link bandwidth. The network 100 information that is already maintained on routers, along with some 101 minor IGP protocol extensions as proposed in this document, are 102 sufficient to also route IP multicast packets. This means a single 103 IGP can be used for routing both unicast packets and multicast 104 packets. This document describes the architecture of routing IP 105 multicast packets using the network information that is disseminated 106 by an IGP. 108 1.2. Motivation 110 With the explosion of IP technology based applications, the support 111 of IP multicast delivery over the same IP network that carries IP 112 unicast traffic becomes mandatory. In many aspects, some basic 113 requirements for routing IP multicast packets are the same as those 114 for routing IP unicast packets; e.g., the "plug and play" nature of 115 bringing up the routing engine and enabling the packets forwarding. 116 It is desirable to use an IGP that requires minimum configuration and 117 currently only routes and forwards IP unicast packets, to also route 118 and forward IP multicast packets. 120 Current practice in an IP network is to use a separate protocol, such 121 as Protocol Independent Multicast (PIM - [RFC4601]), to route and 122 forward IP multicast packets, whereby some network information are 123 actually retrieved from IGP. Using a single protocol, i.e., an IGP, 124 to route both IP unicast and multicast packets is more efficient; 125 this eliminates additional convergence time that would otherwise be 126 introduced by the second protocol. Using one protocol also reduces 127 operational complexity. 129 In an advanced data center network, the decoupling of network IP 130 space from service IP space, for example a VxLAN based network 131 overlay [RFC7348], is required. To support all service applications, 132 such an IP network fabric must support both unicast and multicast. 133 Decoupling network IP space from service IP address space also 134 provides network agility and programmability. If network IP space is 135 decoupled from service IP space, the network itself no longer needs 136 manual configuration; an IP network fabric can be formed 137 automatically. 139 1.3. Conventions used in this Document 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 1.4. Terminology 147 This document makes use of the following terms: 149 o Edge Router: A router that has direct interfaces with one or more 150 IP hosts. 152 o Distribution Tree: a rooted distribution tree with one root and 153 one or more leaves that facilitate routing multicast packets. 155 o IGP: Interior Gateway Protocol. 157 o Intra-Area: Refers to the communication between IGP routing nodes 158 within a single IGP's area. 160 o Inter-Area: Refer to the communication between IGP routing nodes 161 across an area boundary. 163 o IP Multicast Group 165 o Link State Database: The database constructed and maintained by a 166 router running link state based routing algorithm such as IS-IS 167 and OSPF. It contains network based information including 168 identity of routers and their interconnections, reachable IP 169 addresses, etc. 171 o Local Group Database: The database constructed and maintained by 172 an edge router that stores and maintains entries of { multicast- 173 address, host } pairs for hosts interested in traffic for a multi- 174 cast address. 176 o Pruned Tree: A subset of IGP's topology graph with a tree root, 177 using which multicast packets are forwarded to one or more 178 destination nodes with optimization of the usage of links and 179 nodes. 181 o Root Node: A router serving as the root of a multicast 182 distribution tree. 184 o TE (Traffic Engineering) Database: The database constructed and 185 maintained by a router running a link state based routing 186 algorithm with TE extensions such as ISIS-TE and OSPF-TE. It 187 contains TE parameters (such as bandwidth) that are associated 188 with links and nodes. 190 o Transit Router: A router that is capable of receiving an IP 191 multicast packet, then replicates it and sends to one or more 192 other routers in the same multicast distribution tree. 194 2. An Overview of IGP 196 There are currently two heavily deployed IGPs, IS-IS 197 [RFC1195]/[RFC5308] and OSPF [RFC2328]/[RFC2740]. IS-IS and OSPF are 198 different in many aspects, but they both use a link-state algorithm 199 and the network information they disseminate for the same IP network 200 is the same, including routers' IP addresses, routers' 201 interconnections, reachable IP addresses, the network topology, etc. 203 An IGP operation can have a hierarchy of two levels. An IGP runs 204 within an area, where each participating router originates and 205 advertises its own information (router's identity, interface IP 206 addresses, identity of directly connected neighbors, etc.), and this 207 information is flooded to all participating routers the entire area 208 but not beyond. As a result, within an IGP area, each participating 209 router maintains the information of all routers and their 210 interconnections. This collection of network information is the Link 211 State Database, which is currently used as a base to calculate IP 212 routing table for unicast packets within an IGP area. Sometimes we 213 refer to the topology within an IGP area as a topology graph. 214 Separate IGP areas may be interconnected and, between areas, only 215 reachability information is advertised across area boundaries by 216 Level-2 routers in IS-IS or Area Border Routers (ABR) in OSPF. 218 [RFC1195] specifies an IGP for routing IPv4 unicast packets using IS- 219 IS protocol (ISO), whereas [RFC5308] specifies the extensions to 220 support routing IPv6 unicast packets. 222 OSPFv2 [RFC2328] is an IGP for routing IPv4 unicast packets whereas 223 OSPFv3 [RFC2740] is an IGP for routing IPv6 unicast packets. 225 The link state based routing algorithm in OSPF and IS-IS calculates 226 the shortest path from the source to the destination. A routing 227 table for routing unicast packets is generated on every participating 228 IGP router. 230 For some applications, path restrictions (e.g., link bandwidth) need 231 to be considered. As a result, extensions have been added to both 232 IS-IS and OSPF to support traffic engineering based unicast routing 233 as follows: 235 o [RFC3630] - Traffic Engineering (TE) Extensions to OSPF Version 2 237 o [RFC3784] - Intermediate System to Intermediate System (IS-IS) 238 Extensions for Traffic Engineering (TE) 240 o [RFC5329] - Traffic Engineering Extensions to OSPF Version 3 242 A TE-capable IGP router, in addition to constructing a Link State 243 Database, also constructs and maintains a TE Database that stores the 244 traffic parameters (e.g., bandwidth) associated with links and nodes. 245 This information is used for constraint based consideration during 246 normal shortest path calculation. 248 3. Scope 250 To support IP multicast routing, either IS-IS or OSPF can be used 251 and, in the architectural perspective of this document, there is no 252 difference between them. It requires no change in IS-IS or OSPF 253 other than extensions to advertise and store distribution tree root 254 node address and multicast group receiver information (refer to 255 Section 4.2). 257 Using IGP to route IP multicast packets is within IGP's architecture 258 and routing paradigm. IP multicast routing within an IGP area is 259 called intra-area multicast routing, and IP multicast routing across 260 IGP area is called inter-area multicast routing. The concept, rules 261 and behavior regarding intra-area unicast routing and inter-area 262 unicast routing are all similarly applicable to intra-area and inter- 263 area multicast routing, respectively. 265 In an IPv4 network, IPv4 multicast packets can be routed using IS-IS 266 (based on [RFC1195]) or OSPFv2 as introduced by this document. 267 Similarly in an IPv6 network, IPv6 multicast packets can be routed 268 using IS-IS (based on [RFC5308]) or OSPFv3 [RFC2740]. As the 269 networking industry is currently under transition from IPv4 to IPv6, 270 co-existence of the two is sometimes required. Using the 271 architecture described in this document, IPv4 multicast packets can 272 be transported over an IPv6 network and IPv6 multicast packets can be 273 transported over an IPv4 network. 275 4. Routing IP Multicast Packets 277 As illustrated in Figure 1, a single IGP can support both IP unicast 278 and multicast routing. 280 This section describes routing IP multicast packets using the 281 existing network information that IGP collects, the related functions 282 and characteristics, along with the required extensions to existing 283 IGPs. 285 +-------------+ +-------------+ 286 | IP Unicast | | IP Multicast| 287 | Routing | | Routing | 288 +------^------+ +------^------+ 289 | | 290 +------o------+ +------o------+ 291 | Unicast | | Multicast | 292 |Routing Table| |Routing Table| 293 +------^------+ +------^------+ 294 | | 295 +------o------+ +------o------+ 296 | Shortest | | Distribution| 297 | Path Tree | | Path Tree | 298 +------^------+ +------^------+ 299 | | 300 +------o---------------o------+ 301 | Link State Database | 302 +--------------^--------------+ 303 | 304 +--------------o--------------+ 305 | IGP | 306 | +---------+ +---------+ | 307 | | OSPF | | IS-IS | | 308 | +---------+ +---------+ | 309 +-----------------------------+ 311 Figure 1: Using an IGP to Route both IP Unicast and Multicast Packets 313 4.1. Multicast Distribution Tree 315 To route IP multicast packets, a distribution tree is used. A 316 distribution tree consists of a tree root, one or more tree leaves, 317 and some branch nodes. The tree root is identified by the IP address 318 (or Router ID) of an arbitrary router. The tree root can be 319 configured for a specific IP multicast address group, or 320 automatically elected via an algorithm. A tree leaf is an edge 321 router and is a multicast destination. A tree leaf is identified by 322 an edge router's IP address and it is directly attached to one or 323 more hosts that advertise the IP multicast group addresses (see 324 Section 4.2 for details). A router that is not a tree root but 325 transmits a received IP multicast packet to one or more other router 326 is called a Transit Router, which is a branch node in the 327 distribution tree. 329 In the most general case, there is a single multicast distribution 330 tree for each IP multicast address group. Once a distribution tree 331 is formed, an IP packet with the multicast destination address is 332 forwarded according to the multicast distribution tree, that is, from 333 the source to all tree leaves. 335 Via configuration, additional distribution trees can be constructed 336 for the same IP multicast address group, however with different tree 337 roots and tree branches (paths). This option provides a redundancy 338 for routing path protection, and it can also be used to support load 339 balance. 341 When a leaf node of a multicast distribution tree is in the same IGP 342 area as the tree root, the packet flow in the tree is within a single 343 IGP area. This behavior is called IGP intra-area multicast routing. 345 When a leaf node of a multicast distribution tree is in a different 346 IGP area from the tree root, the packet flow in the tree must cross 347 IGP area boundary. This behavior is called IGP inter-area multicast 348 routing. 350 Unicast routing in an IGP domain requires minimum configuration. 351 This characteristic is inherited by multicast routing, that is, it 352 requires minimal configuration and a multicast distribution tree can 353 generally be constructed quickly in the same manner as a unicast 354 routing table. 356 4.1.1. Bidirectional Distribution Tree 358 A multicast distribution tree is bi-directional. In such a tree, IP 359 multicast packets destined to a given multicast address could 360 traverse any tree branch in either direction; that means any leaf 361 node on the tree can be a multicast receiver and sender. When a leaf 362 node is a multicast source, it transmits the packet on the tree by 363 which it is distributed to all other leaves of that tree. The bi- 364 directionality of distribution tree is useful for applications such 365 as video conference. 367 By configuration, a multicast distribution tree can be uni- 368 directional, i.e., all leaf nodes can only receive multicast packets 369 destined to a given multicast address. In this scenario, the tree 370 root may be the traffic source and if not, the source must unicast 371 packets to the tree root, which then distributes the packets 372 according to the distribution tree. The uni-directionality of 373 distribution tree is useful for applications such as video 374 broadcasting. 376 For optimization purpose, i.e., to build an efficient pruned 377 multicast distribution tree in both cases, care must be taken in 378 choosing the location of tree root in a given network; e.g., to 379 consider the average path length from the root to leaf nodes, the 380 total links (branches) used for the distribution, etc. 382 4.2. Advertising Multicast Group Membership 384 In order to support multicast routing, an IGP must be extended to 385 store and advertise IP multicast addresses in the similar manner 386 currently for IP unicast addresses. 388 Pairs of { multicast-group, host } can be configured on an edge 389 router, or learned from the interaction with IGMP/MLD(see 390 Section 4.3). In either case, the router must advertise the IP 391 multicast group membership throughout the IGP area. The advertising, 392 refresh, aging, and removal of IP multicast addresses are handled in 393 the same manner as the existing database element, i.e., LSP in IS-IS 394 and LSA in OSPF. 396 IP multicast addresses can also be advertised across an IGP area 397 boundary using mechanisms similar to those used for IP unicast 398 addresses. IP multicast addresses may be summarized in a way similar 399 to IP unicast addresses for scaling purpose. 401 The details of storing and advertising IP multicast address using IS- 402 IS and OSPF will be specified in a separate documents. 404 4.3. Requirements of Edge Routers 406 To support routing IP multicast packets, edge routers, i.e., routers 407 that have interfaces directly connected to IP hosts, are required to 408 run IGMP (IGMPv2/[RFC2236] or IGMPv3/[RFC3376]) for IPv4 based hosts 409 and MLD (MLD/[RFC2710] or MLDv2/[RFC3810]) for IPv6 based hosts. 411 As the result of interaction with hosts, an edge router would build a 412 Local Group Database where each entry is a { multicast-group, host } 413 pair, which indicates that the attached host belonging to the IP 414 multicast group. This process is on-going in order to keep track of 415 the IP group membership addresses of attached hosts according to 416 protocol specification of IGMP/MLD. 418 Use of the Local Group Database is two fold. First, when an edge 419 router receives an inbound IP multicast packet, it checks in the 420 database to see if any entry has an IP multicast-group address 421 matching the destination address in the received packet. If so, the 422 packet is forwarded to the local host(s); otherwise the packet is 423 dropped. Note this behavior already exists on edge routers that 424 support IP multicast forwarding. 426 Second, an edge router is required to advertise/flood the IP 427 multicast addresses learnt/withdrawn from IGMP/MLD to/from other 428 routers in the same IGP area, in the similar manner as advertising/ 429 flooding its own interface IP addresses. With this information, an 430 IP multicast distribution tree can be built for each IP multicast 431 address group. The details for advertising multicast addresses by 432 IS-IS and OSPF will be documented separately. 434 In some deployment, a host as a multicast destination or source may 435 connect to more than one edge routers for the purpose of reliability 436 or/and load balance, which is normally termed multi-homing. In this 437 scenario, care must be taken in order to prevent forwarding loops or 438 packets duplication. 440 4.4. Intra-Area Multicast Routing 442 An IP multicast distribution tree within an IGP area is a sub-graph 443 of the IGP's area topology graph (see Section 2). All routers that 444 receive advertisement of IP multicast addresses in the IGP area must 445 build the multicast distribution tree for each IP multicast address 446 group. The construction of the distribution is based on the IGP's 447 Link State Database, which is currently used for routing IP unicast 448 packets. All routers in an IGP area must calculate and construct the 449 intra-area distribution tree using IGP's Link State Database with the 450 same algorithm, so that a pruned tree can be constructed for the 451 distribution tree. Care must be taken to avoid forwarding loops and 452 routing optimization is highly desirable. 454 The algorithm for constructing an IP multicast distribution tree, and 455 other related functions, do not require changes to existing IGP 456 function other than the addition of extensions. 458 The specific algorithm and related details for intra-area multicast 459 routing will be in a separate document. 461 4.5. Inter-Area Multicast Routing 463 In inter-area unicast routing, an IP packet from one IGP area 464 forwarded to another area is sent to an area border node (ABR for 465 OSPF) or L2 router (for IS-IS) first, which then forwards the packet 466 to/in the neighboring area. This is also the scenario for inter-area 467 multicast routing, and as such, an ABR/L2-Router functions as a 468 Transit Router, or a branch node in the multicast distribution tree. 470 Note that IGP's Link State Database is per area, so the multicast 471 distribution tree constructed on routers in the transmitting area in 472 generally terminated at the ABR/L2-Router due to lack of routing 473 information. The ABR/L2-Router in question would require extending 474 the distribution in the receiving area based on the separate Link 475 State Database. 477 The specific procedure and related details for inter-area multicast 478 routing will be in a separate document. 480 4.5.1. Behavior of IS-IS Level 2 Router 482 For IS-IS, the area boundary is in the border router, which extends 483 the distribution tree for that area. 485 To support inter-area multicast routing, an IS-IS Level 2 Router is 486 required to propagate IP multicast addresses received in one area to 487 all Level 2 Routers in other areas it is connected. This behavior is 488 similar to the advertisement of IS-IS Reachability Information PDU. 490 4.5.2. Behavior of OSPF ABR 492 For OSPF, the area boundary is on the ABR. When an ABR attached to 493 both transmitting area and receiving area, it extends the 494 distribution tree in the receiving area. 496 To support inter-area multicast routing, an OSPF ABR is required to 497 propagate IP multicast addresses received in one area to all other 498 areas to which it is attached. This behavior is similar to the 499 advertisement of OSPF Summary LSAs. 501 4.6. Heterogeneous Environment 503 To deploy IP multicast routing using IGP as described in this 504 document, all routers in the IGP area are required to do the 505 following: 507 o Implement the extensions to IS-IS (documented separately) or to 508 OSPF (documented separately), depending on the IGP in use, for 509 advertising multicast addresses. 511 o Support the new functions as described in Section 4. 513 A heterogeneous network environment is one where not all routers in 514 an IGP area implement the above extensions. A multicast distribution 515 tree within such an area cannot be segregated, but tunneling 516 mechanism can be used to support multicast routing there. When there 517 are routers that would be on a multicast distribution tree but do not 518 supporting the required extensions, a tunnel is constructed 519 connecting two routers capable of routing multicast across one or 520 more intervening non-capable routers, such that the tunnel becomes a 521 single branch on the distribution tree. An IP multicast packet sent 522 from a tunnel end to the other is encapsulated in an IP packet with 523 the sending router's IP address as the source address and the 524 receiving router's IP address as the destination address. 526 4.7. TE (Traffic Engineering) Support 528 The existing IP multicast routing practice (e.g., PIM) does not 529 consider route constraints (e.g., link bandwidth). Both OSPF and IS- 530 IS support traffic engineering based unicast routing by constructing 531 and maintaining a TE Database. Like the Link State Database, the TE 532 Database can also be used to support IP multicast routing when one or 533 more path constraints are considered. 535 To perform TE based multicast routing using IGP, routers must support 536 TE extensions, and otherwise, there requires no other change in the 537 IGP. 539 4.8. Applications to Overlay Model 541 Using a single IGP as a uniform routing engine for both IP unicast 542 and multicast routing enables a simple but efficient IP networking 543 fabric that can serve various applications above it using a overlay 544 model. These applications are viewed as at the service level, 545 completely decoupled from the underneath IP networking fabric; 546 however, they enjoy both IP unicast and multicast transportation 547 infrastructure. In the multicast perspective, the applications can 548 be IP based, but can also be layer-2 based such as Ethernet. 550 4.9. IPv6 and IPv4 552 The architecture as outlined in this document supports IPv4 multicast 553 routing in IPv4 networks, and also IPv6 multicast routing in IPv6 554 networks. 556 With mechanisms such as tunneling or address translation, the same 557 architecture can also support IPv4 multicast routing in IPv6 558 networks, and IPv6 multicast routing in IPv4 networks. The details 559 are specified in other documents. 561 5. IANA Considerations 563 This document requires no IANA actions. 565 6. Acknowledgement 567 7. References 569 7.1. Normative References 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, March 1997. 574 7.2. Informative References 576 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 577 dual environments", RFC 1195, December 1990. 579 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 580 2", RFC 2236, November 1997. 582 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 584 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 585 Listener Discovery (MLD) for IPv6", RFC 2710, October 586 1999. 588 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 589 2740, December 1999. 591 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 592 Thyagarajan, "Internet Group Management Protocol, Version 593 3", RFC 3376, October 2002. 595 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 596 (TE) Extensions to OSPF Version 2", RFC 3630, September 597 2003. 599 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 600 System (IS-IS) Extensions for Traffic Engineering (TE)", 601 RFC 3784, June 2004. 603 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 604 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 606 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 607 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 608 Protocol Specification (Revised)", RFC 4601, August 2006. 610 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 611 2008. 613 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, 614 "Traffic Engineering Extensions to OSPF Version 3", RFC 615 5329, September 2008. 617 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 618 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 619 eXtensible Local Area Network (VXLAN): A Framework for 620 Overlaying Virtualized Layer 2 Networks over Layer 3 621 Networks", RFC 7348, August 2014. 623 Authors' Addresses 625 Lucy Yong 626 Huawei Technologies Ltd. 627 Austin, TX 628 USA 630 Email: lucy.yong@huawei.com 632 Dean Cheng 633 Huawei Technologies Ltd. 634 2330 Central Expressway 635 Santa Clara, CA 95135 636 USA 638 Email: dean.cheng@huawei.com 640 Weiguo Hao 641 Huawei Technologies Ltd. 642 101 Software Avenue 643 Nanjing 210012 644 China 646 Email: haoweiguo@huawei.com 648 Donald Eastlake 649 Huawei Technologies Ltd. 650 155 Beaver Street 651 Milford, MA 01757 652 USA 654 Email: d3e3e3@gmail.com 655 Andrew Qu 656 MediaTek 657 San Jose, CA 95134 658 USA 660 Email: laodulaodu@gmail.com 662 Jon Hudson 663 Brocade 664 130 Holger Way 665 San Jose, California 95134 666 USA 668 Email: jon.hudson@gmail.com 670 Uma Chunduri 671 Ericsson Inc. 672 300 Holger Way 673 San Jose, California 95134 674 USA 676 Email: uma.chunduri@ericsson.com