WO2018158615A1

WO2018158615A1 - Method and apparatus for enabling the creation of a point-to-multipoint label switched path multicast distribution tree for a given ip multicast stream

Info

Publication number: WO2018158615A1
Application number: PCT/IB2017/051226
Authority: WO
Inventors: Kotesh Babu CHUNDU
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-03-02
Filing date: 2017-03-02
Publication date: 2018-09-07

Abstract

A method and apparatus for enabling creation of a point-to-multipoint label switched path (LSP) multicast distribution tree for a given internet protocol (IP) multicast stream associated with a source, where the source is coupled to a receiver of the IP multicast stream through an Multiprotocol Label Switching (MPLS) network. Responsive to determining that the root of an LSP multicast distribution tree is not identified based upon BGP, performing: receiving an IP address of a second edge network device of the MPLS network; identifying the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream; and based upon the IP address, causing the creation of the LSP tree, where the LSP multicast distribution tree has the second edge network device as a root.

Description

METHOD AND APPARATUS FOR ENABLING THE CREATION OF

A POINT-TO-MULTIPOINT LABEL SWITCHED PATH MULTICAST

DISTRIBUTION TREE FOR A GIVEN IP MULTICAST STREAM

TECHNICAL FIELD

[0001] Embodiments of the invention relate to the field of packet networks; and more specifically, to enabling the creation of a point-to-multipoint Label Switched Path multicast distribution tree for a given IP multicast stream.

BACKGROUND

[0002] Internet Protocol Multicast is a technology that enables point-to-multipoint communication. It is often employed for streaming media applications on

the Internet and private networks. It uses reserved multicast address blocks in IPv4 (e.g., IP class D addresses) and IPv6. IP Multicast uses Protocol Independent Multicast (PIM) as routing protocol to exchange signaling information.

[0003] When a source and a receiver of an IP multicast domain are separated by a

Multiprotocol Label Switching (MPLS) network, the PIM protocol needs to be run in the MPLS network as well. In order to solve this problem of separate control plane and separate data plane for unicast and multicast, service providers and the Internet Engineering Task Force (IETF) community have come up with a technology to natively support IP Multicast in MPLS networks by extending the Label Distribution Protocol (LDP)/Resource Reservation Protocol (RSVP) protocols. This technology is referred to as Label Switched Multicast (LSM) and Multicast Label Switched Path (LSP) trees are called Multicast LDP (mLDP) tunnels. mLDP is documented in IETF Request for Comments (RFC) 6388. mLDP permits the creation of P2MP and MP2MP multicast distribution trees. MP2MP has a concept of sender and receiver in the form of upstream and downstream forwarding equivalency classes (FECs). mLDP has both opaque and application specific (specified for interoperability) encodings of FEC elements to permit the naming of multicast groups. mLDP generally operates as a transactional multicast group management protocol that tracks the join and leave actions for each multicast group.

[0004] With LSM, Multicast traffic is encapsulated in mLDP tunnels in the MPLS network and once it reaches the end of the MPLS network, MPLS labels are de-capsulated and the inner multicast packets are forwarded as regular multicast packets in the IP domain.

[0005] Two signaling mechanisms may be used to map an IP multicast stream to an mLDP tunnel: 1) In-band signaling, and 2) Out of band signaling. In-case of in-band signaling, multicast flow information along with the root of point-to-multipoint (P2MP) or multipoint-to- multipoint (MP2MP) LSP multicast distribution tree (which is referred to herein as LSP tree) is carried in the label FEC message. In case of out of band signaling, multicast flow information is carried through out of band routing protocols such as Border Gateway Protocol (BGP), PIM, etc.

[0006] In both cases, in order to create an LSP tree, the IP multicast domain needs to determine the root address of that LSP tree. IETF RFC 6828 recommends that the root address for a given LSP tree is determined based on the BGP next-hop of a given IP Multicast source prefix.

[0007] In-case of Virtual Private Network (VPN) in-band signaling, the VPN multicast source prefixes are learnt using BGP and therefore the BGP next-hop can be used for determining the root address of a given LSP tree of a given multicast stream as recommended by Multicast VPN (MVPN) in RFC 6826.

[0008] In-case of IPTV deployments where two different IP Multicast domains are connected through an MPLS network and plan to use mLDP in-band signaling to carry IP Multicast traffic in MPLS core network, other routing protocols are run parallel for other purposes. In these scenarios, a given source prefix can be learnt by other network elements using different routing protocols other than BGP. In these scenarios, multicast protocols cannot determine the root address of a LSP tree that need to be created for carrying IP Multicast traffic in the MPLS network using mLDP. Consequently, IP Multicast modules running on the receiver IP domain fail to trigger LSP tree for carrying the IP multicast traffic.

SUMMARY

[0009] One general aspect includes a method in a first edge network device of a multiprotocol label switching (MPLS) network of enabling creation of a point-to-multipoint label switched path (LSP) multicast distribution tree for a given internet protocol (IP) multicast stream associated with a group and a source, where the source is coupled to a receiver of the IP multicast stream through the MPLS network, the method including: determining (202) whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP; responsive to determining that the root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, performing:. The method also includes receiving an input indicating an IP address of a second edge network device of the MPLS network. The method also includes identifying the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream. The method also includes based upon the IP address of the second edge network device, causing the creation of the LSP multicast distribution tree, where the LSP multicast distribution tree has the second edge network device as a root.

[0010] One general aspect includes a first edge network device of a multiprotocol label switching (MPLS) network for enabling the creation of a point-to-multipoint label switched path (LSP) multicast distribution tree for a given internet protocol (IP) multicast stream associated with a group and a source, where the source is coupled to a receiver of the IP multicast stream through the MPLS network. The first edge network device includes a non-transitory computer readable medium to store instructions; and a processor coupled with the non-transitory computer readable medium to process the stored instructions to determine whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP; responsive to determining that the root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, perform the following: receive an input indicating an IP address of a second edge network device of the MPLS network; identify the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream; and, based upon the IP address of the second edge network device, cause the creation of the LSP multicast distribution tree, where the LSP multicast distribution tree has the second edge network device as a root.

[0011] One general aspect includes a non-transitory computer readable medium including codes which when executed by a processor of an edge network device of a multiprotocol label switching (MPLS) network to enable creation of a point-to-multipoint label switched path (LSP) multicast distribution tree for a given internet protocol (IP) multicast stream associated with a group and a source, where the source is coupled to a receiver of the IP multicast stream through the MPLS network by performing operations including: determining whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP; and responsive to determining that the root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, performing the following operations: receiving an input indicating an IP address of a second edge network device of the MPLS network; identifying the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream; and based upon the IP address of the second edge network device, causing the creation of the LSP multicast distribution tree, where the LSP multicast distribution tree has the second edge network device as a root. [0012] BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

[0014] Figure 1 is a block diagram of exemplary IP/MPLS networks implementing the enhanced multicast using mLDP in accordance with some embodiments.

[0015] Figure 2 illustrates a flow diagram of exemplary operations for enabling the creation of a point-to-multipoint Label Switched Path multicast distribution tree for a given IP multicast stream in accordance with some embodiments.

[0016] Figure 3 illustrates an exemplary label FEC element used to create a LSP tree in the MPLS network in accordance with some embodiments.

[0017] Figure 4 illustrates exemplary configuration commands (401-406) to be performed by a network administrator to input the IP address identifying the root of a LSP tree in the MPLS network in accordance with some embodiments.

[0018] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.

[0019] Figure 5B illustrates an exemplary way to implement a special-purpose network device according to some embodiments of the invention.

DETAILED DESCRIPTION

[0020] The following description describes methods and apparatus to enabling the creation of a point-to-multipoint Label Switched Path multicast distribution tree for a given IP multicast stream. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0021] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0022] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot- dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the invention.

[0023] In the following description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "Coupled" is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. "Connected" is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0024] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine -readable media (also called computer-readable media), such as machine -readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set or one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and/or sending data out to other devices via a wireless connection. This radio circuitry may include transmitter(s), receiver(s), and/or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.

[0025] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are "multiple services network devices" that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video).

[0026] The embodiments of the present invention provide a framework for enabling determination of a root and creation of a point-to-multipoint LSP multicast distribution tree for a given internet protocol (IP) multicast stream associated with a group and a source, where the source is coupled to a receiver of the IP multicast stream through an MPLS. The solution provides multiple ways to configure the root address of a given LSP tree based on the multicast flow information. In particular, the embodiments of the present invention enable the deployment of mLDP in-band signaling even when BGP is not used to exchange the IP prefixes across the MPLS network. Further, in scenarios of dual homed sources of multicast traffic, the

embodiments of the present invention enable load balancing of the multicast traffic across different PEs that are configured to act as roots of LSP trees within the MPLS network. Thus, the embodiments of the present invention, enable an egress network device of an MPLS network to determine the IP address of a root and consequently create an LSP tree even if IP prefixes are not learnt via BGP or if there is a better path than BGP for that source prefix within the network.

[0027] A method and an apparatus for enabling creation of a point-to-multipoint LSP multicast distribution tree for a given IP multicast stream associated with a group and a source, where the source is coupled to a receiver of the IP multicast stream through an MPLS network are described. A determination of whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP is performed. Responsive to determining that the root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, an input indicating an IP address of a edge network device of the MPLS network is received. The edge network device is identified as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream. Based upon the IP address of the second edge network device, the creation of the LSP multicast distribution tree is created, where the LSP multicast distribution tree has the second edge network device as a root.

[0028] Figure 1 is a block diagram of exemplary IP/MPLS networks implementing the enhanced multicast using mLDP in accordance with some embodiments. The networks 107, 109 A, 109B can include any number of customer edge equipment (CE) nodes that are devices that connect a local area network (LAN) or similar set of customer devices (e.g., receivers 106A-106B). The CE is a network device that can be any type of networking router, switch, bridge or similar device for interconnecting networks.

[0029] The MPLS network 108 is a set of network devices such as routers or switches forming a provider network that implements Multiprotocol Label Switching (MPLS). This network can be controlled by entities such as internet service providers and similar entities. In some embodiments, the MPLS network can be a core network of a cellular network coupled to an access network (e.g., network 109A-B). The networks 109A and 109B include receive network devices (ND 106A, 106B) which are receivers of multicast content (e.g., one or more multicast streams) from a source ND 101 of the IP multicast tree. The networks 109 A, 109B can include any number of receivers and the source ND 101 can be coupled through the MPLS network 108 to any number of CEs and receivers. These networks can interface through any number of Provider Edge Equipments (PEs) such as PE 103, PE 104A, and PE104B. In some

embodiments, the network 109 A-B can access networks of a cellular network and the network 108 is the core network of the cellular network. In other embodiments, the network 108 is an access network of the cellular network. The illustrated network of Figure 1 is simplified for sake of clarity. One skilled in the art would understand that the network can have any number of CEs, PEs, and receivers where any given source ND of an IP multicast domain can connect with the receivers of the IP multicast domain through the MPLS network 108.

[0030] IP multicast is used for sending IP packet flows from the source ND 101 to a group of interested receivers in a single transmission (e.g., receiver ND 106A and receiver ND 106B). When the source and the receiver of the IP multicast domain are separated by an MPLS network (e.g., network 108), mLDP tunnels are used to extend the LDP/ RSVP protocols and provide multicast forwarding within the MPLS network 108. mLDP permits the creation of P2MP and MP2MP LSP multicast distribution trees (herein referred to as LSP tree). In order to define the mLDP tunnels to be associated with IP multicast traffic, the root of the LSP tree which is being built in the MPLS network is identified. In the illustrated example of Figure 1, the LSP tree 110 is triggered by the ND 104A at the edge of the MPLS network 108 coupling the MPLS network with the IP multicast receiver domain. The LSP tree 110 is terminated in the MPLS network at the root ND 103, where the IP Multicast domain starts again (e.g., IP network 107 that includes the IP Multicast source ND 101). In order to trigger the creation of the LSP tree 110 in the MPLS network 108, the address of the root ND 103 needs to be identifiable and routable in the MPLS network. In the MPLS network a network device acting as a root of the LSP tree is the nearest edge ND of the network that connects the IP multicast domain (within IP network 107) with an edge ND (ND 103) of the MPLS network 108.

[0031] Standard approaches that provide support for IP multicast across an MPLS network, typically rely on the BGP routing protocol to advertise the address of the root to BGP peers within the MPLS network. In these approaches, the address of the root is determined based on the BGP next-hop of the IP Multicast source prefix. However this approach requires that the NDs of the MPLS network support and run BGP. In many networks BGP is not supported and other routing protocols may be used (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or static configuration, etc.) for exchanging forwarding and reachability information within the network. In these networks (e.g., mobile access networks), the implementation of IP multicast through MPLS networks is challenging. The embodiments of the present invention provide a mechanism for determining the address of a root of a LSP tree that is to be associated with an IP multicast source when this root is not learnt via BGP. The following embodiments, enable the MPLS network 108 to identify the root ND 103 and carry IP Multicast traffic without the support for BGP routing protocol.

[0032] The operations in the flow diagram of Figure 2 will be described with reference to the exemplary embodiments of the figures. However, it should be understood that the operations of the flow diagrams can be performed by embodiments of the invention other than those discussed with reference to the other figures, and the embodiments of the invention discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagram of Figure 2.

[0033] Figure 2 illustrates a flow diagram of exemplary operations for enabling the creation of a point-to-multipoint Label Switched Path multicast distribution tree for a given IP multicast stream in accordance with some embodiments. At operation 202 a determination is performed of whether the root of the LSP multicast distribution tree within the MPLS network (e.g., ND 103), which couples the receiver (106A) and the source (e.g., ND 101) of the IP multicast stream is identified based upon BGP. The root of the LSP tree is determined based upon BGP when the source of the multicast stream prefix is learnt by BGP. In some embodiments, this determination is performed by determining (operation 222) whether BGP is used as a reachability and forwarding protocol within an MPLS network to exchange IP addresses of network device of the MPLS network. In other embodiments, this determination is performed by determining

(operation 224) whether a best path towards the source of the IP multicast stream is identified based upon BGP.

[0034] When it is determined that a root of the LSP multicast distribution tree is identified based upon BGP, the flow of operations moves to operation 204, at which route advertisements from one or more BGP peers within the MPLS network are collected. Flow then moves to operation 206, at which an IP address of a BGP peer is identified to be the root of the LSP tree within the MPLS network. The IP address is identified as the BGP next hop of the edge ND (e.g., ND 103 being the next hop of the ND 104 A towards the source 101) within the MPLS network towards a source of a multicast stream.

[0035] Alternatively, when it is determined that the root of the LSP multicast distribution tree is not identified based upon BGP, the flow of operations moves to operation 208, at which an input indicating an IP address of an edge network device of the MPLS network is received. Flow then moves to operation 210, at which the edge network device is identified as a root of the LSP tree coupling the MPLS network with an IP network including the source of the multicast stream.

[0036] The IP address may be received from an administrator of the network through a user interface operative to be used to configure the network devices of the network. Thus, in these embodiments, the administrator of the network (e.g., service provider/customer) is to configure an IP address identifying the root of the LSP tree that is to be built within the MPLS network for forwarding a given IP multicast traffic. In some embodiments the input is received based upon exemplary operations as described with reference to Figure 4 below. Several approaches can be used to enable the configuration of a root of an LSP tree within the MPLS network. In one embodiment, for each multicast group G, a network device with a given IP address is identified as a root of the LSP tree. In this embodiment, all the sources that provide traffic to the determined multicast group (*, G) will use the IP address of the identified network device as the root of the LSP tree within the MPLS network.

[0037] In another embodiment, when the multicast source is dual-homed (i.e., the source is coupled with a first ingress ND and a second ingress ND in the MPLS network), the multicast streams forwarded towards various groups from the source (*, G) can be load balanced on the first ingress or the second ingress ND. For example, a first IP address of the first ingress ND can be used as a root of a LSP tree of the MPLS network to forward a first multicast stream (S,G1) originating from the source S and forwarded towards the group of receivers Gl, while a second IP address of the second ingress ND is used as a root of an LSP tree of the MPLS network to forward a second multicast stream (S, G2) originating from the same source S and forwarded towards a second group of receivers G2. In this embodiment, the administrator of the network is enabled to configure a particular root address for each (Source, Group) combination.

[0038] Once the IP address of the LSP tree root is determined, the flow of operations moves to operation 212 at which based upon the IP address of the second edge network device the creation of the LSP multicast distribution tree is caused using in-band signaling mechanism, where the LSP multicast distribution tree has the second edge network device as a root. At operation 210, the ND 104A encodes a P2MP FEC Element, with the IP address of ND 103 as the "Root Node Address." At operation 212, the source and the group of the IP multicast stream to be forwarded within the MPLS network 108 are encoded into the opaque value of the FEC element.

[0039] Figure 3 illustrates an exemplary label FEC element used to create a LSP tree in the MPLS network in accordance with some embodiments. The FEC element includes a first field for encoding the root node address and a second field for encoding the source and the group of the IP multicast stream to be forwarded within the MPLS network. In MLDP in-band signaling, the IP Multicast flow information is carried in the LDP FEC messages. Thus, the source and the group are encoded within the opaque value of the FEC element. The particular type of FEC Element and opaque value used depends on the IP address family being used, and on whether the multicast tree being established is a source-specific or a bidirectional multicast tree. Thus, as will be described with further details with reference to Figure 4, when an administrator inputs an IP address to be used as a root of the LSP tree for an associated group (*, G) or combination of group and source (S, G) of an IP multicast stream, this IP address is encoded as the "root node address" of the FEC element.

[0040] The FEC element as encoded with the root address and source and group information is used within the network in in-band signaling mechanism to create a LSP tree within the MPLS network 108 enabling transport of the respective multicast traffic from the source 101 to the receivers 106A-B. In some embodiments, the in-band signaling mechanism is performed as described with reference to RFC 6826. For example, when a network device in the MPLS network receives a label mapping or withdraw whose FEC Element contains one of the opaque value types including the source and the group of a multicast stream, and that network device is the one identified by the Root Node Address field of that FEC Element (e.g., Ingress PE ND 103), then the multicast source and group are extracted and passed to the multicast module of the network device operative to perform IP multicast. If a label mapping is being processed, the multicast module adds the downstream ND neighbor to the list of the corresponding (S,G) or (*,G), or creates the list if it does not exist yet. If a label withdraw is being processed, the multicast code will remove the downstream ND neighbor from the list of the corresponding (S,G) or (*,G). Following these operations a standard PIM mechanism occurs.

[0041] Figure 4 illustrates exemplary configuration commands (401-406) to be performed by a network administrator to input the IP address identifying the root of a LSP tree in the MPLS network in accordance with some embodiments. At 401, a command for configuring a network device (Device) is initiated. At 402, the context (local) is specified. At 403, the multicast protocol is specified (PIM). At 403, the type of address family to be used is specified (IPv4). At

405, the network device is configured to use in-band signaling of MLPD for enabling multicast within the MPLS network. At 406, an IP address (IPv4-root-address) of a network device is determined as the IP address of the root address of the LSP tree within the MPLS network. At

406, the acl-name identifies the multicast streams to be associated with this particular root address (e.g., which can be a particular group (*, G), or a particular group-source (S, G) combination).

[0042] For example, the commands of Figure 4 may be used to configure the network device ND 104 to indicate that the ND 103 (and its corresponding IP address) is a root of the LSP tree within the MPLS network 108 that is to transport IP multicast traffic originating from the Source ND 101 and destined to the receiver ND 106A. Further these commands may also be performed to configure ND 104B to indicate that the ND 103 (and its corresponding IP address) is a root of the LSP tree within the MPLS network 108 that is to transport IP multicast traffic originating from the Source ND 101 and destined to the receiver ND 106B. The illustrated configuration commands 401-406 are for illustration purposes only and other examples can be used to enable a network administrator to configure the root of a LSP tree within an MPLS network device and cause the creation of the LSP tree based on an in-band signaling mechanism within the MPLS network. This mechanism, allows the MPLS network to support and perform mLDP even when BGP is not supported within the network or if the BGP best path is not discoverable. Therefore, Multicast traffic is encapsulated in mLDP tunnels in the MPLS network and once it reaches the end of the MPLS network, MPLS labels are de-capsulated and the inner multicast packets are forwarded as regular multicast packets in the IP domain.

[0043] Thus, the embodiments of the present invention present clear advantages with respect to standard multicast MPLS solution that require support of BGP to enable the determination of the root address of an LSP tree. The embodiments of the present invention enable the deployment of mLDP in-band signaling even if BGP is not used to exchange the IP prefixes across the MPLS network. Further, in scenarios of dual homed sources of multicast traffic, the embodiments of the present invention enable load balancing of the multicast traffic across different PEs that are configured to act as roots of LSP trees within the MPLS network. In addition, even when protocols other than BGP are used to determine a best route to a given source, the embodiments of the present invention enable the deployment of mLDP in-band signaling. Thus, the embodiments of the present invention, enable an egress network device of an MPLS network to determine the IP address of a root and consequently creating an LSP tree even if IP prefixes are not learnt via BGP or if there is a better path than BGP for that source prefix within the network.

[0044] Is an exemplary deployment, the embodiments of the present invention can be used in Internet Protocol Television (IPTV) deployments where IPTV traffic travels over MPLS networks. In particular, in IPTV deployments, the sources of the multicast traffic are known and multicast group information is statically defined. In these scenarios, when the IPTV sources are not learnt using BGP at the receiver network, the network device coupling the receiver with the MPLS network is enabled to determine the IP address of a root of the LSP by receiving an input (configuration commands) from an administrator indicating the root address and consequently causing this ND to create the LSP tree coupling the receiver's network work with the IPTV source for forwarding multicast traffic through the MPLS network. In an exemplary deployment, the embodiments of the present invention can be used to enable mLDP over a cellular/mobile network (e.g., within the access or the core network of the cellular network). The embodiments of the present invention enable the determination of a root of an LSP tree in these networks, while avoiding the use of BGP. Thus, in these scenarios where routing protocols other than BGP can be used (e.g., OSPF/IS-IS/Static configuration), the embodiments of the present invention enable the determination of the root address of the LSP tree and consequently the use of mLDP in the MPLS network.

[0045] Architecture:

[0046] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention. Figure 5A shows NDs 500A-H, and their connectivity by way of lines between 500A-500B, 500B-500C, 500C-500D, 500D-500E, 500E-500F, 500F-500G, and 500A-500G, as well as between 500H and each of 500A, 500C, 500D, and 500G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 500A, 500E, and 500F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).

[0047] Two of the exemplary ND implementations in Figure 5 A are: 1) a special-purpose network device 502 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general purpose network device 504 that uses common off-the-shelf (COTS) processors and a standard OS.

[0048] The special-purpose network device 502 includes networking hardware 510 comprising a set of one or more processor(s) 512, forwarding resource(s) 514 (which typically include one or more ASICs and/or network processors), and physical network interfaces (NIs) 516 (through which network connections are made, such as those shown by the connectivity between NDs 500A-H), as well as non-transitory machine readable storage media 518 having stored therein networking software 520. During operation, the networking software 520 may be executed by the networking hardware 510 to instantiate a set of one or more networking software instance(s) 522. Each of the networking software instance(s) 522, and that part of the networking hardware 510 that executes that network software instance (be it hardware dedicated to that networking software instance and/or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 522), form a separate virtual network element 530A-R. Each of the virtual network element(s) (VNEs) 530A-R includes a control communication and configuration module 532A-R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 534A-R, such that a given virtual network element (e.g., 530A) includes the control communication and configuration module (e.g., 532A), a set of one or more forwarding table(s) (e.g., 534A), and that portion of the networking hardware 510 that executes the virtual network element (e.g., 530A).

[0049] The special-purpose network device 502 is often physically and/or logically considered to include: 1) a ND control plane 524 (sometimes referred to as a control plane) comprising the processor(s) 512 that execute the control communication and configuration module(s) 532A-R; and 2) a ND forwarding plane 526 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 514 that utilize the forwarding table(s) 534A-R and the physical NIs 516. By way of example, where the ND is a router (or is implementing routing functionality), the ND control plane 524 (the processor(s) 512 executing the control communication and configuration module(s) 532A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 534A-R, and the ND forwarding plane 526 is responsible for receiving that data on the physical NIs 516 and forwarding that data out the appropriate ones of the physical NIs 516 based on the forwarding table(s) 534A-R.

[0050] Figure 5B illustrates an exemplary way to implement the special-purpose network device 502 according to some embodiments of the invention. Figure 5B shows a special- purpose network device including cards 538 (typically hot pluggable). While in some embodiments the cards 538 are of two types (one or more that operate as the ND forwarding plane 526 (sometimes called line cards), and one or more that operate to implement the ND control plane 524 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and/or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card). A service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)). By way of example, a service card may be used to terminate IPsec tunnels and execute the attendant authentication and encryption algorithms. These cards are coupled together through one or more interconnect mechanisms illustrated as backplane 536 (e.g., a first full mesh coupling the line cards and a second full mesh coupling all of the cards).

[0051] Returning to Figure 5A, the general purpose network device 504 includes hardware 540 comprising a set of one or more processor(s) 542 (which are often COTS processors) and physical NIs 546, as well as non-transitory machine readable storage media 548 having stored therein software 550. During operation, the processor(s) 542 execute the software 550 to instantiate one or more sets of one or more applications 564A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 554 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 562A-R called software containers that may each be used to execute one (or more) of the sets of applications 564A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space ) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment the virtualization layer 554 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 564A-R is run on top of a guest operating system within an instance 562A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a "bare metal" host electronic device, or through para-virtualization the operating system and/or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikernel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including drivers libraries of OS services) that provide the particular OS services needed by the application. As a unikernel can be implemented to run directly on hardware 540, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikernels running directly on a hypervisor represented by virtualization layer 554, unikernels running within software containers represented by instances 562A-R, or as a combination of unikernels and the above-described techniques (e.g. , unikernels and virtual machines both run directly on a hypervisor, unikernels and sets of applications that are run in different software containers).

[0052] The instantiation of the one or more sets of one or more applications 564A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 552. Each set of applications 564A-R, corresponding virtualization construct (e.g., instance 562A-R) if implemented, and that part of the hardware 540 that executes them (be it hardware dedicated to that execution and/or time slices of hardware temporally shared), forms a separate virtual network element(s) 560A-R.

[0053] The virtual network element(s) 560A-R perform similar functionality to the virtual network element(s) 530A-R - e.g., similar to the control communication and configuration module(s) 532A and forwarding table(s) 534A (this virtualization of the hardware 540 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments of the invention are illustrated with each instance 562A-R corresponding to one VNE 560A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 562A-R to VNEs also apply to embodiments where such a finer level of granularity and/or unikernels are used.

[0054] In certain embodiments, the virtualization layer 554 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 562A-R and the physical NI(s) 546, as well as optionally between the instances 562A-R; in addition, this virtual switch may enforce network isolation between the VNEs 560A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).

[0055] The third exemplary ND implementation in Figure 5A is a hybrid network device 506, which includes both custom ASICs/special-purpose OS and COTS processors/standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 502) could provide for para-virtualization to the networking hardware present in the hybrid network device 506.

[0056] Regardless of the above exemplary implementations of an ND, when a single one of multiple VNEs implemented by an ND is being considered (e.g., only one of the VNEs is part of a given virtual network) or where only a single VNE is currently being implemented by an ND, the shortened term network element (NE) is sometimes used to refer to that VNE. Also in all of the above exemplary implementations, each of the VNEs (e.g., VNE(s) 530A-R, VNEs 560A-R, and those in the hybrid network device 506) receives data on the physical NIs (e.g., 516, 546) and forwards that data out the appropriate ones of the physical NIs (e.g., 516, 546). For example, a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where "source port" and

"destination port" refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services code point (DSCP) values.

[0057] The NDs of Figure 5 A, for example, may form part of the Internet or a private network; and other electronic devices (not shown; such as end user devices including workstations, laptops, netbooks, tablets, palm tops, mobile phones, smartphones, phablets, multimedia phones, Voice Over Internet Protocol (VOIP) phones, terminals, portable media players, GPS units, wearable devices, gaming systems, set-top boxes, Internet enabled household appliances) may be coupled to the network (directly or through other networks such as access networks) to communicate over the network (e.g., the Internet or virtual private networks (VPNs) overlaid on (e.g., tunneled through) the Internet) with each other (directly or through servers) and/or access content and/or services. Such content and/or services are typically provided by one or more servers (not shown) belonging to a service/content provider or one or more end user devices (not shown) participating in a peer-to-peer (P2P) service, and may include, for example, public webpages (e.g., free content, store fronts, search services), private webpages (e.g.,

username/password accessed webpages providing email services), and/or corporate networks over VPNs. For instance, end user devices may be coupled (e.g., through customer premise equipment coupled to an access network (wired or wirelessly)) to edge NDs, which are coupled (e.g., through one or more core NDs) to other edge NDs, which are coupled to electronic devices acting as servers. However, through compute and storage virtualization, one or more of the electronic devices operating as the NDs in Figure 5A may also host one or more such servers (e.g., in the case of the general purpose network device 504, one or more of the software instances 562A-R may operate as servers; the same would be true for the hybrid network device 506; in the case of the special-purpose network device 502, one or more such servers could also be run on a virtualization layer executed by the processor(s) 512); in which case the servers are said to be co-located with the VNEs of that ND.

[0058] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE/VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE/VNE implemented on a ND can be referred to as IP addresses of that NE/VNE.

[0059] Some NDs provide support for implementing VPNs (Virtual Private Networks) (e.g., Layer 2 VPNs and/or Layer 3 VPNs). For example, the ND where a provider's network and a customer's network are coupled are respectively referred to as PEs (Provider Edge) and CEs (Customer Edge). In a Layer 2 VPN, forwarding typically is performed on the CE(s) on either end of the VPN and traffic is sent across the network (e.g., through one or more PEs coupled by other NDs). Layer 2 circuits are configured between the CEs and PEs (e.g., an Ethernet port, an ATM permanent virtual circuit (PVC), a Frame Relay PVC). In a Layer 3 VPN, routing typically is performed by the PEs. By way of example, an edge ND that supports multiple VNEs may be deployed as a PE; and a VNE may be configured with a VPN protocol, and thus that VNE is referred as a VPN VNE.

[0060] While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0061] While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims

CLAIMS What is claimed is:

1. A method in a first edge network device of a Multiprotocol Label Switching (MPLS) network of enabling creation of a point-to-multipoint Label Switched Path (LSP) multicast distribution tree for a given Internet Protocol (IP) multicast stream associated a source, wherein the source is coupled to a receiver of the IP multicast stream through the MPLS network the method comprising:

determining (202) whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP; and

responsive to determining that the root of the LSP multicast distribution tree within the

MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, performing:

receiving an input indicating an IP address of a second edge network device of the MPLS network,

identifying the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream, and

based upon the IP address of the second edge network device, causing (212) the creation of the LSP multicast distribution tree, wherein the LSP multicast distribution tree has the second edge network device as a root.

2. The method of claim 1, wherein determining whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP includes determining (222) whether BGP is used as a reachability and forwarding protocol within an MPLS network to exchange IP addresses of network device of the MPLS network.

3. The method of claim 1, wherein determining whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP includes determining (224) whether a best path towards the source of the IP multicast stream is identified based upon BGP.

4. The first edge network device of claim 1, wherein causing (212) the creation of the LSP multicast distribution is performed based upon an in-band signaling mechanism.

5. The method of claim 4, wherein causing (212) the creation of the LSP multicast distribution includes encoding (214) the IP address of the second edge network device as a root node address of a forwarding equivalency class (FEC) element.

6. The method of claim 5, wherein causing (212) the creation of the LSP multicast distribution further includes encoding (216) the source the IP multicast stream into an opaque value of the FEC element.

7. The method of claim 1, wherein the MPLS network is at least one of an access network or a core network of a cellular network.

8. A machine-readable medium comprising computer program code which when executed by a computer carries out the method steps of any of claims 1-7.

9. A first edge network device of a Multiprotocol Label Switching (MPLS) network for enabling creation of a point-to-multipoint Label Switched Path (LSP) multicast distribution tree for a given Internet Protocol (IP) multicast stream associated with a source, wherein the source is coupled to a receiver of the IP multicast stream through the MPLS network the first edge network device comprising:

a non-transitory computer readable medium to store instructions; and

a processor coupled with the non-transitory computer readable medium to process the stored instructions to:

determine (202) whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BG, and

responsive to determining that the root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is not identified based upon BGP, perform the following: receive an input indicating an IP address of a second edge network device of the MPLS network,

identify the second edge network device as the root of the LSP multicast distribution tree coupling the MPLS network with an IP network including the source of the multicast stream, and

based upon the IP address of the second edge network device, cause (212) the creation of the LSP multicast distribution tree, wherein the LSP multicast distribution tree has the second edge network device as a root.

10. The first edge network device of claim 9, wherein to determine whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP includes to determine (222) whether BGP is used as a reachability and forwarding protocol within an MPLS network to exchange IP addresses of network device of the MPLS network.

11. The first edge network device of claim 10, wherein to determine whether a root of the LSP multicast distribution tree within the MPLS network coupling the receiver and the source of the IP multicast stream is identified based upon BGP includes to determine (224) whether a best path towards the source of the IP multicast stream is identified based upon BGP.

12. The first edge network device of claim 9, wherein to cause (212) the creation of the LSP multicast distribution is performed based upon an in-band signaling mechanism.

13. The first edge network device of claim 12, wherein to cause (212) the creation of the LSP multicast distribution includes to encode (214) the IP address of the second edge network device as a root node address of a forwarding equivalency class (FEC) element.

14. The first edge network device of claim 13, wherein to cause (212) the creation of the LSP multicast distribution further includes to encode (216) the source of the IP multicast stream into an opaque value of the FEC element.

15. The first edge network device of claim 9, wherein the MPLS network is at least one of an access network or a core network of a cellular network.