Network system, computer networking method, and computer readable storage medium

Abstract

The invention discloses a network system, a computer networking method and a computer readable storage medium. In one example, a first network device receives a multicast packet for a multicast group associated with a multicast service from a multicast sender device via an L2 network. The first network device generates a unicast L3 packet based on the multicast packet, the unicast L3 packet including a PIM registration request configured to register the first network device as a multicast source of the multicast group. A header of the unicast L3 packet specifies a source address that includes a network address translation (NAT) to an address of a virtual loop interface of the second network device. The virtual loop interface is associated with a PIM service for a multicast service between the first network device and the second network device. The first network device forwards the unicast L3 packet across the L3 transport network to the second network device.

Description

[0001] This application claims the benefit of U.S. Patent Application No. 18 / 400,947, filed on December 29, 2023, which claims the benefit of U.S. Provisional Application No. 63 / 510,771, filed on June 28, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure relates generally to computer networking and, more particularly, to multicast communications. Background Art

[0003] A computer network is a collection of interconnected computing devices that can exchange data and share resources. Example computing devices include routers, switches, and other layer 2 (L2) network devices that operate within layer 2 (i.e., the data link layer) of the Open Systems Interconnection (OSI) reference model, and layer 3 (L3) network devices that operate within layer 3 (i.e., the network layer) of the OSI reference model. Network devices within a computer network typically include a control unit that provides control plane functions for the network device and forwarding components for routing or switching data units.

[0004] Computing devices can establish a "network session" (also referred to herein as a "session") to enable communication between devices on a computer network. A session can be bidirectional in that the session includes packets traveling in two directions between a first device and a second device. For example, a session includes a forward packet flow originating from a first device and destined for a second device and / or a reverse packet flow originating from a second device and destined for the first device. The forward packet flow and the reverse packet flow of a session are related to each other because the values ​​specified in the source address and source port of the forward packet flow are the same as the values ​​specified in the destination address and destination port of the reverse packet flow, and the values ​​specified in the destination address and destination port of the forward packet flow are the same as the values ​​specified in the source address and source port of the reverse packet flow.

[0005] Alternatively, a session can be unidirectional in that the session includes packets traveling in only one direction from the first device to the second device. For example, a session includes a forward packet flow originating from the first device and destined for the second device. A different session may include a reverse packet flow originating from the second device and destined for the first device.

[0006] To establish a session, the computing device may use one or more communication session protocols, including Transmission Control Protocol (TCP), Transport Layer Security (TLS), User Datagram Protocol (UDP), Internet Control Message Protocol (UDP), and the like. Summary of the invention

[0007] In general, the technology disclosed herein relates to sending a protocol independent multicast (PIM) message across an L3 transport network. In one example, a first network device is connected to a multicast sender device via a layer 2 (L2) network. The first network device is also connected to a second network device via an L3 transport network. The L3 transport network can be, for example, a session-routed transport network or a multi-protocol label switching (MPLS) transport network.

[0008] The second network device defines a PIM service for a multicast service between the first network device and the second network device. The second network device establishes a virtual circuit interface and stores an association between the PIM service and the address of the virtual circuit interface. The first network device learns the address of the virtual circuit interface of the second network device associated with the PIM service for a multicast service between the first network device and the second network device via a routing protocol such as a Border Gateway Protocol (BGP).

[0009] A first network device receives a multicast packet for a multicast group associated with a multicast service from a multicast sender device via an L2 network. The first network device generates a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet including a PIM registration request that is directed to a rendezvous point (RP) device and is configured to register the first network device as a multicast source for the multicast group. A header of the unicast L3 packet specifies a source address that includes a network address translation (NAT) to an address of a virtual circuit interface of a second network device. In some examples, the first network device performs NAT of an address of the multicast sender device to an address of a virtual circuit interface of the second network device. In some examples, the first network device performs NAT of an address of the first network device to an address of a virtual circuit interface of the second network device. The first network device forwards the unicast L3 packet to the second network device across the L3 transport network.

[0010] The second network device receives the unicast L3 packet. The second network device determines that the PIM registration request is associated with a multicast group associated with the multicast service based at least in part on a stored association between the PIM service and an address of a virtual circuit interface of the second network device. The second network device registers the first network device as a multicast source for the multicast group associated with the multicast service.

[0011] The technology of the present disclosure may provide specific improvements in computer-related fields of computer networking with practical applications. For example, traditionally, a network device that receives a PIM message from another network device interconnected via an L3 transport network may not be able to identify the multicast service or multicast sender to which the PIM message is directed, because in the case where the network device supports multiple multicast services, the traditional PIM message may not include information specifying the corresponding multicast service from other multicast services to which the PIM message is applied. This may force the network device to apply the same policy (e.g., aggregation point, distribution tree, etc.) to the multicast traffic of each of the same multicast services, in which case it may be more desirable to apply different policies to different multicast services. The technology of the present invention may enable network devices to exchange PIM messages across intermediate transport networks while retaining the ability to identify specific multicast senders, multicast receivers, and multicast services associated with a specific PIM message.

[0012] In addition, conventionally, an ingress network device of a transport network may receive a multicast packet for a multicast group and forward the multicast packet to an egress network device across the transport network. If a multicast receiving device to which the egress network device is connected does not subscribe to the multicast group, the egress network device may discard the multicast packet, thereby wasting network resources of the transport network. By facilitating the exchange of PIM messages between network devices interconnected by the transport network, the technology of the present invention may reduce or eliminate the number of multicast packets for a multicast group sent across the transport network to an egress network device that is not connected to a multicast receiving device that subscribes to the multicast group, thereby reducing unnecessary consumption of network resources of the transport network, saving processing power of the egress network device due to the egress network device receiving fewer multicast packets, and improving efficiency.

[0013] In one example, the present disclosure describes a first network system, including: a storage medium; and a processing circuit in communication with the storage medium, the processing circuit being configured to: define a PIM service between a first network device and a second network device, each of the PIM services being associated with a corresponding multicast service in a plurality of multicast services; establish a virtual circuit interface of the first network device, each of the virtual circuit interfaces corresponding to a corresponding one of the PIM services; and store an association between an address of each of the virtual circuit interfaces and a corresponding PIM service in the PIM services; receive a unicast L3 distribution from the second network device via an L3 transport network. The invention relates to a multicast group, wherein the unicast L3 packet includes: a header specifying a source address, the source address being an address of a first virtual circuit interface among the virtual circuit interfaces; and a payload including a PIM registration request to an RP device of the multicast group for registering a second network device as a multicast source of the multicast group; and registering the second network device as a multicast source of the multicast group based at least in part on an association between the address of the first virtual circuit interface specified by the header of the unicast L3 packet and a first PIM service among the PIM services, the multicast group being associated with a first multicast service among the plurality of multicast services, the first multicast service being associated with the first PIM service.

[0014] In another example, the present disclosure describes a method, including: receiving, by a first network device, a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to the first network device via an L2 network; generating, by the first network device at least partially based on the multicast packet, a unicast L3 packet including a PIM registration request that is addressed to an RP device and is configured to register the first network device as a multicast source for the multicast group, wherein a header of the unicast L3 packet specifies a source address, the source address including a NAT to an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device; and forwarding, by the first network device, the unicast L3 packet to the second network device across the L3 transport network.

[0015] In another example, the present disclosure describes a non-transitory computer-readable medium including instructions that, when executed, are configured to cause a processing circuit of a first network device to perform the following operations: receive a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to the first network device via an L2 network; generate a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet including a PIM registration request that is addressed to an RP device and is configured to register the first network device as a multicast source for the multicast group, wherein a header of the unicast L3 packet specifies a source address, the source address including a network address translation (NAT) to an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device; and forward the unicast L3 packet to the second network device across the L3 transport network.

[0016] In another example, the present disclosure describes a method, including: defining, by a first network device, a PIM service for a multicast service between the first network device and a second network device; establishing, by the first network device, a virtual circuit interface; storing, by the first network device, an association between the PIM service and an address of the virtual circuit interface; receiving, by the first network device and from the second network device via an L3 transport network, a unicast L3 packet including a PIM registration request that is addressed to an RP device and is configured to register the second network device as a multicast source for a multicast group associated with the multicast service, wherein a header of the unicast L3 packet specifies a source address that includes an address of the virtual circuit interface of the first network device; and registering, by the first network device and based at least in part on the association between the PIM service and the address of the virtual circuit interface of the first network device specified by the header of the unicast L3 packet, the second network device as a multicast source for the multicast group associated with the multicast service.

[0017] In another example, the present disclosure describes a first network system, comprising: a storage medium, and a processing circuit in communication with the storage medium, the processing circuit being configured to: receive a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to a first network device via an L2 network; generate a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet comprising: a header specifying a source address, the source address being an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device, and a payload containing a PIM registration request to an RP device of the multicast service for registering the first network device as a multicast source of the multicast group; and forwarding the unicast L3 packet to the second network device across the L3 transport network.

[0018] In another example, the present disclosure describes a method, comprising: receiving, by a first network device and from a multicast receiver device, a multicast join request for a multicast group associated with a multicast service; and sending, by the first network device to a second network device based on the received multicast join request, a unicast L3 packet comprising: a header comprising: (1) source address information, the source address information specifying address information of the first network device, and (2) destination address information specifying address information of the second network device; metadata specifying a session identifier for the multicast service; and a payload comprising a PIM join request that is directed to an RP device and is configured to cause the first network device to subscribe to the multicast group.

[0019] In another example, the present disclosure describes a method, comprising: receiving, by a first network device and from a multicast source device, a multicast packet for a multicast group associated with a multicast service; and sending, by the first network device, a unicast L3 packet to a second network device based on the received multicast packet, the unicast L3 packet comprising: a header comprising: (1) source address information, the source address information specifying address information of the first network device, and (2) destination address information specifying address information of the second network device; metadata specifying a session identifier for the multicast service; and a payload comprising a PIM registration request that is directed to an RP device and is configured to register the first network device as a multicast source of the multicast group.

[0020] In another example, the present disclosure describes a method, comprising: receiving, by a hub network device, a first unicast L3 packet from a first branch network device, the first unicast L3 packet comprising: a first header comprising (1) first source address information, the first source address information specifying address information of the first branch network device, and (2) first destination address information specifying address information of the hub network device; first metadata specifying a session identifier for a multicast service; and a first payload comprising a PIM registration request to an RP device, the registration request being configured to register the first branch network device as a multicast source of a multicast group associated with the multicast service; receiving, by the hub network device and from a second branch network device, a second unicast L3 packet, the second unicast L The packet includes: a second header including (1) second source address information, the second source address information specifying address information of the second branch network device, and (2) second destination address information specifying address information of the hub network device; second metadata specifying a session identifier for a multicast service; and a second payload including a PIM join request that is addressed to the RP device and is configured to subscribe the first branch network device to the multicast packet; and storing, by the hub network device and based at least in part on the first unicast L3 packet and the second unicast L3 packet, a multicast route that specifies the first branch network device as being associated with a multicast source device of the multicast group and specifies the second branch network device as being associated with a multicast receiver device of the multicast group.

[0021] The details of one or more examples of the technology of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these technologies will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 is a block diagram illustrating an example computer network system in accordance with techniques of this disclosure.

[0023] Figure 2 is a block diagram illustrating an example computing device in accordance with techniques of this disclosure.

[0024] FIG. 3A to FIG. 3B is a block diagram illustrating an example computer network system in accordance with techniques of this disclosure.

[0025] Figure 4 is a flow chart illustrating example operations in accordance with the techniques of this disclosure.

[0026] Figure 5 is a flow chart illustrating example operations in accordance with the techniques of this disclosure.

[0027] Figure 6is a flow chart illustrating example operations in accordance with the techniques of this disclosure.

[0028] Figure 7 is a flow chart illustrating example operations in accordance with the techniques of this disclosure.

[0029] Figure 8 is a flow chart illustrating example operations in accordance with the techniques of this disclosure.

[0030] Fig. 9 is a block diagram illustrating an example unicast L3 packet encapsulating a PIM registration request in accordance with the techniques of this disclosure.

[0031] Fig.10 is a block diagram illustrating an example unicast L3 packet encapsulating a PIM join request in accordance with the techniques of this disclosure.

[0032] Like reference numerals refer to like elements throughout the drawings and description. DETAILED DESCRIPTION

[0033] Figure 1 is a block diagram illustrating an example computer network system 2 according to the techniques of this disclosure. Figure 1 In an example of the computer network system 2, one or more service provider networks, such as service provider networks 150A to 150D (collectively, "service provider networks 150"), are configured to provide wide area network (WAN) connections to different customer networks 140A to 140B (collectively, "customer networks 140"). Network devices 110A to 110I (collectively, "network devices 110") of service provider networks 150 provide access to service provider networks 150 to client devices 100A to 100B (collectively, "client devices 100") associated with customer networks 140. In some examples, customer networks 140 are enterprise networks. For ease of illustration, customer network 140A is depicted as having a single client device 100A, and customer network 140B is depicted as having a single client device 100B, but each customer network 140 may include any number of client devices.

[0034] In some examples, customer network 140 may be an L2 computer network, where references to a layer followed by a number refer to a corresponding layer in an open systems interconnection (OSI) model. L2 is also referred to as the "data link layer" in the OSI model, and throughout this disclosure, the term L2 may be used interchangeably with the phrase "data link layer." Typically, customer network 140 includes many client devices 100, each of which may communicate with each other across service provider network 150, as described in more detail below. Communication links 16A to 16H (collectively referred to as links "16") may be Ethernet, ATM, or any other suitable network connection. In other examples, customer network 140 may be an L3 network. Common L3 operations include those performed according to L3 protocols, such as Internet Protocol (IP). L3 is also referred to as the "network layer" in the OSI model, and throughout this disclosure, the term L3 may be used interchangeably with the phrase "network layer."

[0035] Network device 110 may be implemented using any network device, such as a switch, router, gateway, or other suitable network device that can send and receive network traffic. For example, customer network 140 may be a network of geographically separated sites of an enterprise. Each of customer networks 140 may include additional customer equipment, such as one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection and / or intrusion prevention devices), servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or Figure 1 Other routers not depicted. Figure 1 The configuration of the computer network system 2 shown in is merely an example. For example, the computer network system 2 may include any number of customer networks 140. However, for ease of description, Figure 1 Only customer networks 140A-140B are shown.

[0036] Service provider network 150 represents one or more publicly accessible computer networks owned and operated by one or more service providers. Figure 1 1 is shown as including multiple interconnected service provider networks 150, but in other examples, the computer network system 2 may instead include a single service provider network that provides connections between customer networks 140. Service providers are typically large telecommunications entities or companies. Each of the service provider networks 150 is typically a large L3 computer network. Each service provider network 150 is an L3 network because it natively supports L3 operations as described in the OSI model.

[0037] Although not shown, each service provider network 150 may be coupled to one or more networks managed by other providers and may therefore form part of a large-scale public network infrastructure (e.g., the Internet). Therefore, customer networks 140 may be considered edge networks of the Internet. Each service provider network 150 may provide computing devices (such as client devices 100) within customer networks 140 with access to the Internet and may allow computing devices within customer networks 140 to communicate with each other.

[0038] Although additional routers are not shown for ease of explanation, it should be understood that system 2 may include additional network and / or computing devices, such as, for example, one or more additional switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection, and / or intrusion prevention devices), servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other routers. In addition, although the elements of system 2 are shown as being directly coupled, it should be understood that one or more additional network elements may be included along any of network links 16 such that the network elements of system 2 are not directly coupled.

[0039] Each service provider network 150 typically provides a number of residential and business services to customer networks 140, including residential and business-grade data services (commonly referred to as "Internet services" because these data services allow access to a collection of publicly accessible networks known as the Internet), residential and business-grade telephone and / or voice services, and residential and business-grade television services.

[0040] In some examples, the network device 110 can implement a stateful, session-based routing scheme that enables each of the network devices 110 to independently perform path selection and traffic engineering. Using session-based routing can enable the network device 110 to avoid using a centralized controller (such as a software-defined network (SDN) controller) to perform path selection and traffic engineering. In this way, the network device 110 can be more efficient and scalable for large networks where the use of an SDN controller would not be feasible. In addition, using session-based routing can enable the network device 110 to avoid using tunnels, thereby saving a large amount of network resources by eliminating the need to perform encapsulation and decapsulation at the tunnel endpoints. In some examples, the network device 110 implements session-based routing as a secure vector routing (SVR) provided by Juniper Networks. In some examples, the network device 110 includes an Ethernet over SVR (EoSVR) router.

[0041] exist Figure 1In the example of , client device 100A of system 2 establishes session 40 (shown by dashed lines) with client device 100B. Network device 110 facilitates establishment of session 40 by transmitting network traffic between client device 100A and client device 100B. In some examples, client device 100A can be considered a "source" device because client device 100A initiates session 40 between client device 100A and client device 100B, for example, client device 100A is the "source" of packets of the forward flow of the session. Session 40 includes a forward packet flow originating from client device 100A and destined for client device 100B and a reverse packet flow originating from client device 100B and destined for client device 100A. The forward flow of session 40 traverses a first path, including, for example, client device 100A, network devices 110A to 110I, and client device 100B.

[0042] In some examples, the network device 110 can extend the session 40 to an L3 session across the service provider network 150 according to one or more L3 communication session protocols, including the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP), etc. For example, in order to establish the session 40 according to TCP so that data can be exchanged according to TCP, the client device 100A and the client device 100B perform a three-way handshake. The client device 100A sends a first packet with a "SYN" flag to the client device 100B. The client device 100B confirms the receipt of the first packet by responding to the client device 100A with a second packet with a "SYN-ACK" flag. The client device 100A confirms the receipt of the second packet by responding to the client device 100B with a third packet including an "ACK" flag. After sending the third packet, the session 40 is established according to TCP, and the client devices 100A, 100B can exchange data with each other via the session 40. Additional example information about TCP is described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 793, "TRANSMISSION CONTROL PROTOCOL," September 1981, available at https: / / tools.ietf.org / html / rfc793, the entire contents of which are incorporated herein by reference.

[0043] UDP is a connectionless protocol because client device 100A does not verify that client device 100B is able to receive data before sending data. To establish session 40 according to UDP, client device 100A sends a first packet to client device 100B. When client device 100A receives any packet from client device 100B, session 40 can be considered "established" according to UDP, meaning that client device 100B successfully received the first packet from client device 100A, responded, and client device 100A was able to receive the response from client device 100B. Additional example information about UDP is described in "User Datagram Protocol" RFC 768 of the IETF, August 28, 1980, which is available at https: / / tools.ietf.org / html / rfc768, the entire contents of which are incorporated herein by reference.

[0044] exist Figure 1 In the examples of FIG. 4 , when network device 110A receives a packet of a forward packet flow originating from client device 100A and destined for client device 100B, network device 110A determines whether the packet belongs to a new session (e.g., is the “first” packet or “lead” packet of session 40). In some examples, network device 110A determines whether session information (e.g., source address, source port, destination address, destination port, and protocol) of the first packet matches an entry in the session table.

[0045] If no such entry exists, the network device 110A determines that the packet belongs to a new session and creates an entry in the session table. In addition, if the packet belongs to a new session, the network device 110A may generate a session identifier for the session 40. The session identifier may include, for example, the source address and source port of the client device 100A, the destination address and destination port of the client device 100B, and the protocol used by the first packet. The network device 110A may use the session identifier to identify subsequent packets as belonging to the same session.

[0046] In some examples, network device 110 performs stateful routing for session 40. For example, network device 110 may forward each packet of a forward packet flow of session 40 sequentially and along the same forward network path. As described herein, the "same" forward path may refer to the same network device 110 that forms a segment or at least a portion of a path between a device that originates a packet and a destination device of the packet (but not necessarily the entire network path between the device that originates the packet and the destination device of the packet). In addition, network device 110 forwards each packet of a return flow of session 40 sequentially and along the same return network path. The forward network path for the forward packet flow of session 40 and the return network path for the return packet flow of session 40 may be the same path or different paths. By ensuring that each packet of the flow is forwarded sequentially and along the same path, network device 110 maintains the state of the entire flow at each network device 110, thereby enabling the use of stateful packet services, such as deep packet inspection (DPI).

[0047] exist Figure 1 In an example of , a stateful routing session can be established from network device 110A (which can be an ingress network device) through intermediate network devices (such as network devices 110B to 110H) to network device 110I (which can be an egress network device). In this example, network device 110A determines that the first packet is an unmodified packet and the first packet of a new session 40. Network device 110A modifies the first packet to include metadata specifying a session identifier. In some examples, the metadata can be inserted after the header of the modified first packet. The session identifier can include, for example, an original source address, a source port, a destination address, a destination port, a protocol, a service, and / or a tenant. Network device 110A replaces the header of the modified first packet to specify a source address that is the address of network device 110A, a source port that is the port via which network device 110A forwards the modified first packet to client device 100B, a destination address that is the address of the next hop to which network device 110A forwards the first packet (e.g., the address of network device 110B), and a destination port that is the port of the next hop to which network device 110A forwards the first packet (e.g., the port of network device 110B).

[0048] The network device 110A may also identify a network service associated with the session 40. For example, the network device 110A may compare one or more of the source address, source port, destination address, or destination port for the session with a table of service address and port information to identify the service associated with the session. Examples of network services include Hypertext Transfer Protocol (HTTP), firewall services, proxy services, packet monitoring or measurement services, etc. For example, the network device 110A may determine that the forward packet flow of the session 40 specifies the destination address and destination port assigned to the client device 100B. Thereafter, the network device 110A may store the association between the session 40 and the identified network service. As another example, if the source port and / or destination port of the session 40 is 80, the network device 110A may determine that the session 40 is associated with the HTTP service. In other examples, the network device 110A may determine that one or more of the source address, source port, destination address, or destination port of the session 40 belongs to an address block or port indicating that a particular service is associated with the session 40.

[0049] In some examples, network device 110A uses the determined network service for session 40 to select a forwarding path for forwarding the first packet and each subsequent packet of the forward packet flow of session 40 to client device 100B. In this way, network device 110A can perform service-specific path selection to select a network path that best suits the service requirements. In contrast to network topologies that use an SDN controller to perform path selection, each of network devices 110 performs path selection. In addition, the use of session-based routing enables each of network devices 110 to make routing decisions at a service or application level, as compared to traditional network devices that can only make routing decisions at a flow level.

[0050] Additionally, network device 110A may store a session identifier for session 40 so that upon receiving subsequent packets for session 40, network device 110A may identify the subsequent packets as belonging to the same session 40 and forward the subsequent packets along the same path as the first packet. In some examples, upon receiving such subsequent packets, network device 110A may forward the subsequent packets without metadata specifying the session identifier.

[0051] Intermediate network device 110B receives the modified first packet from network device 110A. Network device 110B determines whether the modified first packet includes metadata specifying a session identifier. In response to determining that the modified first packet includes metadata specifying the session identifier, intermediate network device 110B determines that network device 110B is not an ingress device, such that network device 110B does not append metadata specifying the session identifier.

[0052] As described above with respect to network device 110A, network device 110B determines whether the packet belongs to a new session (e.g., is the "first" packet or the "lead" packet of the session) by determining whether the source address, source port, destination address, destination port, and protocol of the first packet match an entry in the session table. If no such entry exists, network device 110B may determine that the packet belongs to a new session and create an entry in the session table. In addition, if the packet belongs to a new session, network device 110B may generate a session identifier for the session. The session identifier used by network device 110B to identify the session for the first packet may be different from the session identifier used by network device 110A to identify the same session for the first packet because each network device 110A, 110B uses the header source address, source port, destination address, and destination port of the first packet to generate the session identifier, and when each of network devices 110 forwards the first packet along the forward path, the header information may be modified by each preceding network device of network device 110. In addition, each of network devices 110 can store the header information to identify the previous network device (or "waypoint") of network device 110 and the next network device (or "waypoint") of network device 110 so that each of network devices 110 can reconstruct the same forward path and reverse path for each subsequent packet of the session.

[0053] Network device 110B may replace the header of the modified first packet to specify a source address that is the address of network device 110B, a source port that is the port via which network device 110A forwards the modified first packet to client device 100B, a destination address that is the address of a next hop to which network device 110B may forward the first packet (e.g., the address of network device 110C for session 40 along the first path), and a destination port that is the port of the next hop to which network device 110B may forward the first packet (e.g., the port of network device 110C). Network device 110B forwards the modified first packet to network device 110C. In addition, network device 110B may store a session identifier for the session so that upon receiving subsequent packets for the session, network device 110B may identify the subsequent packets as belonging to the same session and forward the subsequent packets along the same path as the first packet.

[0054] Subsequent intermediate network devices, such as network devices 110C through 110H, may process the modified first packet in a similar manner as network devices 110A and 110B, such that network device 110 forwards subsequent packets of the session along the same path as the first packet. In addition, each of network devices 110 may store a session identifier for the session, which may include an identification of a previous network device of network device 110 along the network path. Thus, each of network devices 110 may forward packets of a reverse packet flow for the session back to client device 100A along the same network path using the session identifier.

[0055] A network device in the network device 110 that can forward packets of a forward packet flow of a session to a destination for the packet flow can be referred to as an egress or "terminal" network device. In the aforementioned example, since the network device 110I can forward packets to the client device 100B, the network device 110I is a terminal network device. The network device 110I receives a modified first packet that includes metadata specifying a session identifier (e.g., an original source address, a source port, a destination address, and a destination port). The network device 110I determines that the modified first packet is destined for a service that terminates at the network device 110I by determining that the destination source address and the destination source port specified in the metadata of the modified lead packet correspond to a destination reachable by the network device 110I (e.g., the client device 100B). The network device 110I restores the original first packet by removing the metadata from the modified first packet and using the metadata to modify the header of the first packet to specify the original source address and source port of the client device 100A, and the destination address and destination port of the client device 100B. Network device 1101 forwards the recovered first packet to client device 100B. Thus, the use of session-based routing may form a series of waypoints (eg, network devices 110) interconnected by path "segments" (eg, end-to-end routing vectors between each waypoint).

[0056] Additional information about session-based routing and SVR is described in the following documents: U.S. Patent No. 9,729,439, entitled “COMPUTER NETWORK PACKET FLOW CONTROLLER,” issued on August 8, 2017; Internet Engineering Task Force (IETF), “Secure Vector Routing (SVR),” draft-menon-svr-00, dated October 1, 2021, available at https: / / datatracker.ietf.org / doc / draft-menon-svr / 00 / ; Internet Engineering Task Force (IETF), “Secure Vector Routing (SVR),” draft-menon-svr-01, Internet-Draft, dated March 29, 2022, available at https: / / datatracker.ietf.org / doc / draft-menon-svr / 01 / ; and Internet Engineering Task Force (IETF), “Secure Vector Routing (SVR),” draft-menon-svr-02, Internet-Draft, dated September 20, 2022. (SVR)", draft-menon-svr-02, Internet-Draft, available at https: / / datatracker.ietf.org / doc / draft-menon-svr / 02 / ; the entire contents of each of the above documents are incorporated herein by reference.

[0057] Bidirectional Forwarding Detection (BFD) is a network protocol for detecting failures in a bidirectional path between two network devices, such as link 16B between network devices 110A and 110B. BFD provides low-overhead, short-duration detection of failures in a link between two network devices. In addition, BFD provides a single mechanism that can be used for active detection on any medium at any protocol layer, with a wide range of detection times and overhead to avoid the proliferation of different methods between adjacent devices. BFD operates on top of any data protocol (network layer, link layer, tunnel, etc.), forwarding between two network devices. Typically, BFD operates in unicast, point-to-point mode. BFD packets are carried as payloads of any encapsulation protocol suitable for the medium and network.

[0058] According to BFD, network devices 110A and 110B establish a session via link 16B. Typically, network devices 110A and 110B establish and tear down a BFD session using a three-way handshake. Typically, network devices 110A and 110B may declare link 16B to be operable only after bidirectional communication is established between network devices 110A and 110B. However, this does not exclude the use of unidirectional links. For example, link 16B may represent a first unidirectional link from network device 110A to network device 110B, and a second unidirectional link from network device 110B to network device 110A.

[0059] Once the BFD session is established, network devices 110A and 110B periodically send BFD packets over link 16B. Each network device 110A, 110B estimates how fast it can send and receive BFD packets in order to negotiate with peer network devices 110A, 110B how fast fault detection can occur. In some examples, network devices 110A and 110B can modify these estimates in real time to adapt to network congestion, changes in delay or bandwidth, or other abnormal situations. This can allow the use of a shared medium between fast network devices and slow network devices, while allowing fast network devices to detect faults more quickly, while allowing slow network devices to participate in fault detection.

[0060] BFD can operate in two modes: asynchronous mode and demand mode. In asynchronous mode, if one of network devices 110A and 110B stops receiving BFD packets for a certain amount of time (the length of which is negotiated as described above), network devices 110A and 110B can assume that link 16B (or components, devices, or paths forming link 16B) has failed. In demand mode, network devices 110A and 110B can negotiate not to send periodic BFD packets in order to reduce overhead. This assumes that network devices 110A and 110B have another way to verify connectivity to each other, such as via the physical layer. However, if necessary, either of network devices 110A, 110B can still send BFD packets.

[0061] In addition, either of the network devices 110A, 110B may use an Echo function. When this function is activated, the network device 110A, for example, sends an Echo packet stream to the network device 110B. The network device 110B responds by sending the Echo packet back to the network device 110A via the forwarding plane of the network device 110B. The network device 110A may use the Echo function to test the forwarding path to the network device 110B, and vice versa. Additional example information about BFD is described in the following documents: "Bidirectional Forwarding Detection (BFD)", RFC 5880, IETF, June 2010, available at https: / / datatracker.ietf.org / doc / html / rfc5880; and "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC5881, IETF, June 2010, available at https: / / datatracker.ietf.org / doc / rfc5881 / , the entire contents of each of which are incorporated herein by reference.

[0062] Network device 110 creates a separate BFD session for each communication path and data protocol used between the two network devices. For example, in order to perform fault detection along the entire path of session 40 between network devices 110A and 110I, a different BFD session may be established along each link 16, such as a first BFD session between network devices 110A and 110B along the first link, a second BFD session between network devices 110B and 110C along link 16C, and so on.

[0063] In some examples, it may not be feasible to use a dedicated BFD session between two network devices. For example, a hub network device may be connected to a large number of spoke network devices (e.g., dozens, hundreds, or more network devices). If such a hub network device were to maintain a dedicated BFD session with each spoke network device to which the hub network device is connected, the BFD packets sent and received by the hub network device may consume a large amount of network resources. Therefore, the use of dedicated BFD sessions may consume network resources that could otherwise be used to send and receive client traffic.

[0064] In some examples, in order to reduce the consumption of network resources for performance monitoring, network device 110 may use inflow performance monitoring. For example, each network device 110 may modify a packet carrying client data for a session between client devices 100 to include metadata containing performance information. For example, a session between client device 100A and client device 100B consists of a forward flow originating from client device 100A and destined for client device 100B and a reverse flow originating from client device 100B and destined for client device 100A. Network device 110A receives a first packet of the forward flow from client device 100A, the first packet including a header and a data payload. Network device 110A modifies the first packet to further include metadata containing first performance information, and forwards the modified first packet to network device 110B. Network device 110B may obtain the first performance information from the metadata of the first packet. In addition, network device 110B may remove the metadata and forward the first packet to client device 100B (e.g., by forwarding the packet to network device 110C).

[0065] In addition, network device 110B receives a second packet of the reverse flow from client device 100B, the second packet including a header and a data payload. Network device 110B modifies the second packet to further include metadata including the second performance information, and forwards the modified second packet to network device 110A. Network device 110A may obtain the second performance information from the metadata of the second packet. In addition, network device 110A may remove the metadata and forward the second packet to client device 100A.

[0066] In some examples, the metadata includes a BFD packet. In some examples, the metadata includes a timestamp that network devices 110A, 110B can use to determine performance information. In some examples, the metadata includes measurements of network performance, such as measurements of delay, jitter, packet loss, bandwidth, etc. For example, network device 110A modifies a first packet of a forward flow to include metadata specifying a first timestamp, which indicates the time when network device 110A forwarded the first packet to network device 110B. Network device 110B modifies a second packet of a reverse flow to include metadata specifying a second timestamp and / or a third timestamp, the second timestamp indicating the time when network device 110B received the first packet from network device 110A, and the third timestamp indicating the time when network device 110B forwarded the second packet to network device 110A. Network devices 110A and 110B can exchange multiple such modified packets to obtain multiple data points about the performance of link 16B between network devices 110A and 110B. For example, network device 110A may process multiple timestamps to generate metrics of link 16B between network devices 110A and 110B, such as latency, jitter, packet loss, bandwidth, etc. In this manner, network devices 110A and 110B may perform performance monitoring on link 16B without interrupting customer traffic between client devices 100 or consuming additional network resources by using a dedicated BFD session for performance monitoring.

[0067] PIM is a family of routing protocols used to facilitate the distribution of multicast traffic over large networks, such as a LAN, WAN, or the Internet. PIM is protocol-independent because PIM can use routing information provided by other routing protocols, such as BGP. PIM can operate in sparse mode or dense mode. Network devices that employ PIM dense mode flood multicast traffic to every other peer network device, and therefore PIM dense mode does not scale well due to the volume of traffic for large networks.

[0068] Network devices using PIM sparse mode can determine the optimal RP between multicast sender devices and multicast receiver devices, and create a shortest path tree for distributing multicast messages. PIM sparse mode can be more effectively scaled for large networks. When a multicast source device sends one or more multicast packets to a multicast group, the designated router (DR) of the multicast source device sends a unicast PIM registration request encapsulating the one or more multicast packets to the RP. The RP registers the DR of the multicast source device as a multicast source for the multicast group.

[0069] A multicast receiver device indicates a desire to join a multicast group by sending a join request, such as an Internet Group Management Protocol (IGMP) group join request, to the DR of the multicast receiver device. The DR of the multicast receiver device sends a PIM join request to the RP, which in turn registers the DR of the multicast receiver device as a multicast receiver for the multicast group. Periodically, the DR of the multicast source device, the DR of the multicast receiver device, the RP, or another intermediate network device may send a PIM prune message to remove network devices that are not connected to the multicast receiver device from the distribution tree.

[0070] Additional example information regarding PIM and PIM coefficient modes is described in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2117, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification," June 1998, available at https: / / www.ietf.org / rfc / rfc2362.txt, the entire contents of which are incorporated herein by reference.

[0071] According to the techniques of the present disclosure, network device 110 exchanges PIM messages across an L3 transport network, such as one or more service provider networks 150. In one example, network device 110A is connected to client 100A via an L2 network, such as customer network 140A. Client device 100A operates as a multicast sender device for a multicast group associated with a multicast service. Network device 110A is also connected to network device 110B via an L3 transport network, such as service provider network 150A. Service provider network 150A may be, for example, a session-routed transport network or an MPLS transport network.

[0072] The network device 110B defines a PIM service for multicast services between the network device 110A and the network device 110B. Figure 1 In the example of FIG. 1 , network device 110A and network device 110B may or may not be directly connected. For example, one or more intermediate network devices (in the example of FIG. 1 ) of service provider network 150A may be directly connected to network device 110B. Figure 1 ) may provide a connection between network devices 110A and 110B.

[0073] Network device 110B establishes a virtual circuit interface and stores an association between the PIM service and the address of the virtual circuit interface. Network device 110A learns the address of the virtual circuit interface of network device 110B associated with the PIM service for multicast services between network devices 110A, 110B via a routing protocol such as BGP. In some examples, the address of the virtual circuit interface of network device 110B is used as a service identifier for the PIM service for multicast services between network devices 110A, 110B.

[0074] The network device 110A receives a multicast packet for a multicast group associated with a multicast service from a multicast sender device 100A via an L2 network 140A. The network device 110A generates a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet including a PIM registration request that is directed to an RP device and configured to register the network device 110A as a multicast source of the multicast group. The header of the unicast L3 packet specifies a source address that is a network address translation (NAT) of an address of a virtual circuit interface of the network device 110B. In some examples, the network device 110A performs NAT of the address of the multicast sender device to the address of the virtual circuit interface of the network device 110B. In some examples, the network device 110A performs NAT of the address of the network device 110A to the address of the virtual circuit interface of the network device 110B. The network device 110A forwards the unicast L3 packet to the network device 110B across the L3 transport network 150A.

[0075] The network device 110B receives the unicast L3 packet. The network device 110B determines that the PIM registration request is associated with a multicast group associated with the multicast service based at least in part on a stored association between the PIM service and the address of the virtual circuit interface of the network device 110B. The network device 110B registers the network device 110A as a multicast source for the multicast group associated with the multicast service.

[0076] In some examples, as described above, service provider network 150A is a transport network based on session routing. In this example, network device 110A performs session-based routing to forward a unicast L3 packet to network device 110B. For example, network device 110A modifies a header of the unicast L3 packet to specify an address of network device 110A as a source address and an address of network device 110B as a destination address. In addition, network device 110A adds metadata specifying an address of a virtual circuit interface of network device 110B to the unicast L3 packet. Upon receiving the unicast L3 packet, network device 110B may modify the header of the unicast L3 packet based at least in part on the metadata to specify an address of a virtual circuit interface of a second network device as a source address of the unicast L3 packet and remove the metadata from the unicast L3 packet.

[0077] Additional information regarding the use of PIM and session-based routing is discussed in U.S. Patent No. 11,005,749, entitled “Multicast source and receiver access control,” issued on May 11, 2021, and U.S. Patent No. 11,070,465, entitled “Distribution of multicast information in a routing system,” issued on July 20, 2021, the entire contents of each of which are incorporated herein by reference.

[0078] In some examples, as described above, service provider network 150A is an MPLS transport network. In such examples, network device 110A forwards the unicast L3 packet across the MPLS transport network by encapsulating the unicast L3 packet with one or more MPLS labels. Upon receiving the unicast L3 packet, network device 110B removes the one or more MPLS labels from the unicast L3 packet.

[0079] The foregoing examples involve sending a PIM registration request across a transport network in response to network device 110A receiving a multicast packet of client device 100A operating as a multicast source device. However, the techniques of this disclosure may be equally applicable to any type of PIM message to be forwarded across a transport network, such as a PIM join request or a PIM prune request.

[0080] For example, network device 110I receives an IGMP group join request for a multicast group from client device 100B operating as a multicast receiver device. Network device 110I generates a unicast L3 packet containing a PIM join request to register network device 110I as a multicast receiver for the multicast group, the unicast L3 packet also including a header specifying a destination address, the destination address being an address of a virtual circuit interface of network device 110H, wherein the virtual circuit interface of network device 110H is associated with a PIM service between network device 110H and network device 110I for a multicast service associated with the multicast group. Network device 110I forwards the unicast L3 packet including the PIM join request to network device 110H. Network device 110H may register network device 110I as a multicast receiver for the multicast group based at least in part on the virtual circuit interface of network device 110H specified by the unicast L3 packet. In addition, network device 110H may forward the PIM join request to the RP for the multicast service using similar techniques.

[0081] As another example, network device 1101 may forward a unicast L3 packet containing a PIM prune message and further specifying a source address that is an address of a virtual circuit interface of network device 110H, wherein the virtual circuit interface of network device 110H is associated with a PIM service for a multicast service associated with a multicast group between network device 110H and network device 1101. Network device 110H may perform pruning of one or more network devices in accordance with the PIM prune message and forward the PIM prune message to the RP for the multicast service using similar techniques.

[0082] Figure 2 is a block diagram illustrating an example computing device 200 according to the techniques of the present disclosure. In general, computing device 200 may be Figure 1 The computing device 200 includes a processing circuit 202 for executing any one or more of the application 222, the routing component 250, or any other computing device described herein. Other examples of the computing device 200 may be used in other instances to implement the techniques of the present disclosure. Figure 2 200 is shown in the examples as a single device, but in some examples, computing device 200 may be implemented as a computing system distributed across multiple devices, such as in a distributed computing or cloud computing environment, for example.

[0083] Although for the purposes of this example Figure 2 200, but a computing device operating according to the techniques of the present disclosure may be any component or system including one or more processors or other suitable computing environment for executing software instructions, and does not necessarily need to include, for example, Figure 2 206; and in some examples, components such as one or more storage devices 208 may not be co-located with other components or in the same chassis. In some examples, computing device 200 may be implemented as a virtualized network function (VNF). In some examples, one or more aspects of computing device 200 may run as one or more containers or as one or more applications within a virtual machine of a network function virtualization (NFV) platform, such as virtual input and output (VirtIO) and single root input / output virtualization (SR-IOV) network virtualization technologies, or on a bare metal server. In some examples, computing device 200 is a physical network device, such as a switch, router, gateway, or other device that sends and receives network traffic.

[0084] like Figure 2As shown in the example of , the computing device 200 includes a processing circuit 202, one or more input devices 204, one or more communication units 206, one or more output devices 212, one or more storage devices 208, and one or more user interface (UI) devices 210. In one example, the computing device 200 also includes one or more applications 222 and an operating system 216 that can be executed by the computing device 200. Each of the components 202, 204, 206, 208, 210, and 212 is coupled (physically, communicatively, and / or operationally) for inter-component communication. In some examples, one or more communication channels 214 may include a system bus, a network connection, an inter-process communication data structure, or any other method for transmitting data. As an example, the components 202, 204, 206, 208, 210, and 212 may be coupled via one or more communication channels 214.

[0085] In one example, processing circuit 202 is configured to implement functions and / or process instructions for execution within computing device 200. In some examples, processing circuit 202 includes one or more hardware-based processors. For example, processing circuit 202 is capable of processing instructions stored in storage device 208. Examples of processing circuit 202 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or equivalent discrete or integrated logic circuits.

[0086] One or more storage devices 208 may be configured to store information within computing device 200 during operation. In some examples, one or more storage devices 208 are described as computer-readable storage media. In some examples, one or more storage devices 208 include temporary storage, which means that the primary purpose of storage device 208 is not long-term storage. In some examples, one or more storage devices 208 include volatile memory, which means that one or more storage devices 208 do not maintain the stored content when the computer is turned off. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory. In some examples, one or more storage devices 208 store program instructions for execution by processing circuit 202. In one example, one or more storage devices 208 are used by software or applications running on computing device 200 to temporarily store information during program execution.

[0087] In some examples, the one or more storage devices 208 also include one or more computer-readable storage media. The one or more storage devices 208 can be configured to store a larger amount of information than a volatile memory. The one or more storage devices 208 can also be configured for long-term storage of information. In some examples, the one or more storage devices 208 include a non-volatile storage element. Examples of such non-volatile storage elements include a magnetic hard disk, an optical disk, a floppy disk, a flash memory, or an electrically programmable memory (EPROM) or an electrically erasable programmable (EEPROM) memory.

[0088] In some examples, the computing device 200 also includes one or more communication units 206. In one example, the computing device 200 uses the one or more communication units 206 to communicate with external devices via one or more networks (such as one or more wired / wireless / mobile networks). The one or more communication units 206 may include a network interface, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. Other examples of such network interfaces may include 3G / 4G / 5G and WiFi radios. In some examples, the one or more communication units 206 may include multiple high-speed network interface cards. In some examples, the computing device 200 uses the one or more communication units 206 to communicate with external devices. For example, the computing device 200 uses the one or more communication units 206 to communicate with external devices via the one or more communication units 206 to which it is connected. Figure 1 Link 16 and Figure 1 Communicate with other network devices 110 and / or client devices 100.

[0089] In one example, computing device 200 also includes one or more user interface devices 210. In some examples, user interface device 210 is configured to receive input from a user through tactile, audio, or video feedback. Examples of one or more user interface devices 210 include a presence-sensitive display, a mouse, a keyboard, a voice response system, a camera, a microphone, or any other type of device for detecting commands from a user. In some examples, the presence-sensitive display includes a touch-sensitive screen. In some examples, a user such as an administrator of service provider network 150 can input configuration data of computing device 200.

[0090] One or more output devices 212 may also be included in the computing device 200. In some examples, the one or more output devices 212 are configured to provide output to the user using tactile, audio, or video stimulation. In one example, the one or more output devices 212 include a presence-sensitive display, a sound card, a video graphics adapter card, or any other type of device for converting signals into an appropriate form understandable to a human or machine. Additional examples of the one or more output devices 212 include speakers, cathode ray tube (CRT) monitors, liquid crystal displays (LCDs), or any other type of device that can generate understandable output to a user.

[0091] The computing device 200 may include an operating system 216. In some examples, the operating system 216 controls the operation of the components of the computing device 200. For instance, in one example, the operating system 216 facilitates communication of one or more applications 222 with the processing circuit 202, one or more communication units 206, one or more storage devices 208, one or more input devices 204, one or more user interface devices 210, and one or more output devices 212. The applications 222 may also include program instructions and / or data that may be executed by the computing device 200.

[0092] In some examples, processing circuit 202 executes routing component 250, which determines the route of the received packet and forwards the packet accordingly. Routing component 250 can be used with other routers such as Figure 1 network devices 110) to establish and maintain computer networks (such as Figure 1 A computer network system 2 of the present invention is used to transmit network traffic between one or more client devices. The routing protocol daemon (RPD) 254 of the routing component 250 can execute software instructions to implement one or more control plane networking protocols 256. For example, the protocol 256 may include one or more routing protocols, such as IGMP 221 and / or Border Gateway Protocol (BGP) 220, for exchanging routing information with other routing devices and for updating the routing information base (RIB) 252, Multi-Protocol Label Switching (MPLS) protocol 215, PIM 225, and other routing protocols. The protocol 256 may also include one or more communication session protocols 223, such as TCP, UDP, TLS, or ICMP. The protocol 256 additionally includes BFD 224.

[0093] Routing information 252 may describe the topology of the computer network in which computing device 200 resides, and may also include routes through shared trees in the computer network. Routing information 252 may describe various routes within the computer network and the appropriate next hop for each route, such as adjacent routing devices along each route. Routing information 252 may be programmed into a dedicated forwarding chip, a series of tables, a complex database, a linked list, a radix tree, a database, a flat file, or a variety of other data structures.

[0094] Session information 235 stores information for identifying a session. In some examples, session information 235 is in the form of a session table. For example, service information 232 includes one or more entries that specify a session identifier. In some examples, the session identifier includes one or more of a source address, a source port, a destination address, a destination port, or a protocol associated with a forward packet flow and / or a reverse packet flow of the session. As described above, when routing component 250 receives a packet from a session, the session identifier is a session identifier. Figure 1 When routing component 250 receives a packet of a forward packet flow from client device 100A to client device 100B, routing component 250 determines whether the packet belongs to a new session (e.g., is the "first" packet or the "lead" packet of session 40). To determine whether the packet belongs to a new session, routing component 250 determines whether session information 235 includes an entry corresponding to the source address, source port, destination address, destination port, and protocol of the first packet. If an entry exists, the session is not a new session. If no entry exists, the session is new, and routing component 250 generates a session identifier for the session and stores the session identifier in session information 235. Routing component 250 can thereafter use the session identifier stored in session information 235 for the session to identify subsequent packets as belonging to the same session.

[0095] The service information 232 stores information that the routing component 250 can use to identify the service associated with the session. In some examples, the service information 232 is in the form of a service table. For example, the service information 232 includes one or more entries that specify a service identifier and one or more of a source address, source port, destination address, destination port, or protocol associated with the service. In some examples, the routing component 250 can query the service information 232 for the received packet using one or more of the source address, source port, destination address, destination port, or protocol of the session to determine the service associated with the session. For example, the routing component 250 can determine the service identifier based on the correspondence between the source address, source port, destination address, destination port, or protocol in the service information 232 and the source address, source port, destination address, destination port, or protocol specified by the session identifier. The routing component 250 retrieves one or more service policies 234 corresponding to the identified service based on the service associated with the packet. The service policy may include, for example, a path failover policy, a dynamic host configuration protocol (DHCP) tag policy, a traffic engineering policy, a priority of network traffic associated with the session, and the like. Routing component 250 applies one or more service policies 234 to the packet corresponding to the services associated with the packet.

[0096] In some examples, computing device 200 may be used as Figure 1 Any one of the network devices 110 operates. Figure 2 In the following example, computing device 200 operates as network device 110A. Computing device 200 receives a packet from client device 100A that is destined for client device 100B via one or more communication units 206. In response to receiving the packet, computing device 200 generates an L3 packet that includes an L3 header and metadata, the metadata including a source IP address and source port of client device 100A and a destination IP address and destination port of client device 100B.

[0097] In some examples, the metadata includes a session identifier. The session identifier is a unique identifier for a session that includes a first packet flow originating from a first client device (e.g., client device 100A) and destined for a second client device (e.g., client device 100B) and a second packet flow originating from the second client device and destined for the first client device. Typically, the session identifier includes a 5-tuple, such as a source IP address and source port of the first client device, a destination IP address and destination port of the second client device, and a network protocol used by the session.

[0098] In this example, the packet is a first packet of a plurality of packets for a session. In response to receiving the first packet, computing device 200 may generate a session identifier for the session between client device 100A and client device 100B, and store the session identifier in session information 235 (e.g., to store metadata of the L3 packet). As described above, computing device 200 may generate an L3 packet including an L3 header and metadata based on the first packet. Computing device 200 forwards the L3 packet to a next-hop router (network device 110B) via one or more communication units 206.

[0099] For subsequent packets, computing device 200 may determine, based on information (e.g., a 5-tuple) of the subsequent packets, that the subsequent packets belong to the same session as the first packet. For example, in response to receiving a second packet of a session, computing device 200 may perform a lookup of session information 235 and determine, based on a source address, source port, destination address, destination port, and / or protocol specified by the second packet, that the second packet belongs to a session having a corresponding entry within session information 235.

[0100] In response to determining that the subsequent packet belongs to the same session as the first packet, computing device 200 may generate a subsequent L3 packet including an L3 header but not metadata for the subsequent packet (because the session identifier associated with the given session has been stored by, for example, each subsequent router that receives the first packet).

[0101] The computing device 200 may forward subsequent L3 packets to the same next-hop network device 110B. Intermediate network devices (e.g., network devices 110B to 110H) may receive the subsequent L3 packets and identify the session associated with the subsequent L3 packets from the L3 headers of the subsequent L3 packets, and use the stored metadata to perform session-based routing of the subsequent L3 packets. In this manner, the computing device 200 may modify only the first L3 packet of the multiple L3 packets generated for the session to include the metadata, thereby avoiding including the metadata in each of the multiple L3 packets generated for the session, while still ensuring that each of the multiple L3 packets is forwarded along the same path (e.g., to the same next-hop network device 110), and the original packet may be recovered from the L3 packet by an egress router (such as network device 110I).

[0102] refer to Figure 2 In the following example, computing device 200 operates as network device 110I and receives a modified L3 packet as described above from network device 110H. For example, computing device 200 receives an L3 packet having an L3 header and metadata via one or more communication units 206.

[0103] If the L3 packet is the first L3 packet of multiple L3 packets for a session, the computing device 200 can use the metadata to generate a session identifier for the session between the client device 100A and the client device 100B, and store the session identifier in the session information 235 (e.g., to store the metadata of the L3 packet). In response to determining that the packet is destined for a client device coupled to the network device 110I, the computing device 200 can use the metadata of the L3 packet to recover the original packet. For example, the computing device 200 can use the metadata to modify the header of the packet to specify the original source address, source port, destination address, and destination port. The computing device 200 then forwards the recovered packet to the client device 100B.

[0104] The computing device 200 may also receive subsequent L3 packets that do not include metadata in the plurality of L3 packets. For these subsequent L3 packets, the computing device 200 may determine that the subsequent L3 packets belong to the same session as the first L3 packet based on the L3 header (e.g., the source IP address and source port of the previous hop router and the destination IP address and destination port of the network device 110I). The computing device 200 may determine the original destination port and destination address of the packet from the metadata of the stored first L3 packet. The computing device 200 may forward the subsequent packets to the client device 100A via one or more communication units 206. In this way, the computing device 200 may receive only the first L3 packet that specifies metadata, while subsequent L3 packets do not include such information. Thus, the network device 110 as described herein may avoid including metadata in each of the plurality of L3 packets generated for the session, while still ensuring that each of the plurality of L3 packets is forwarded along the same path (e.g., to the same next hop network device 110).

[0105] According to the technology of the present disclosure, the computing device 200 can cross the L3 transmission network (such as Figure 1 One or more service provider networks 150) and one or more network devices (such as Figure 1 The network device 110) exchanges PIM messages.

[0106] As an example, the computing device 200 is Figure 1 The routing component 250 learns the address of the virtual circuit interface of the network device 110B associated with the PIM service for multicast services between the computing devices 200 and 110B via a routing protocol such as BGP, and stores such information in the PIM multicast information 262. The routing component 250 learns the address of the virtual circuit interface of the network device 110B associated with the PIM service for multicast services between the computing devices 200 and 110B via a routing protocol such as BGP, and stores such information in the PIM multicast information 262. Figure 1The multicast sender device 100A receives a multicast packet for a multicast group associated with a multicast service. The routing component 250 generates a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet carrying a PIM registration request that is addressed to the RP device and is configured to register the computing device 200 as a multicast source of the multicast group. The header of the unicast L3 packet specifies a source address that is a network address translation (NAT) of an address of a virtual circuit interface of the network device 110B. In some examples, the routing component 250 performs NAT of an address of the multicast sender device to an address of the virtual circuit interface of the network device 110B. In some examples, the routing component 250 performs NAT of an address of the computing device 200 to an address of the virtual circuit interface of the network device 110B. The routing component 250 forwards the unicast L3 packet to the network device 110B across the L3 transport network 150A.

[0107] As another example, computing device 200 may be used as Figure 1 The routing component 250 defines a PIM service between the network device 110A and the computing device 200. The routing component 250 establishes a virtual circuit interface 260 and stores information of the PIM service in the service information 232, the information of the PIM service including an association between the PIM service and the address of the virtual circuit interface 260. In some examples, the address of the virtual circuit interface 260 is used as a service identifier of the PIM service for multicast services between the network device 110A and the computing device 200.

[0108] Routing component 250 receives a unicast L3 packet from network device 110A via L3 transport network 150A. The unicast L3 packet includes a header that specifies a source address of an address of virtual circuit interface 260. Routing component 250 determines that a PIM registration request from network device 110A is associated with a multicast group associated with a multicast service based at least in part on a stored association between the PIM service and the address of virtual circuit interface 260. Routing component 250 registers network device 110A as a multicast source for the multicast group associated with the multicast service and stores the registration of network device 110A within PIM multicast information 262.

[0109] Figure 3A is a block diagram illustrating an example computer network system 300A that is not configured according to the techniques of the present disclosure. More specifically, Figure 3AA system 300A is depicted that uses GRE tunnels to implement multicast packet distribution. System 300A includes an MPLS core 310, provider edge (PE) routers 312A-312B (collectively, "PE routers 312"), customer edge (CE) routers 314A-314B (collectively, "CE routers 314"), routers 316A-316B (collectively, "routers 316"), satellite network 318, router 320, and router 322. In some examples, PE router 312 is an MX router provided by Juniper Networks, Inc. that provides PE functionality. In some examples, CE router 314 is an MX router provided by Juniper Networks, Inc. that provides CE functionality. PE router 312 and CE router 314 can communicate using PIM-RP and Multicast Source Discovery Protocol (MSDP).

[0110] Satellite network 318 operates as an intermediate access or transport network between router 316 and router 320. Router 316 and router 320 may communicate via PIM-SM over GRE. Router 320 may operate as a gateway or access point for router 322 into satellite network 318. Router 322 may be an SRX router provided by Juniper Networks.

[0111] With a system configured with the techniques of the present disclosure (such as Figure 3B (discussed in more detail below), computer network system 300A may not implement a PIM architecture for multiple multicast services. This is because router 316 may not be able to identify which multicast service or which multicast sender the PIM message is intended for when it receives the PIM message via the GRE tunnel. Such a conventional PIM message may not include any information that router 316 can use to identify the multicast service from other multicast services, thereby preventing the implementation of PIM within the L3 transport network.

[0112] Figure 3B is a block diagram illustrating an example computer network system 300B according to the techniques of the present disclosure. More specifically, Figure 3B Depicted is a system 300B that implements multicast packet distribution using PIM over a session-routing based network. Figure 3BIt includes an MPLS core 310, provider routers 352A to 352B (collectively referred to as "P routers 352"), PE routers 354A to 354C (collectively referred to as "PE routers 354"), data centers 356A to 356B (collectively referred to as "data centers 356"), the data centers include routers 362A to 362C (collectively referred to as "routers 362"), routers 358A to 358F (collectively referred to as "routers 358"), satellite networks 364A to 364B (collectively referred to as "satellite networks 364"), branch routers 360A to 360C (collectively referred to as "branch routers 360") and servers 366A to 366C (collectively referred to as "servers 366").

[0113] Data center 356A includes routers 362A and 362B that communicate with PE routers 354A and 354B via BGP and PIM-SM. PE router 354 may be an MX router provided by Juniper Networks, Inc. Routers 360 and 362 may be session-smart routers provided by Juniper Networks, Inc. that are capable of performing session-based routing.

[0114] Satellite network 364A operates as an intermediate access or transport network between routers 358A, 358B and routers 358C, 358D. Routers 358A, 358B and routers 358C, 358D may communicate via BGP and Service Topology Exchange Protocol (STEP). Routers 358C, 358D operate as gateways or access points for routers 360A, 360B, respectively, into satellite network 364A. Router 360A operates as a gateway device to provide layer 3 access to server 366A via IGMPv2. Router 360B operates as a gateway device to provide layer 3 access to server 366B via IGMPv2. Server 366 is an example of an end-point user or client device.

[0115] Data center 356B includes router 362C in communication with PE router 354C and router 358E. Satellite network 364B operates as an intermediate access or transport network between router 358E and router 358F. Router 358F operates as a gateway or access point for router 360C into satellite network 364B. Router 360C operates as a gateway device to provide layer 3 access to server 366C via IGMPv2. Figure 3B In the example, server 366B is the multicast source device, and servers 366A, 366C are multicast receiver devices.

[0116] According to the technology of the present disclosure, PIM is suitable for operating in a network based on session routing. More specifically, Figure 3BAs depicted in the example of , session-based routing routers 358 , 362 provide a BGP connection through an SVR to interconnect two remote PIM peers (eg, routers 360A and 360C).

[0117] For example, a first branch router 360A connected to a multicast receiver device (server 366A) receives an IGMP multicast group join request from the multicast receiver device 366A. The first branch router 360A may generate a PIM join request and send the PIM join request to the RP (PE router 354B) via session-based routing. In some examples, the first branch router 360A forms a unicast L3 packet including a source address of the first branch router 360A, a destination address of a hub router (e.g., router 362B), metadata specifying a session identifier for a multicast service associated with the multicast group, and a payload including the PIM join request. The hub router 362B may receive the L3 packet and forward the PIM join request encapsulated by the unicast L3 packet to the RP (e.g., PE router 354B), which may be outside the network (or outside the data center 356A). The first branch router 360A may store multicast state information specifying the multicast receiver device 366A as a member of the multicast group. The hub router 362B may store multicast information specifying a multicast route to the first spoke router 360A for the multicast group.

[0118] As another example, a second branch router 360B connected to a multicast source device (e.g., server 366B) receives a multicast packet for a multicast group from the multicast source device (e.g., server 366B). The second branch router 360B can generate a PIM registration message including the multicast packet and send the PIM registration message to an RP (e.g., PE router 354B) via session-based routing. In some examples, the second branch router 360B forms a unicast L3 packet including a source address of the second branch router 360B, a destination address of the hub router 362B, metadata specifying a session identifier for a multicast service associated with the multicast group, and a payload including a PIM registration request. The hub router 362B can receive the L3 packet and forward the PIM registration request encapsulated by the unicast L3 packet to the RP, which can be outside the network (e.g., or data center 356A). The second branch router 360B can store multicast state information specifying the multicast source device 366B as a sender of the multicast group. Additionally, for subsequent multicast packets, the second branch router 360B may omit metadata from the L3 packet encapsulating the corresponding multicast packet.

[0119] The hub router 362B may store multicast information specifying a multicast route from the second spoke router 360B to the first spoke router 360A for the multicast group. In addition, the hub router may generate a PIM pruning message to remove the RP (e.g., PE router 354B) from the multicast tree so that subsequent multicast traffic is sent from the second router 360B to the hub 362B and then directly to the first router 360A, thereby bypassing the RP (e.g., PE router 354B).

[0120] In one example, the first network device 360A is configured to: receive a multicast join request for a multicast group associated with a multicast service from a multicast receiver device 366A; and send a unicast L3 packet to a second network device (e.g., such as a hub device 362B) based on the received multicast join request, the unicast L3 packet comprising: a header comprising: (1) source address information, the source address information specifying address information of the first network device 360A, and (2) destination address information, the destination address information specifying address information of the second network device 362B; metadata specifying a session identifier for the multicast service; and a payload comprising a PIM join request that is directed to an RP device (e.g., PE router 354B) and is configured to subscribe the first network device 360A to the multicast group.

[0121] In some examples, the first network device is further configured to: receive a second unicast L3 packet from a second network device, the second unicast L3 packet comprising: a second header comprising (1) second source address information, the second source address information specifying address information of the second network device, and (2) second destination address information, the second destination address information specifying address information of the first network device; second metadata specifying a session identifier for a multicast service; and a second payload comprising a multicast packet for a multicast group; and forward the multicast packet to a multicast recipient device.

[0122] In some examples, the first network device is further configured to store multicast state information that specifies the multicast recipient as a member of the multicast group based on the received multicast join request. In some examples, the session identifier for the multicast service includes at least a source address that is an address of the multicast recipient device and a source port that is a port of the multicast recipient device. In some examples, the source address information of the header includes: a source address that is an address of the first network system; a source port that is a port of the first network system, and the destination address information of the header includes: a destination address that is an address of the second network device; and a destination port that is a port of the second network device.

[0123] In some examples, the first network device is further configured to determine a session identifier for the multicast service based at least in part on a source address and a source port specified by the multicast join request, the source address specifying an address of the multicast recipient device and the source port specifying a port of the multicast recipient device.

[0124] In another example, a first network device is configured to: receive a multicast packet for a multicast group associated with a multicast service from a multicast source device; and send a unicast L3 packet to a second network device based on the received multicast packet, the unicast L3 packet comprising: a header comprising: (1) source address information, the source address information specifying address information of the first network device, and (2) destination address information specifying address information of the second network device; metadata specifying a session identifier for the multicast service; and a payload comprising a PIM registration request that is addressed to an RP device and is configured to register the first network device as a multicast source for the multicast group.

[0125] In some examples, the first network device is further configured to store multicast state information designating the multicast source device as a multicast source for the multicast service based on the received multicast packet.

[0126] In another example, a hub network device is configured to: receive a first unicast L3 packet from a first branch network device, the first unicast L3 packet comprising: a first header including (1) first source address information, the first source address information specifying address information of the first branch network device, and (2) first destination address information specifying address information of the hub network device; first metadata specifying a session identifier for a multicast service; and a first payload including a PIM registration request to an RP device, the registration request being configured to register the first branch network device as a multicast source of a multicast group associated with the multicast service; and receive a second unicast L3 packet from a second branch network device, the second unicast L3 packet comprising : a second header comprising (1) second source address information, the second source address information specifying address information of a second branch network device, and (2) second destination address information specifying address information of a hub network device; second metadata specifying a session identifier for a multicast service; and a second payload comprising a PIM join request that is directed to an RP device and is configured to subscribe the first branch network device to the multicast packet; and storing a multicast route based at least in part on the first unicast L3 packet and the second unicast L3 packet, the multicast route specifying the first branch network device as being associated with a multicast source device of a multicast group, and specifying the second branch network device as being associated with a multicast receiver device of the multicast group.

[0127] In some examples, the hub network device is further configured to: send a third unicast L3 packet to the first branch network device, the third unicast L3 packet comprising: a third header comprising (1) third source address information, the third source address information specifying the address information of the hub network device, and (2) third destination address information specifying the address information of the first branch network device; and a third payload comprising a PIM join request addressed to the first branch network device and configured to cause the hub network device to subscribe to the multicast group; send a fourth unicast L3 packet to the first branch network device, the unicast L3 packet comprising: a third header comprising (1) third source address information, the third source address information specifying the address information of the hub network device, and (2) third destination address information specifying the address information of the first branch network device; fourth metadata specifying a session identifier for the multicast service; and a payload comprising a PIM pruning request to remove the RP device from the multicast group.

[0128] One goal of the disclosed technology is to support full-fledged Any-Source Multicast (ASM) multicast (PIM / IGMP), except that the first version does not require RP functionality and Multicast Source Discovery Protocol (MSDP). The current FRR routing stack includes PIM Sparse Mode (SM) and IGMP v2 and v3 support. Support is provided to leverage FRR PIM / IGMP functionality through a data model based on session routing.

[0129] like FIG. 3A to FIG. 3B As depicted in , multicast is migrated and session-based routing routers are introduced. Typically, customers have GRE tunnels through satellite networks. The updated network removes the GRE tunnels and introduces session-based routing routers. One goal is to remove all GRE tunnels and do session-based routing between session-based routing routers. There can be multiple data centers connected in this way.

[0130] Customers may require IGMPv2 and PIM-ASM. Session-based routing routers may not be (at least initially) RPs and may not be used for MSDP source discovery. Multicast sources and receivers connect to branch session-based routing routers. There may also be sources that are located somewhere behind session-based routing routers in the data center but not directly connected to them.

[0131] The following sections step through the basic sequence of protocol events. PIM is a complex protocol with many edge cases, so this is not meant to be a complete tutorial. It simply walks through some common cases, especially with expected customer deployments.

[0132] Source and receiver on different branch 128T routers

[0133] Receiver on branch 1 joins. The receiver sends an IGMP membership report to the branch 1 128T router to join a specific group. The router creates a (*, G) forwarding state and then sends a PIM (*, G) join upstream to the RP. This join is sent to the hub 128T router. The hub creates a (*, G) mroute state. It also sends a (*, G) upstream to the RP. Once the RP receives the join, it creates a (*, G) mroute state.

[0134] The source on branch 2 begins sending. Then, the source connected to branch 2 begins sending traffic. The branch 2 128T router creates an (S, G) mroute and unicasts PIM registration control messages directly to the RP. These PIM registration messages can include data packets. The RP receives the PIM registration and then sends a PIM (S, G) join to the source address. The RP forwards the included data packets down the shared tree. The hub receives this PIM join and creates the (S, G) mroute state. Note that it is still forwarding traffic based on the (*, G) shared tree entry until it determines that the traffic has arrived at the shortest path tree. The hub sends a PIM join to the source address. The branch 2 router receives the (S, G) join and adds the wan interface (the interface that received the join) to the outgoing interface list of the (S, G) mroute entry. Traffic now flows from the source to the hub. The hub detects that traffic has arrived from the source and updates its forwarding to forward using the (S, G) mroute. The hub sends the traffic to both the RP and the branch 1 receiver. The RP detects that traffic is coming in natively and unicasts a PIM Register-Stop directly to the first hop router (branch 2). The hub detects that traffic from this source no longer needs to be received from the RP. The hub sends a (S, G) RPT Prune to the RP. The RP no longer needs to send a (S, G) Join to the source because the shortest path tree is already fully established. Now, multicast traffic flows from branch 2 to the hub and then to branch 1. Branch 1 detects this single source address because it is the last hop router. It sends a PIM (S, G) Join to the source. The (S, G) Join is received by the hub. This (S, G) Join does not have much of an impact in this particular case as far as forwarding is concerned. The shortest path tree for this (S, G) is already established on the hub.

[0135] Source and receiver behind RP on branch 128T router

[0136] A receiver on a spoke router joins a group. The receiver sends an IGMP membership report to the spoke 128T router to join a specific group. The router creates a (*, G) forwarding state and then sends a PIM (*, G) join upstream to the RP. This join is sent to the hub 128T router. The hub creates a (*, G) mroute state. It also sends a (*, G) upstream to the RP. Once the RP receives the join, it creates a (*, G) mroute state.

[0137] The source behind the RP starts sending traffic. Once the traffic starts flowing, the RP starts sending traffic to the hub. The hub forwards the traffic to the spoke according to the mroute. The spoke forwards the traffic according to the (*,G) mroute. The spoke detects the (S,G) and creates the (S,G) state. The (S,G) mroute can be programmed immediately because the input interface towards the source and the RP is the same interface. The source sends a PIM (S,G) join to the source. The hub receives the PIM (S,G) join and creates the (S,G) mroute state. The hub sends a PIM join to the RP. The shortest path tree to the source is then established through the RP.

[0138] Source on the branch. Receiver is both on the branch 128T router and behind the RP.

[0139] The source on branch 1 starts first. The source starts sending traffic to the branch 1 router. The branch 1 router creates the (S, G) mroute state. It unicasts a PIM registration Register to the RP. The RP creates the (S, G) state as a result of the registration, but it does not have any receivers, so it unicasts a PIM registration Stop to branch 1. Branch 1 stops sending PIM registrations to the RP.

[0140] The receiver behind the RP then joins. The receiver behind the RP then joins the group. The RP receives the PIM (*, G) join. The RP already has the (S, G) state, so it adds the outgoing interface to this mroute. It sends a PIM (S, G) join to the source. The hub receives the PIM (S, G) join and creates the (S, G) mroute state. The hub sends a PIM (S, G) join to the source. Spoke 1 receives the PIM (S, G) join. It already has the (S, G) mroute state, so it adds the outgoing interface to the outgoing interface list. It now starts forwarding this traffic to the hub. Traffic flows to the receiver behind the RP.

[0141] Then the receiver on branch 2 joins. Another receiver on branch 2 joins the multicast group by sending an IGMP membership report. Branch 2 creates a (*, G) mroute state. It sends a (*, G) PIM join to the RP. The hub receives the (*, G) join, and it creates a (*, G) mroute state. It also adds this interface to the outgoing interfaces of the (S, G) mroute. The hub sends a (*, G) join to the RP. Traffic flows from branch 1 to the hub, and then to branch 2. Branch 2 creates a (S, G) mroute state. Then, branch 2 sends a PIM (S, G) join to the source.

[0142] Service configuration for multicast

[0143] A service must be created for multicast traffic. A service must be defined for a given group address. A multicast sender policy must be created to allow the source to send for the multicast group. There must be a tenant to forward the source's traffic. Additionally, there must be an access policy to allow the receiver on the outgoing interface.

[0144] Below is an example configuration that allows traffic to 225.1.1.1 to reach the red tenant. Receivers on the food tenant can join this group.

[0145] serviceiptv-service

[0146] nameiptv-service

[0147] address225.1.1.1 / 32

[0148] access-policy food

[0149] source food

[0150] exit

[0151] multicast-sender-policy red source red

[0152] exit

[0153] exit

[0154] The multicast service configuration is extended to allow non-host prefixes. When matching an mroute to a multicast service, the longest prefix match is used.

[0155] Also, note that unicast control messages (Register and Register-Stop) are sent between the first-hop router and the RP. Once the RP is configured, services are automatically generated for the RP address. The user should not configure services for this RP address because services are automatically generated.

[0156] Multicast protocol configuration

[0157] Support has been added to enable multicast protocol configuration on network interfaces. There is a global PIM command to set the multicast group-wide RP address.

[0158] PIM can be configured in the configuration hierarchy as:

[0159] authority router <> routing default-instance {vrf <>} pim

[0160] Here, RP can be configured as

[0161] rp <group-addr mask>address <rp-address>

[0162] The group range of the RP is the first parameter. If the RP should be configured for all groups, 224 / 4 can be set as group / mask. The RP address can be a local address, in which case this router acts as the RP for the given group range (but this is not supported in the first version)

[0163] The configuration of PIM on an interface is similar to the configuration of OSPF on an interface:

[0164] Interface <node> <network-interface>

[0165] IGMP is similar and can be configured in the configuration hierarchy as:

[0166] authority router <> routing default-instance {vrf <>} igmp

[0167] IGMP is similar to PIM and is configured on an interface.

[0168] Interface <node> <network-interface>

[0169] Multicast is supported in the 128T data model as follows:

[0170] authority

[0171] router A

[0172] routing default-instance

[0173] pim

[0174] rp 10.10.10.2 224.0.0.0 / 4

[0175] interface T217_DUT2 inet30

[0176] node T217_DUT2

[0177] interface inet30

[0178] igmp

[0179] interface T217_DUT2 inet30

[0180] node T217_DUT2

[0181] interface inet30

[0182] version 2

[0183] This can also be enabled in vrf:

[0184] authority

[0185] router A

[0186] routing default-instance

[0187] vrf vrf

[0188] pim

[0189] rp 20.20.20.2 224.0.0.0 / 4

[0190] interface T217_DUT2 inet40

[0191] node T217_DUT2

[0192] interface inet40

[0193] igmp

[0194] interface T217_DUT2 inet40

[0195] node T217_DUT2

[0196] interface inet40

[0197] SVR Multicast Configuration

[0198] Multicast over SVR does not need to be explicitly configured. If BGPoSVR is configured on the session-based routing routers and PIM RP configuration exists on both BGP routers, then the SVR multicast configuration is automatically generated. Therefore, BGPoSVR is a prerequisite for multicast over SVR. PIM is not typically configured on the WAN interface. This multicast configuration is automatically generated.

[0199] The show commands available in FRR are provided through session-based routing PCLI. A REST endpoint with JSON output is provided so that even if the GUI is not modified, the GUI will display the JSON output via the REST endpoint.

[0200] Show Command

[0201] Below are examples of supported commands. This list is not exhaustive, and commands may be removed or added. Also included below are examples of output for each command in FRR. Session-based routing routers can get JSON output from FRR and can display it in different formats. The session-based routing "verbose" version of the command shows the full JSON output.

[0202] Note that each show command allows the vrf option:

[0203] show ip igmp [vrf <vrfname>] …

[0204] show ip pim [vrf <vrfname>] …

[0205] For brevity, the "vrf" option is removed from the following commands. The tabular output shown for the following commands has sample output for the FRR display. The tabular output on the 128T PCLI (brief verbosity for each command) may be different. The detailed display for session-based routing shows the full JSON output.

[0206] show igmp interface

[0207] t231-dut4.openstacklocal# show ip igmp int

[0208] Interface status address V Querier query timer running time

[0209] g10 mtrc 11.1.10.4 3 Others--:--:-- 00:11:38

[0210] g60 up 11.1.60.4 3 local 00:00:22 00:00:09

[0211] t231-dut4.openstacklocal# show ip igmp int json

[0212] {

[0213] "g10":{

[0214] "name":"g10",

[0215] "state":"up",

[0216] "address":"11.1.10.4",

[0217] "index":6,

[0218] "flagMulticast":true,

[0219] "flagBroadcast":true,

[0220] "lanDelayEnabled":true,

[0221] "upTime":"00:14:21",

[0222] "version":3,

[0223] "mtraceOnly":true

[0224] },

[0225] "g60":{

[0226] "name":"g60",

[0227] "state":"up",

[0228] "address":"11.1.60.4",

[0229] "index":8,

[0230] "flagMulticast":true,

[0231] "flagBroadcast":true,

[0232] "lanDelayEnabled":true,

[0233] "upTime":"00:02:52",

[0234] "version":3,

[0235] "querier":true,

[0236] "queryTimer":"00:01:49"

[0237] }

[0238] }

[0239] Note that in the output above, if the interface has PIM enabled but not IGMP enabled, the interface will be shown as "State: mtrc". If the interface has IGMP enabled, it will be shown as "State: up".

[0240] show igmp group

[0241] t231-dut5.openstacklocal# show ip igmp groups

[0242] Total IGMP groups: 4

[0243] Watermark warning limit (not set): 0

[0244] Interface Address Group Mode Timer Source V Run Time

[0245] g60 11.1.60.5 239.0.1.7 EXCL 00:03:01 1 3 149:54:31

[0246] g60 11.1.60.5 239.0.1.5 EXCL 00:03:01 1 3 149:54:31

[0247] loopback 10.5.0.1 239.0.1.1 EXCL 00:03:09 1 3 221:40:01

[0248] loopback 10.5.0.1 239.0.1.5 EXCL 00:03:09 1 3 221:39:58

[0249] t231-dut5.openstacklocal# show ip igmp groups json

[0250] {

[0251] "totalGroups":4,

[0252] "watermarkLimit":0,

[0253] "g60":{

[0254] "name":"g60",

[0255] "state":"up",

[0256] "address":"11.1.60.5",

[0257] "index":10,

[0258] "flagMulticast":true,

[0259] "flagBroadcast":true,

[0260] "lanDelayEnabled":true,

[0261] "groups":[

[0262] {

[0263] "source":"11.1.60.5",

[0264] "group":"239.0.1.7",

[0265] "mode":"EXCLUDE",

[0266] "timer":"00:02:55",

[0267] "sourcesCount":1,

[0268] "version":3,

[0269] "uptime":"149:54:37"

[0270] },

[0271] {

[0272] "source":"11.1.60.5",

[0273] "group":"239.0.1.5",

[0274] "mode":"EXCLUDE",

[0275] "timer":"00:02:55",

[0276] "sourcesCount":1,

[0277] "version":3,

[0278] "uptime":"149:54:37"

[0279] } ]

[0281] },

[0282] "loopback":{

[0283] "name":"loopback",

[0284] "state":"up",

[0285] "address":"10.5.0.1",

[0286] "index":12,

[0287] "flagMulticast":true,

[0288] "lanDelayEnabled":true,

[0289] "groups":[

[0290] {

[0291] "source":"10.5.0.1",

[0292] "group":"239.0.1.1",

[0293] "mode":"EXCLUDE",

[0294] "timer":"00:03:03",

[0295] "sourcesCount":1,

[0296] "version":3,

[0297] "uptime":"221:40:07"

[0298] },

[0299] {

[0300] "source":"10.5.0.1",

[0301] "group":"239.0.1.5",

[0302] "mode":"EXCLUDE",

[0303] "timer":"00:03:03",

[0304] "sourcesCount":1,

[0305] "version":3,

[0306] "uptime":"221:40:04"

[0307] } ]

[0309] }

[0310] }

[0311] show pim mroute [ABCD[ABCD]]

[0312] t231-dut5.openstacklocal# show ip mroute

[0313] IP Multicast Routing Table

[0314] Flags: S - sparse, C - join, P - prune

[0315] R-RP bit set, F-registration flag, T-SPT bit set

[0316] Source Group Flag Prototype Input Output TTL Run Time

[0317] * 239.0.1.1 SC IGMP g60 pimreg 1

[0318] 11.1.30.3 239.0.1.4 SFT PIM g30 g60 1

[0319] * 239.0.1.5 SC IGMP g60 pimreg 1

[0320] t231-dut5.openstacklocal# show ip mroute json

[0321] {

[0322] "239.0.1.1":{

[0323] "*":{

[0324] "installed":1,

[0325] "refCount":2,

[0326] "oilSize":2,

[0327] "OilInheritedRescan":0,

[0328] "iif":"g60",

[0329] "upTime":"00:23:43",

[0330] "flags":"SC",

[0331] "oil":{

[0332] "pimreg":{

[0333] "source":"*",

[0334] "group":"239.0.1.1",

[0335] "protocolIgmp":true,

[0336] "inboundInterface":"g60",

[0337] "iVifI":2,

[0338] "outboundInterface":"pimreg",

[0339] "oVifI":0,

[0340] "ttl":1,

[0341] "upTime":"00:23:43"

[0342] },

[0343] "loopback":{

[0344] "source":"*",

[0345] "group":"239.0.1.1",

[0346] "protocolPim":true,

[0347] "protocolIgmp":true,

[0348] "inboundInterface":"g60",

[0349] "iVifI":2,

[0350] "outboundInterface":"loopback",

[0351] "oVifI":3,

[0352] "ttl":1,

[0353] "upTime":"00:23:43"

[0354] }

[0355] }

[0356] }

[0357] },

[0358] "239.0.1.4":{

[0359] "11.1.30.3":{

[0360] "installed":1,

[0361] "refCount":1,

[0362] "oilSize":1,

[0363] "OilInheritedRescan":0,

[0364] "iif":"g30",

[0365] "upTime":"00:04:15",

[0366] "flags":"ST",

[0367] "oil":{

[0368] "g60":{

[0369] "source":"11.1.30.3",

[0370] "group":"239.0.1.4",

[0371] "protocolPim":true,

[0372] "inboundInterface":"g30",

[0373] "iVifI":1,

[0374] "outboundInterface":"g60",

[0375] "oVifI":2,

[0376] "ttl":1,

[0377] "upTime":"00:04:15"

[0378] }

[0379] }

[0380] }

[0381] },

[0382] "239.0.1.5":{

[0383] "*":{

[0384] "installed":1,

[0385] "refCount":2,

[0386] "oilSize":2,

[0387] "OilInheritedRescan":0,

[0388] "iif":"g60",

[0389] "upTime":"00:23:43",

[0390] "flags":"SC",

[0391] "oil":{

[0392] "pimreg":{

[0393] "source":"*",

[0394] "group":"239.0.1.5",

[0395] "protocolIgmp":true,

[0396] "inboundInterface":"g60",

[0397] "iVifI":2,

[0398] "outboundInterface":"pimreg",

[0399] "oVifI":0,

[0400] "ttl":1,

[0401] "upTime":"00:23:43"

[0402] },

[0403] "loopback":{

[0404] "source":"*",

[0405] "group":"239.0.1.5",

[0406] "protocolPim":true,

[0407] "protocolIgmp":true,

[0408] "inboundInterface":"g60",

[0409] "iVifI":2,

[0410] "outboundInterface":"loopback",

[0411] "oVifI":3,

[0412] "ttl":1,

[0413] "upTime":"00:23:43"

[0414] }

[0415] }

[0416] }

[0417] }

[0418] }

[0419] Display pim interface

[0420] t231-dut4.openstacklocal# show ip pim int

[0421] Interface status address PIM Nbrs PIM DR FHR Channel

[0422] g10 up 11.1.10.4 1 local0 0

[0423] g60 up 11.1.60.4 1 11.1.60.5 0 0

[0424] pimreg up 0.0.0.0 0 local0 0

[0425] t231-dut4.openstacklocal# show ip pim int json

[0426] {

[0427] "g10":{

[0428] "name":"g10",

[0429] "state":"up",

[0430] "address":"11.1.10.4",

[0431] "index":6,

[0432] "flagMulticast":true,

[0433] "flagBroadcast":true,

[0434] "lanDelayEnabled":true,

[0435] "pimNeighbors":1,

[0436] "pimIfChannels":0,

[0437] "firstHopRouterCount":0,

[0438] "pimDesignatedRouter":"11.1.10.4",

[0439] "pimDesignatedRouterLocal":true

[0440] },

[0441] "g60":{

[0442] "name":"g60",

[0443] "state":"up",

[0444] "address":"11.1.60.4",

[0445] s"index":8,

[0446] "flagMulticast":true,

[0447] "flagBroadcast":true,

[0448] "lanDelayEnabled":true,

[0449] "pimNeighbors":1,

[0450] "pimIfChannels":0,

[0451] "firstHopRouterCount":0,

[0452] "pimDesignatedRouter":"11.1.60.5"

[0453] },

[0454] "pimreg":{

[0455] "name":"pimreg",

[0456] "state":"up",

[0457] "address":"0.0.0.0",

[0458] "index":12,

[0459] "lanDelayEnabled":true,

[0460] "pimNeighbors":0,

[0461] "pimIfChannels":0,

[0462] "firstHopRouterCount":0,

[0463] "pimDesignatedRouter":"0.0.0.0",

[0464] "pimDesignatedRouterLocal":true

[0465] }

[0466] }

[0467] t231-dut4.openstacklocal# show ip pim join

[0468] Interface address source group status running time expiration pruning

[0469] g4 10.4.1.1 * 239.0.1.1 NOINFO --:--:-- --:-- --:--

[0470] g60 11.1.60.4 * 239.0.1.1 JOIN 03:37:09 02:59 --:--

[0471] g60 11.1.60.4 * 239.0.1.3 JOIN 00:04:10 02:59 --:--

[0472] g60 11.1.60.4 * 239.0.1.5 JOIN 03:37:06 02:59 --:--

[0473] loopback 10.4.0.1 * 239.0.1.4 NOINFO --:--:-- --:-- --:--

[0474] t231-dut4.openstacklocal# show ip pim join json

[0475] {

[0476] "g4":{

[0477] "name":"g4",

[0478] "state":"up",

[0479] "address":"10.4.1.1",

[0480] "index":5,

[0481] "flagMulticast":true,

[0482] "flagBroadcast":true,

[0483] "lanDelayEnabled":true,

[0484] "239.0.1.1":{

[0485] "*":{

[0486] "source":"*",

[0487] "group":"239.0.1.1",

[0488] "upTime":"--:--:--",

[0489] "expire":"--:--",

[0490] "prune":"--:--",

[0491] "channelJoinName":"NOINFO",

[0492] "protocolIgmp":1

[0493] }

[0494] }

[0495] },

[0496] "g60":{

[0497] "name":"g60",

[0498] "state":"up",

[0499] "address":"11.1.60.4",

[0500] "index":8,

[0501] "flagMulticast":true,

[0502] "flagBroadcast":true,

[0503] "lanDelayEnabled":true,

[0504] "239.0.1.1":{

[0505] "*":{

[0506] "source":"*",

[0507] "group":"239.0.1.1",

[0508] "upTime":"03:37:35",

[0509] "expire":"02:32",

[0510] "prune":"--:--",

[0511] "channelJoinName":"JOIN",

[0512] "protocolPim":1

[0513] }

[0514] },

[0515] "239.0.1.3":{

[0516] "*":{

[0517] "source":"*",

[0518] "group":"239.0.1.3",

[0519] "upTime":"00:04:36",

[0520] "expire":"02:32",

[0521] "prune":"--:--",

[0522] "channelJoinName":"JOIN",

[0523] "protocolPim":1

[0524] }

[0525] },

[0526] "239.0.1.5":{

[0527] "*":{

[0528] "source":"*",

[0529] "group":"239.0.1.5",

[0530] "upTime":"03:37:32",

[0531] "expire":"02:32",

[0532] "prune":"--:--",

[0533] "channelJoinName":"JOIN",

[0534] "protocolPim":1

[0535] }

[0536] }

[0537] },

[0538] "loopback":{

[0539] "name":"loopback",

[0540] "state":"up",

[0541] "address":"10.4.0.1",

[0542] "index":10,

[0543] "flagMulticast":true,

[0544] "lanDelayEnabled":true,

[0545] "239.0.1.4":{

[0546] "*":{

[0547] "source":"*",

[0548] "group":"239.0.1.4",

[0549] "upTime":"--:--:--",

[0550] "expire":"--:--",

[0551] "prune":"--:--",

[0552] "channelJoinName":"NOINFO",

[0553] "protocolIgmp":1

[0554] }

[0555] }

[0556] }

[0557] }

[0558] show pim neighbors

[0559] t231-dut4.openstacklocal# show ip pim nei

[0560] Interface Neighbor Uptime Waiting Time DR Priority

[0561] g10 11.1.10.2 00:28:50 00:01:25 1

[0562] g60 11.1.60.5 00:28:04 00:01:41 1

[0563] t231-dut4.openstacklocal# show ip pim nei json

[0564] {

[0565] "g10":{

[0566] "11.1.10.2":{

[0567] "interface":"g10",

[0568] "neighbor":"11.1.10.2",

[0569] "upTime":"00:28:53",

[0570] "holdTime":"00:01:22",

[0571] "holdTimeMax":105,

[0572] "drPriority":1

[0573] }

[0574] },

[0575] "g60":{

[0576] "11.1.60.5":{

[0577] "interface":"g60",

[0578] "neighbor":"11.1.60.5",

[0579] "upTime":"00:28:07",

[0580] "holdTime":"00:01:38",

[0581] "holdTimeMax":105,

[0582] "drPriority":1

[0583] }

[0584] }

[0585] }

[0586] Display pim rp information

[0587] t231-dut2.openstacklocal# show ip pim rp-info

[0588] RP Address Group / Prefix List OIF I am RP Source

[0589] 11.1.10.2 224.0.0.0 / 4 g10 is static

[0590] 11.1.60.4 225.0.0.0 / 16 g10 No Static

[0591] 11.1.30.5 226.0.0.0 / 25g10 No Static

[0592] t231-dut2.openstacklocal# show ip pim rp-info json

[0593] {

[0594] "11.1.10.2":[

[0595] {

[0596] "rpAddress":"11.1.10.2",

[0597] "outboundInterface":"g10",

[0598] "iAmRP": true,

[0599] "group": "224.0.0.0 / 4",

[0600] "source": "Static"

[0601] }

[0602] ,

[0603] "11.1.60.4":

[0604] {

[0605] "rpAddress": "11.1.60.4",

[0606] "outboundInterface": "g10",

[0607] "iAmRP": false,

[0608] "group": "225.0.0.0 / 16",

[0609] "source": "Static"

[0610] }

[0611] ,

[0612] "11.1.30.5":

[0613] {

[0614] "rpAddress": "11.1.30.5",

[0615] "outboundInterface": "g10",

[0616] "iAmRP": false,

[0617] "group": "226.0.0.0 / 25",

[0618] "source": "Static"

[0619] }

[0621] }

[0622] Display PIM status

[0623] t231-dut2.openstacklocal# show ip pim state​

[0624] Details:J->Pim Join,I->IGMP Report,S->Source,*->Inherited from(*,G),V ->VxLAN,M->Muted

[0625] Equipment Replacement RPT IIF OIL

[0626] 1 * 239.0.1.1 y g10 pimreg(I ), loopback(I )

[0627] 1*239.0.1.3 and g10 g10(J)

[0628] 1 * 239.0.1.4 y g10 g10(J)

[0629] 1 * 239.0.1.5 y g10 g10(J)

[0630] t231-dut2.openstacklocal# show ip pim state json

[0631] {

[0632] "239.0.1.1":{

[0633] "*":{

[0634] "g10":{

[0635] "pimreg":{

[0636] "source":"*",

[0637] "group":"239.0.1.1"

[0638] "inboundInterface":"g10".

[0639] "outboundInterface":"pimreg".

[0640] "installed":1

[0641] },

[0642] "loopback":{

[0643] "source":"*",

[0644] "group":"239.0.1.1",

[0645] "inboundInterface":"g10",

[0646] "outboundInterface":"loopback",

[0647] "installed":1

[0648] }

[0649] },

[0650] "Installed":1,

[0651] "isRpt":true,

[0652] "RefCount":2,

[0653] "OilListSize":2,

[0654] "OilRescan":1,

[0655] "LastUsed":0,

[0656] "PacketCount":0,

[0657] "ByteCount":0,

[0658] "WrongInterface":0

[0659] }

[0660] },

[0661] "239.0.1.3":{

[0662] "*":{

[0663] "g10":{

[0664] "g10":{

[0665] "source":"*",

[0666] "group":"239.0.1.3",

[0667] "inboundInterface":"g10",

[0668] "outboundInterface":"g10",

[0669] "installed":1

[0670] }

[0671] },

[0672] "Installed":1,

[0673] "isRpt":true,

[0674] "RefCount":1,

[0675] "OilListSize":1,

[0676] "OilRescan":1,

[0677] "LastUsed":0,

[0678] "PacketCount":0,

[0679] "ByteCount":0,

[0680] "WrongInterface":0

[0681] }

[0682] },

[0683] "239.0.1.4":{

[0684] "*":{

[0685] "g10":{

[0686] "g10":{

[0687] "source":"*",

[0688] "group":"239.0.1.4",

[0689] "inboundInterface":"g10",

[0690] "outboundInterface":"g10",

[0691] "installed":1

[0692] }

[0693] },

[0694] "Installed":1,

[0695] "isRpt":true,

[0696] "RefCount":1,

[0697] "OilListSize":1,

[0698] "OilRescan":1,

[0699] "LastUsed":0,

[0700] "PacketCount":0,

[0701] "ByteCount":0,

[0702] "WrongInterface":0

[0703] }

[0704] },

[0705] "239.0.1.5":{

[0706] "*":{

[0707] "g10":{

[0708] "g10":{

[0709] "source":"*",

[0710] "group":"239.0.1.5",

[0711] "inboundInterface":"g10",

[0712] "outboundInterface":"g10",

[0713] "installed":1

[0714] }

[0715] },

[0716] "Installed":1,

[0717] "isRpt":true,

[0718] "RefCount":1,

[0719] "OilListSize":1,

[0720] "OilRescan":1,

[0721] "LastUsed":0,

[0722] "PacketCount":0,

[0723] "ByteCount":0,

[0724] "WrongInterface":0

[0725] }

[0726] }

[0727] }

[0728] Example output of the implemented show command

[0729] The following are examples of all the show commands added for the multicast control plane status.

[0730] Display the pim interface:

[0731] ================= ======== ============== =========== ===

[0732] Interface Status Address PIM Nbrs PIM DR FHR

[0733] ================= ======== ============== =========== ===

[0734] pimreg up 0.0.0.0 0 0.0.0.0 0

[0735] pim000000000001 up 16.0.0.2 1 16.0.0.2 0

[0736] g111 up 172.16.111.2 1 local0

[0737] pim000000000000 up 16.0.0.2 1 16.0.0.2 0

[0738] There is a "pimreg" interface because this is automatically created by FRR. The PIM interfaces generated for each BGPoSVR peer are the ones that begin with "pim".

[0739] show pim neighbors

[0740] ================== ============== =========== ===========

[0741] Interface Neighbor Uptime Waiting Time DR Priority

[0742] ================== ============== =========== ===========

[0743] pim000000000001 10.5.0.1 22:51:39 00:01:15 1

[0744] g111 172.16.111.6 22:51:32 00:01:15 1

[0745] pim000000000000 10.4.0.1 22:51:39 00:01:15 1

[0746] Show pim join

[0747] ================= =========== ============= =============

[0748] Interface address source group status running time expiration pruning

[0749] ================= =========== ============= =============

[0750] pim000000000001 16.0.0.2 * 227.0.0.100 up 00:04:22 02:43 --:--

[0751] pim000000000001 16.0.0.2 * 226.0.0.140 up 00:04:22 02:43 --:--

[0752] pim000000000001 16.0.0.2 * 226.0.0.41 up 00:04:22 02:43 --:--

[0753] pim000000000001 16.0.0.2 * 226.0.0.40 up 00:04:22 02:43 --:--

[0754] pim000000000001 16.0.0.2 10.111.1.7 226.0.0.11 up 00:04:22 02:43--:--

[0755] pim000000000001 16.0.0.2 * 226.0.0.10 up 00:04:22 02:43 --:--

[0756] pim000000000000 16.0.0.2 * 227.0.0.100 up 00:04:52 02:43 --:--

[0757] pim000000000000 16.0.0.2 10.111.1.7 226.0.0.11 up 00:04:51 02:43--:--

[0758] pim000000000000 16.0.0.2 * 226.0.0.10 up 00:04:51 02:43 --:--

[0759] Display pim status

[0760] ======== ============= ============= ====== ======

[0761] Active source group RPT IIF OIL

[0762] ======== ============= ============= ====== ======

[0763] 1 * 226.0.0.140 y g111 pim000000000001

[0764] 1 * 226.0.0.41 y g111 pim000000000001

[0765] 1 * 227.0.0.100 y g111 pim000000000001, pim000000000000

[0766] 1 * 226.0.0.40 y g111 pim000000000001

[0767] 1 * 226.0.0.10 y g111 pim000000000001, pim000000000000

[0768] 1 10.111.1.7 226.0.0.11 n g111 pim000000000001, pim000000000000

[0769] show pim mroute

[0770] IP Multicast Routing Table

[0771] Flags: S - sparse, C - joined, P - trimmed, R - RP bit set, F - registered flag, T - SPT bit set

[0772] ============= ============= ======== ======== ======= =======

[0773] Source Group Flag Prototype Input Output TTL Run Time

[0774] ============= ============= ======== ======== ======= ==

[0775] * 226.0.0.140 SP g111 pim000000000001 None 06:38:34

[0776] * 226.0.0.41 SP g111 pim000000000001 None 22:53:29

[0777] * 227.0.0.100 SP g111 pim000000000001 None 22:53:27

[0778] * 227.0.0.100 SP g111 pim000000000000 None 22:53:27

[0779] * 226.0.0.40 SP g111 pim000000000001 None 22:53:29

[0780] * 226.0.0.10 SP g111 pim000000000001 None 22:53:29

[0781] * 226.0.0.10 SP g111 pim000000000000 None 22:53:29

[0782] 10.111.1.7 226.0.0.11 STP g111 pim000000000001 None 02:18:04

[0783] 10.111.1.7 226.0.0.11 STP g111 pim000000000000 None 02:18:04

[0784] Display pim rp information:

[0785] =============== ===================== ========== ========= ==

[0786] RP Address Group / Prefix List OIF I am RP Source

[0787] =============== ===================== ========== ========== ===

[0788] 172.16.111.6 226.0.0.0 / 24 g111 No Static

[0789] 10.111.1.6 227.0.0.0 / 24 g111 No Static

[0790] show igmp interface

[0791] ================= ======== ========== ========= ========

[0792] Interface status address version query query timer running time

[0793] ================= ======== ========== ========= ========

[0794] pim000000000000 up 10.5.0.1 3 Others--:--:-- 22:58:06

[0795] g15 up 10.5.1.1 3 local 00:00:25 22:57:15

[0796] g25 up 10.5.2.1 3 local 00:00:58 06:04:10

[0797] show igmp group

[0798] =========== =========== ============= ========== =========

[0799] Interface Address Group Mode Timer Source Version Run Time

[0800] =========== =========== ============= ========== =========

[0801] g25 10.5.2.1 226.0.0.11 includes --:--:-- 1 3 06:05:40

[0802] g25 10.5.2.1 226.0.0.10 not included 00:03:51 1 3 06:05:40

[0803] g15 10.5.1.1 226.0.0.41 not included 00:03:16 1 3 22:58:45

[0804] g15 10.5.1.1 226.0.0.40 not included 00:03:16 1 3 22:58:45

[0805] g15 10.5.1.1 226.0.0.11 includes --:--:-- 1 3 22:58:45

[0806] g15 10.5.1.1 226.0.0.10 not included 00:03:16 1 3 22:58:45

[0807] g15 10.5.1.1 227.0.0.100 not included 00:03:16 1 3 22:37:10

[0808] g15 10.5.1.1 226.0.0.140 not included 00:03:16 1 3 06:43:50

[0809] constraint

[0810] The FRR code is used for multicast routing (PIM / IGMP). The FRR code limits each vrf to 255 multicast-enabled interfaces (MAXVIFS). However, the kernel has a lower limit of 32 MAXVIFs per vrf. Kernel changes may be required to scale beyond this limit.

[0811] The disclosed techniques support PIM sparse mode, static configuration of RPs, IGMP v2 / v3, multicast via SVR in hub and spoke topologies. In addition, the disclosed techniques contemplate the use of PIM-SSM, the ability to be an RP. When there are multiple senders on the LAN, PIM assertion processing will be performed. If there is no doubt that this is what the customer needs, then this may be deprioritized. It is assumed that BGP via SVR is configured when running multicast via SVR.

[0812] Figure 4 is a flowchart illustrating an example operation according to the technology of the present disclosure. Figure 1 To describe Figure 4 .like Figure 4 As depicted in the example of , network devices 110 exchange PIM messages across an L3 transport network, such as one or more service provider networks 150 .

[0813] Network device 110B defines a PIM service for a multicast service between network device 110A and network device 110B. In this example, network device 110A and network device 110B may or may not be directly connected. For example, one or more intermediate network devices (in the service provider network 150A) of service provider network 150A may be directly connected to each other. Figure 1 ) may provide a connection between network devices 110A and 110B.

[0814] Network device 110B establishes a virtual circuit interface and stores an association between the PIM service and the address of the virtual circuit interface. Network device 110A learns the address of the virtual circuit interface of network device 110B associated with the PIM service for multicast services between network devices 110A, 110B via a routing protocol such as BGP. In some examples, the address of the virtual circuit interface of network device 110B is used as a service identifier for the PIM service for multicast services between network devices 110A, 110B.

[0815] Network device 110A receives a multicast packet for a multicast group associated with a multicast service from multicast sender device 100A via L2 network 140A (400). Network device 110A generates a unicast L3 packet based at least in part on the multicast packet, the unicast L3 packet including a PIM registration request that is addressed to an RP device and is configured to register network device 110A as a multicast source for the multicast group (402). A header of the unicast L3 packet specifies a source address that includes a network address translation (NAT) to an address of a virtual circuit interface of network device 110B. In some examples, network device 110A performs NAT of the address of the multicast sender device to the address of the virtual circuit interface of network device 110B. In some examples, network device 110A performs NAT of the address of network device 110A to the address of the virtual circuit interface of network device 110B. Network device 110A forwards the unicast L3 packet to network device 110B across L3 transport network 150A (404). Fig. 9 An example of such a unicast L3 packet generated by network device 110A is described in FIG.

[0816] The network device 110B receives the unicast L3 packet. The network device 110B determines that the PIM registration request is associated with a multicast group associated with the multicast service based at least in part on a stored association between the PIM service and an address of a virtual circuit interface of the network device 110B. The network device 110B registers the network device 110A as a multicast source for the multicast group associated with the multicast service, e.g., by storing data associating the network device 110A with the multicast group for the multicast service and indicating that the network device 110A is a multicast source for the group / service.

[0817] Figure 5 is a flow chart showing an example operation according to the technology of the present disclosure. Figure 1 To describe Figure 5 .like Figure 5 As depicted in the example of , network devices 110 exchange PIM messages across an L3 transport network, such as one or more service provider networks 150 .

[0818] The network device 110B defines a PIM service for a multicast service between the network device 110B and the network device 110A (500). In some examples, the network device 110B is configured by an administrator to define a PIM service for each multicast service supported by the network device 110B. In some examples, the network device 110B defines multiple PIM services between, for example, different client devices in the client device 100, including a different PIM service between the network device 110B and the network device 110A for each of the multiple different multicast services. In some examples, when defining the PIM services, the network device 110B represents each PIM service with a different identifier (such as an integer or a text string) and generates mapping data between the identifier of a given PIM service and the corresponding multicast service.

[0819] In addition, network device 110B establishes a virtual circuit interface for network device 110B (502). In general, network device 110B may establish a different virtual circuit interface for each different PIM service defined by network device 110B. In some examples, network device 110B generates mapping data indicating an association between a PIM service identifier and a network address of the virtual circuit interface. Network device 110B stores the association between the PIM service and the address of the virtual circuit interface (504). In some examples, network device 110B stores the mapping data between the PIM service and the address of the virtual circuit interface on a storage medium (such as a storage medium). Figure 2 The network device 110B may advertise the association between the PIM service identifier and the network address of the virtual circuit interface to other network devices, such as to a BGP peer via a BGP session with the BGP peer. In some examples, the network device 110B sends the association to the network device 110A.

[0820] Network device 110B receives a unicast L3 packet from network device 110A via an L3 transport network (such as service provider network 150A) (506). The header of the unicast L3 packet specifies a source address, which is the address of the virtual circuit interface of network device 110B. The unicast L3 packet also includes (e.g., contained in the payload of the unicast L3 packet) a PIM registration request to the RP device. The PIM registration request is configured to enable the recipient to register network device 110A as a multicast source for a multicast group associated with a multicast service. Fig. 9 An example of such a unicast L3 packet received by network device 110B is described in FIG.

[0821] Network device 110B registers network device 110A as a multicast source for a multicast group associated with a multicast service based at least in part on an association between the stored PIM service and an address of a virtual circuit interface of network device 110A specified by a header of a unicast L3 packet (508). For example, network device 110B may identify the PIM service using the address of the virtual circuit interface on which the unicast L3 packet was received and mapping data between the PIM service and the address of the virtual circuit interface. In addition, network device 110B may identify the relevant multicast service using the identified PIM service and mapping data between the PIM service and the corresponding multicast service. Thereafter, network device 110B may register network device 110A as a multicast source for a multicast group associated with the identified multicast service using a PIM registration request specified by the unicast L3 packet. In some examples, network device 110B stores an association between network device 110A and the corresponding multicast group, which indicates network device 110A as a multicast source for the multicast group. In some examples, network device 110B maintains a database of multicast groups. In this example, network device 110B adds network device 110A to a multicast source list of an entry for a corresponding multicast group in the database. In some examples, network device 110B may be configured to discard multicast packets received from a network device that is not identified as a multicast source for a multicast group in the database.

[0822] Figure 6 is a flow chart showing an example operation according to the technology of the present disclosure. Figure 1 To describe Figure 6 .like Figure 6 As depicted in the example of , network devices 110 exchange PIM messages across an L3 transport network, such as one or more service provider networks 150 .

[0823] exist Figure 6 In some examples, client device 100B operates as a multicast receiver device for a multicast group associated with a multicast service. Network device 110I receives a multicast join request for the multicast group from client device 100B (600). In some examples, the multicast join request is an IGMP multicast join request.

[0824] Network device 110I is configured to generate a unicast L3 packet based on the received multicast join request and send it to network device 110H (602). The unicast L3 packet includes a header that includes (1) source address information that specifies address information of network device 110I, and (2) destination address information that specifies address information of network device 110H. In some examples, the destination address information specifies a virtual circuit interface of network device 110H. The virtual circuit interface of network device 110H may be associated with a PIM service between network device 110H and network device 110I for a multicast service associated with a multicast group.

[0825] The unicast L3 packet generated by the network device 110I also includes metadata that specifies a session identifier for a multicast service associated with the multicast group specified by the IGMP multicast join request. In addition, the unicast L3 packet includes a payload that contains a PIM join request to the RP device. The PIM join request is configured to cause the network device 110I to subscribe to the IGMP multicast group specified by the multicast join request. Fig.10 An example of such a unicast L3 packet generated by network device 110I is described in FIG.

[0826] Network device 110H registers network device 110I as a multicast receiver for the multicast group. In some examples, network device 110H may identify the PIM service using the virtual circuit interface of network device 110H specified by the unicast L3 packet and mapping data between the PIM services between network device 110H and network device 110I. In addition, network device 110H may identify the multicast service using the identified PIM service and mapping data between the PIM service and the multicast service. Network device 110H registers network device 110I as a multicast receiver for the multicast group associated with the identified multicast service.

[0827] In addition, network device 110H may forward the PIM join request to the RP for the multicast service. For example, network device 110G may be a hop from network device 110H toward the RP. Network device 110H modifies the source information of the unicast L3 packet to specify the address information of network device 110H, and modifies the destination address information of the unicast L3 packet to specify network device 110G. In some examples, the destination address information specifies the virtual circuit interface of network device 110G. The virtual circuit interface of network device 110G may be associated with the PIM service for the multicast service associated with the multicast group between network device 110G and network device 110H. Network device 110H forwards the modified unicast L3 packet to network device 110G. Network device 110G may register network device 110G as a multicast receiver of the multicast group associated with the multicast service. In this way, each upstream network device 110 (and the RP itself) toward the RP may register downstream network device 110 as a receiver of the multicast group associated with a specific multicast service.

[0828] Figure 7 is a flowchart illustrating an example operation according to the technology of the present disclosure. Figure 1 To describe Figure 7 .like Figure 7 As depicted in the example of , network devices 110 exchange PIM messages across an L3 transport network, such as one or more service provider networks 150 .

[0829] The network device 110A receives a multicast packet for a multicast group associated with a multicast service from a client device 100A (acting as a multicast source or multicast sender device) (700).

[0830] Network device 110A generates a unicast L3 packet based on the received multicast packet and sends the unicast L3 packet to network device 110B (702). The unicast L3 packet includes a header, which includes (1) source address information, specifying the address information of network device 110A, and (2) destination address information, specifying the address information of network device 110B. The unicast L3 packet also includes metadata, specifying a session identifier for a multicast service associated with the multicast group specified by the received multicast packet. In addition, the unicast L3 packet includes a PIM registration request, which is configured to register network device 110A as a multicast source for the multicast group specified by the received multicast packet. Fig. 9 An example of such a unicast L3 packet generated by network device 110A is described in FIG.

[0831] As mentioned above about Figure 5 As described, network device 110B registers network device 110A as a multicast source of a multicast group associated with a multicast service based at least in part on a PIM registration request specified by a unicast L3 packet. In some examples, network device 110B stores an association between network device 110A and a corresponding multicast group, which indicates network device 110A as a multicast source of the multicast group. In some examples, network device 110B maintains a database of multicast groups. In this example, network device 110B adds network device 110A to a multicast source list of an entry of a corresponding multicast group in the database. In some examples, network device 110B may be configured to discard multicast packets received from a network device that is not identified as a multicast source of a multicast group in the database.

[0832] Figure 8 is a flowchart illustrating an example operation according to the technology of the present disclosure. Figure 3B To describe Figure 8 .like Figure 8 As depicted in the example of , router 362A operates as a hub network device and router 360 operates as a spoke router, providing connections to one or more client devices, such as server 366 .

[0833] Branch router 360B connected to a multicast source device (eg, server 366B) receives multicast packets for a multicast group from the multicast source device (eg, server 366B). Branch router 360B stores multicast state information that specifies multicast source device 366B as a sender of the multicast group.

[0834] The branch router 360B generates a PIM registration message including a multicast packet and sends the PIM registration message to an RP (e.g., PE router 354B) via session-based routing. In some examples, the branch router 360B forms a first unicast L3 packet and sends the first unicast L3 packet to the hub router 362B, and the hub router 362B receives the first unicast L3 packet (802). The first unicast L3 packet includes source address information specifying an address of the branch router 360B and destination address information specifying an address of the hub router 362B. The first unicast L3 packet also includes metadata specifying a session identifier for a multicast service associated with the multicast group and a payload including a PIM registration request. The PIM registration request is configured to register the branch router 360B as a sender of the multicast group. Fig. 9 An example of such a first unicast L3 packet sent by the spoke router 360B is described in . In some examples, the hub router 362B forwards the PIM registration request encapsulated by the first unicast L3 packet to the RP, which can be external to the network (e.g., or data center 356A). For subsequent multicast packets, the spoke router 360B can omit metadata from the unicast L3 packet encapsulating the corresponding multicast packet.

[0835] Additionally, the first branch router 360A connected to a multicast recipient device (eg, server 366A) receives an IGMP multicast group join request from the multicast recipient device 366A. The branch router 360A stores multicast state information designating the multicast recipient device 366A as a member of the multicast group.

[0836] The branch router 360A generates a PIM join request and sends the PIM join request to the RP (PE router 354B) via session-based routing. In some examples, the branch router 360A forms a second unicast L3 packet and sends the second unicast L3 packet to the hub router 362B, and the hub router 362B receives the second unicast L3 packet (802). In some examples, the second unicast L3 packet includes source address information specifying an address of the branch router 360A and destination address information specifying an address of the hub router 362B. The second unicast L3 packet also includes metadata specifying a session identifier for a multicast service associated with the multicast group and a payload including the PIM join request. Fig.10 An example of such a second unicast L3 packet sent by the branch router 360A is described in . The PIM join request is configured to subscribe the branch router 360A to a multicast group associated with the multicast service. In some examples, the hub router 362B forwards the PIM join request encapsulated by the second unicast L3 packet to an RP (e.g., PE router 354B), which can be external to the network (or external to the data center 356A).

[0837] The hub router 362B generates and stores a multicast route for a multicast service based at least in part on a PIM registration request specified by a first unicast L3 packet and a PIM join request specified by a second unicast L3 packet (804). For example, the hub router 362B determines a multicast service associated with a multicast group based on a session identifier specified by the first unicast L3 packet. The hub router 362B determines that the branch router 360B is a multicast source for a multicast group associated with the identified multicast service based on the PIM registration request. In addition, the hub router 362B determines that the multicast service associated with the multicast group based on the session identifier specified by the second unicast L3 packet. The hub router 362B determines that the branch router 360A is subscribed to a multicast group associated with the identified multicast service based on the PIM join request. Hub router 362B generates and stores a multicast route that specifies spoke router 360B as being associated with a multicast source device of the multicast group and specifies spoke router 360A as being associated with a multicast recipient device of the multicast group.

[0838] Fig. 9 is a block diagram illustrating an example unicast L3 packet 900 encapsulating a PIM registration request according to the techniques of this disclosure. Fig. 9 As shown in the example of , unicast L3 packet 900 includes header 901. Header 901 specifies the source network device (e.g., Figure 1 The source address 902 is the address of the network device 110A, the source port 904 is the port of the source network device, and the destination address 906 is the address of the destination network device (for example, Figure 1 The source address 902 may include a NAT address that is an address of a virtual circuit interface of the destination device (e.g., network device 110B), a destination port 908 that is a port of the destination network device, and a network protocol 910. In some examples, the source address 902 may include a NAT address that is an address of a virtual circuit interface of the destination device (e.g., network device 110B), the virtual circuit interface being associated with a PIM service established between the source network device and the destination network device for a multicast service.

[0839] The unicast L3 packet 900 also includes metadata 920. The metadata 920 includes a session identifier for the multicast service for which the PIM service is established.

[0840] Unicast L3 packet 900 encapsulates PIM registration request 924. PIM registration request 924 is configured to register a source network device (e.g., network device 110A) with the RP as a multicast source for a multicast group associated with a multicast service specified by session identifier 922. In addition, PIM registration request 924 encapsulates multicast packet 926 that originates from a multicast source device (e.g., Figure 1 client device 100A) and to a multicast recipient device (e.g., Figure 1 The multicast packet 926 is sent by a multicast source device (eg, client device 100A) to a multicast group associated with a multicast service, the multicast group including a multicast recipient device (eg, client device 100B).

[0841] Fig.10 is a block diagram illustrating an example unicast L3 packet 1000 encapsulating a PIM join request according to the techniques of this disclosure. Fig.10 As shown in the example of , unicast L3 packet 1000 includes header 1001. Header 1001 specifies the source network device (e.g., Figure 1 The source address 1002 is the address of the network device 110B, the source port 1004 is the port of the source network device, and the destination address 1006 is the address of the destination network device (for example, Figure 1 10A), a destination port 1008 as a port of a destination network device, and a network protocol 1010. In some examples, source address 1002 specifies a NAT address that is an address of a virtual circuit interface of a destination device (e.g., network device 110A), the virtual circuit interface being associated with a PIM service established between the source network device and the destination network device for a multicast service.

[0842] The unicast L3 packet 1000 also includes metadata 1020. The metadata 1020 includes a session identifier for the multicast service for which the PIM service is established.

[0843] Unicast L3 packet 1000 encapsulates PIM join request 1024. PIM join request 1024 is configured to register a source network device (e.g., network device 110B) with the RP as a multicast recipient of a multicast group associated with a multicast service specified by session identifier 1022. PIM join request 1024 may be received by the source network device in response to a request from a multicast recipient device (e.g., Figure 1 The IGMP group join request is sent when the client device 100B receives the IGMP group join request. The IGMP group join request is configured to enable a multicast receiver device (eg, the client device 100B) to subscribe to a multicast group associated with a multicast service.

[0844] The following examples may illustrate one or more aspects of the present disclosure.

[0845] Embodiment 1. A first network system comprises: a storage medium; and a processing circuit that communicates with the storage medium, the processing circuit being configured to: define a protocol independent multicast (PIM) service between the first network system and a second network device, each of the PIM services being associated with a corresponding multicast service in a plurality of multicast services; establish a virtual loop interface of the first network system, each of the virtual loop interfaces corresponding to a corresponding one of the PIM services; and store an association between an address of each of the virtual loop interfaces and a corresponding PIM service in the PIM services. In some embodiments, the processing circuitry may be further configured to: receive a unicast L3 packet from a second network device via a Layer 3 (L3) transport network, the unicast L3 packet comprising: a header specifying a source address, the source address being an address of a first virtual circuit interface in the virtual circuit interfaces; and a payload comprising a PIM registration request to a rendezvous point (RP) device of a multicast group for registering the second network device as a multicast source for the multicast group; and register the second network device as a multicast source for the multicast group based at least in part on an association between the address of the first virtual circuit interface specified by the header of the unicast L3 packet and a first PIM service in the PIM services, the multicast group being associated with a first multicast service in a plurality of multicast services, the first multicast service being associated with the first PIM service. In some cases, the processing circuitry may be configured to prune a multicast tree for the multicast group based on registering the second network device as a multicast source.

[0846] Embodiment 2. The first network system according to embodiment 1, wherein the address of the first virtual circuit interface includes a service identifier of a first PIM service between the first network system and the second network device.

[0847] Embodiment 3. The first network system according to any one of embodiments 1 to 2, wherein before receiving the unicast L3 packet, the processing circuit is configured to advertise the association between the address of the first virtual circuit interface and the first PIM service to the second network device via a routing protocol.

[0848] Embodiment 4. The first network system according to embodiment 3, wherein the routing protocol is Border Gateway Protocol (BGP).

[0849] Embodiment 5. The first network system according to any one of embodiments 1 to 4, wherein, to receive a unicast L3 packet, the processing circuit is configured to: receive the unicast L3 packet via a multi-protocol label switching (MPLS) transport network, wherein the unicast L3 packet is encapsulated with one or more MPLS labels.

[0850] Embodiment 6. A first network system comprises: a storage medium, and a processing circuit in communication with the storage medium, the processing circuit being configured to: receive a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to a first network device via a Layer 2 (L2) network; generate a unicast Layer 3 (L3) packet based at least in part on the multicast packet, the unicast L3 packet comprising: a header specifying a source address, the source address being an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device, and a payload comprising a protocol independent multicast (PIM) registration request to a rendezvous point (RP) device of the multicast service for registering the first network device as a multicast source of the multicast group; and forward the unicast L3 packet to the second network device across the L3 transport network.

[0851] Embodiment 7. A first network system according to embodiment 6, wherein the processing circuit is further configured to: learn from the second network device via a routing protocol session between the first network device and the second network device, the address of the virtual loop interface of the second network device associated with the PIM service for multicast service between the first network device and the second network device.

[0852] Embodiment 8. The first network system according to embodiment 7, wherein the routing protocol is Border Gateway Protocol (BGP).

[0853] Embodiment 9. A first network system according to any one of Embodiments 6 to 8, wherein the processing circuit is further configured to: define a second PIM service; establish a second virtual loop interface; store an association between the second PIM service and the address of the second virtual loop interface; and notify the second network device of the association between the second PIM service and the address of the second virtual loop interface.

[0854] Embodiment 10. A first network system according to any one of embodiments 6 to 9, wherein, in order to forward a unicast L3 packet to a second network device across a transport network, the processing circuit is configured to: perform session-based routing to forward the unicast L3 packet across the transport network based on session routing by: modifying a header of the unicast L3 packet to specify an address of the first network device as a source address and an address of the second network device as a destination address; and adding metadata specifying an address of a virtual loop interface of the second network device to the unicast L3 packet.

[0855] Embodiment 11. A first network system according to any one of embodiments 6 to 10, wherein, in order to forward the unicast L3 packet to the second network device across the transport network, the processing circuit is configured to: forward the unicast L3 packet across a multi-protocol label switching (MPLS) transport network by encapsulating the unicast L3 packet with one or more MPLS labels.

[0856] Embodiment 12: The first network system according to any one of embodiments 6 to 11, wherein the address of the virtual circuit interface of the second network device includes a service identifier of a PIM service for multicast service between the first network device and the second network device.

[0857] Embodiment 13. A method, comprising: receiving, by a first network device, a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to the first network device via a Layer 2 (L2) network; generating, by the first network device at least partially based on the multicast packet, a unicast Layer 3 (L3) packet including a Protocol Independent Multicast (PIM) registration request that is destined for a rendezvous point (RP) device and is configured to register the first network device as a multicast source for the multicast group, wherein a header of the unicast L3 packet specifies a source address, the source address including a Network Address Translation (NAT) to an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device; and forwarding, by the first network device, the unicast L3 packet to the second network device across the L3 transport network.

[0858] Embodiment 14. The method according to embodiment 13 further includes: learning, by the first network device and via a routing protocol, from the second network device an address of a virtual loop interface of the second network device associated with a PIM service for a multicast service between the first network device and the second network device.

[0859] Embodiment 15. The method of embodiment 14, wherein the routing protocol is Border Gateway Protocol (BGP).

[0860] Embodiment 16. The method according to any one of Embodiments 13 to 15 further includes: defining a second PIM service by the first network device; establishing a second virtual loop interface by the first network device; and storing an association between the second PIM service and the address of the second virtual loop interface by the first network device.

[0861] Embodiment 17. A method according to any one of embodiments 13 to 16, wherein forwarding a unicast L3 packet across a transport network to a second network device includes: performing session-based routing to forward the unicast L3 packet across a session-routed transport network by: modifying a header of the unicast L3 packet to specify an address of the first network device as a source address and an address of the second network device as a destination address; and adding metadata to the unicast L3 packet that specifies an address of a virtual loop interface of the second network device.

[0862] Embodiment 18. A method according to any one of embodiments 13 to 17, wherein forwarding the unicast L3 packet across the transport network to the second network device includes: forwarding the unicast L3 packet across a multi-protocol label switching (MPLS) transport network by encapsulating the unicast L3 packet with one or more MPLS labels.

[0863] Embodiment 19. The method according to any one of Embodiments 13 to 18, wherein the address of the virtual circuit interface of the second network device includes a service identifier of a PIM service for multicast services between the first network device and the second network device.

[0864] Embodiment 20. A non-transitory computer-readable medium comprising instructions that, when executed, are configured to cause a processing circuit of a first network system to perform the following operations: receive a multicast packet for a multicast group associated with a multicast service from a multicast sender device connected to a first network device via a Layer 2 (L2) network; generate a unicast Layer 3 (L3) packet based at least in part on the multicast packet, the unicast L3 packet comprising: a header specifying a source address, the source address being an address of a virtual circuit interface of a second network device, the virtual circuit interface being associated with a PIM service for the multicast service between the first network device and the second network device, and a payload comprising a protocol independent multicast (PIM) registration request to a rendezvous point (RP) device of the multicast service for registering the first network device as a multicast source for the multicast group; and forward the unicast L3 packet to the second network device across the L3 transport network.

[0865] The techniques described in this disclosure may be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuits, and any combination of such components. The term "processor" or "processing circuit" may generally refer to any of the aforementioned logic circuits, alone or in combination with other logic circuits or any other equivalent circuits. A control unit including hardware may also perform one or more techniques of the present disclosure.

[0866] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any described units, modules, or components may be implemented together or individually as discrete but interoperable logic devices. Depicting different features as modules or units is intended to highlight different functional aspects and does not necessarily mean that such modules or units must be implemented by separate hardware or software components. Instead, functions associated with one or more modules or units may be performed by separate hardware or software components, or functions associated with one or more modules or units may be integrated within common or separate hardware or software components.

[0867] The techniques described in the present disclosure may also be embodied or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. The instructions embedded or encoded in the computer-readable storage medium may cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. The computer-readable storage medium may include a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a hard disk, a CD-ROM, a floppy disk, a tape, a magnetic medium, an optical medium, or other computer-readable medium.< / vrfname> < / vrfname> < / node> < / node>

Claims

1. A network system, comprising: Storage media; as well as a processing circuit in communication with the storage medium, the processing circuit being configured to: receiving, from a multicast sender device connected to the network system via a layer 2 L2 network, a multicast packet for a multicast group associated with a multicast service; generating a unicast layer 3 L3 packet based at least in part on the multicast packet, the unicast L3 packet comprising: a header specifying a source address, the source address being an address of a virtual circuit interface of a network device, the virtual circuit interface being associated with a PIM service between the network system and the network device for the multicast service, and A payload, comprising a protocol independent multicast PIM registration request to a rendezvous point RP device of the multicast service for registering the network system as a multicast source of the multicast group; as well as The unicast L3 packet is forwarded to the network device across the L3 transport network.

2. The network system according to claim 1, wherein: The processing circuit is further configured to: The address of the virtual circuit interface of the network device associated with the PIM service for the multicast service between the network system and the network device is learned from the network device via a routing protocol session between the network system and the network device.

3. The network system according to claim 2, wherein: The routing protocol is the Border Gateway Protocol BGP.

4. The network system according to claim 1, wherein: The processing circuit is further configured to: Define a second PIM service; establishing a second virtual circuit interface; storing an association between the second PIM service and the address of the second virtual circuit interface; as well as The association between the second PIM service and the address of the second virtual circuit interface is advertised to the network device.

5. The network system according to claim 1, wherein: The address of the virtual circuit interface of the network device includes a service identifier of the PIM service used for the multicast service between the network system and the network device.

6. The network system according to any one of claims 1 to 5, wherein: To forward the unicast L3 packet to the network device across the transport network, the processing circuit is configured to: Performing session-based routing to forward the unicast L3 packet across a session-based routing transport network by: modifying the header of the unicast L3 packet to specify an address of the network system as the source address and an address of the network device as the destination address; as well as Metadata specifying the address of the virtual circuit interface of the network device is added to the unicast L3 packet.

7. The network system according to any one of claims 1 to 5, wherein: To forward the unicast L3 packet to the network device across the transport network, the processing circuit is configured to: The unicast L3 packet is forwarded across a Multi-Protocol Label Switching (MPLS) transport network by encapsulating the unicast L3 packet with one or more Multi-Protocol Label Switching (MPLS) labels.

8. A computer networking method, comprising: receiving, by a network system and from a multicast sender device connected to the network system via a layer 2, L2, network, a multicast packet for a multicast group associated with a multicast service; generating, by the network system and based at least in part on the multicast packet, a unicast layer 3 L3 packet including a protocol independent multicast (PIM) registration request destined for a rendezvous point (RP) device and configured to register the network system as a multicast source for the multicast group, wherein a header of the unicast L3 packet specifies a source address, the source address comprising a network address translation NAT to an address of a virtual circuit interface of a network device, the virtual circuit interface being associated with a PIM service between the network system and the network device for the multicast service, and The unicast L3 packet is forwarded by the network system to the network device across the L3 transport network.

9. The computer networking method according to claim 8, further comprising: The address of the virtual circuit interface of the network device associated with the PIM service for the multicast service between the network system and the network device is learned from the network device by the network system via a routing protocol.

10. The computer networking method according to claim 9, wherein: The routing protocol is the Border Gateway Protocol BGP.

11. The computer networking method according to claim 8, further comprising: A second PIM service is defined by the network system; The network system establishes a second virtual circuit interface; as well as An association between the second PIM service and the address of the second virtual circuit interface is stored by the network system.

12. The computer networking method according to claim 8, wherein: The address of the virtual circuit interface of the network device includes a service identifier of the PIM service used for the multicast service between the network system and the network device.

13. The computer networking method according to any one of claims 8 to 12, wherein: Forwarding the unicast L3 packet to the network device across the transport network includes: Performing session-based routing to forward the unicast L3 packet across a session-based routing transport network by: modifying the header of the unicast L3 packet to specify an address of the network system as the source address and an address of the network device as a destination address; and Metadata specifying the address of the virtual circuit interface of the network device is added to the unicast L3 packet.

14. The computer networking method according to any one of claims 8 to 12, wherein: Forwarding the unicast L3 packet to the network device across the transport network includes: The unicast L3 packet is forwarded across a Multi-Protocol Label Switching (MPLS) transport network by encapsulating the unicast L3 packet with one or more Multi-Protocol Label Switching (MPLS) labels.

15. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to be configured as the processing circuit of the network system according to any one of claims 1 to 7, or to be configured to execute the computer networking method according to any one of claims 8 to 14.

Images