Distribution of multicast information in routing

Abstract

A routing system for distributing multicast routing information for a multicast service includes a plurality of routers, the plurality of routers including a multicast source router and a plurality of multicast receiver routers, the plurality of routers providing a multicast service, wherein the router is configured to exchange multicast information associated with the multicast service comprising identifications of the multicast source and the multicast recipient.

Description

[0001] Description of divisional application

[0002] This application is a divisional application of the invention patent application with application date of May 12, 2020, application number 202080035115.8, and invention name “Distribution of multicast information in routing”.

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This patent application is related to U.S. patent application No. 15 / 054,781 (now issued U.S. Patent No. 9,985,883), entitled "NAME-BASED ROUTING SYSTEM AND METHOD," filed on February 26, 2016, agent file number 4094 / 1014 and naming MeLampy, Baj, Kumar, Penfield and Timmons as inventors, the disclosure of which is incorporated herein by reference in its entirety.

[0005] This patent application is also related to U.S. patent application No. 14 / 833,571 (now issued U.S. Patent No. 9,762,485), entitled "Network Packet Flow Controller with Extended Session Management," filed on August 24, 2015, agent file number 4094 / 1011, and naming Kaplan, Kumar, Timmons and MeLampy as inventors, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0006] The present invention generally relates to the distribution of multicast information in a routing system. Background Art

[0007] Routing platforms such as the 128T routing platform from 128 Technologies of Burlington, Mass., can be considered service-oriented because service configuration is the focus of the data model (and thus the configuration paradigm). In such service-oriented routing platforms, administrators can define services to represent the capabilities that their network is designed to deliver to consumers, and these services—along with their required policies and properties—determine how traffic patterns traverse the network.

[0008] The 128T routing platform consists of two main components: the Session Smart Router (SSR) and the Conductor. Together, the SSR and Conductor form a highly distributed single logical control plane and a truly session-aware data plane. The SSR combines a service-centric control plane and a session-aware data plane to provide all IP routing tables, feature-rich policy management, advanced data aggregation and analysis, and high-speed packet forwarding, classification, and security capabilities. Conductor is a centralized management and policy engine that provides orchestration, management, zero-touch provisioning, monitoring, and analysis for distributed SSRs—while maintaining a network-wide multi-tenant service and policy data model. With these components, the 128T routing platform supports a variety of deployment models from small branches to high-capacity edge routers to hyperscale software-defined data centers.

[0009] Until now, the concept of a service has been limited to a single "router" (a collection of nodes), or exported to an external router using explicit configuration using Conductor. This can make service configuration difficult to scale to a large number of SSRs. Summary of the invention

[0010] According to one embodiment of the present invention, a routing system for providing multicast access control includes multiple routers, the multiple routers include routers for multicast sources and multiple multicast receivers, the multiple routers provide multicast services, wherein the routers are configured to implement multicast access control policies for the multicast services, the multicast access control policies include receiver access policies that control which multicast receivers are allowed to receive packets from the multicast service and sender access policies that control which multicast sources are allowed to send packets to the multicast service for distribution to the multicast receivers.

[0011] According to another embodiment, a router for providing multicast access control includes: a data storage device, which stores multicast access control policies for multicast services, the multicast access control policies including receiver access policies that control which multicast receivers are allowed to receive packets from the multicast service and sender access policies that control which multicast sources are allowed to send packets to the multicast service for distribution to the multicast receivers; and a controller, which is configured to implement the multicast access control policies for the multicast service.

[0012] In various alternative embodiments of the routing system and router described above, the sender access policy may include a tenant-based sender access policy, the tenant-based sender access policy specifies at least one source tenant that is allowed to send packets to the multicast service. The receiver access policy may include a tenant-based receiver access policy, the tenant-based receiver access policy specifies at least one receiver tenant that is allowed to receive packets from the multicast service. The router may only accept multicast joins from interfaces associated with at least one receiver tenant. The router may only accept multicast joins from interfaces associated with at least one receiver tenant unless the tenant-based receiver access policy is overridden by a configuration on one or more interfaces. At least one router may be configured to accept multicast joins from interfaces that are not designated receiver tenants. At least one router may be configured to reject multicast joins from interfaces that are designated receiver tenants. The router may be configured to transmit membership query messages on interfaces associated with at least one receiver tenant. The router may be configured to discard member report messages on any interface with a tenant that cannot access the multicast service. The router may be configured to exchange multicast information associated with the multicast service including identification of multicast sources and multicast receivers. Each router may be configured to transmit multicast information of the router to a central repository and receive multicast information for other routers from the central repository. At least the source router may be configured to determine an optimal rendezvous point router for distributing packets associated with a multicast service based on the exchanged multicast information. The multicast source router may be configured to transmit unicast packets for the multicast service to each multicast receiver router associated with at least one multicast receiver. The multicast source router may be configured to join a multicast tree and transmit multicast packets to a plurality of multicast receiver routers.

[0013] Additional embodiments may be disclosed and claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Those skilled in the art should more fully appreciate the advantages of the various embodiments of the present invention from the following "Description of Illustrative Embodiments," which is discussed with reference to the drawings summarized below.

[0015] Figure 1 is a schematic diagram showing the main components of the STEP server 100 according to an exemplary embodiment.

[0016] Figure 2 is a logic flow diagram of the STEP server controller 120 for implementing advanced STEP server functions according to an exemplary embodiment.

[0017] Figure 3 is a schematic diagram illustrating major components of a STEP client 300 according to an exemplary embodiment.

[0018] Figure 4 is a logic flow diagram of the STEP client controller 220 for implementing advanced STEP client functions according to an exemplary embodiment.

[0019] Figure 5 is a schematic diagram showing an exemplary topology partitioned into a region having multiple neighborhoods.

[0020] Figure 6 is with Figure 5 Schematic diagram of the same topology but divided into multiple areas.

[0021] Figure 7 is a schematic diagram showing a topology including two routers that are peers to each other.

[0022] Figure 8 is a diagram of an example of redistributing BGP to services.

[0023] Fig. 9 The following is an example diagram of redistributing BGP to STEP.

[0024] Fig.10 is a schematic diagram showing the topology of a multicast configuration including no receivers.

[0025] Fig.11 It shows Fig.10 But now router R2 has received IGMP joins on both of its interfaces.

[0026] Fig.12 is shown with Figure 6 Schematic diagram of the same topology.

[0027] Fig.13 is a schematic diagram of a topology including service exchanges between areas resulting in a loop.

[0028] Fig.14 It shows Fig.13 The topology does not include a schematic diagram of service exchange between areas with loop avoidance.

[0029] Fig.15 is a schematic diagram showing a topology including source-based routing within the same area.

[0030] Fig.16 is a schematic diagram illustrating a topology including source-based routing across multiple regions.

[0031] Fig.17 is a schematic wireframe diagram showing a heatmap view of a network.

[0032] Fig.18is a logic flow diagram for publishing aggregated routes or services according to an exemplary embodiment.

[0033] Fig.19 is a logic flow diagram for loop detection and prevention according to an exemplary embodiment.

[0034] Fig. 20 is a logic flow diagram for source-based routing according to an exemplary embodiment.

[0035] Fig.21 is a schematic diagram showing a topology including point-to-multipoint SVR routing.

[0036] Fig. 22 is a schematic diagram showing a topology including multicast proxy routing.

[0037] It should be noted that the aforementioned figures and the elements depicted therein are not necessarily drawn to consistent scale or to any scale. Unless the context implies otherwise, the same elements are indicated by the same numerals. DETAILED DESCRIPTION

[0038] definition

[0039] As used in this specification and the appended claims, unless the context requires otherwise, the following terms shall have the indicated meanings:

[0040] STEP stands for Service and Topology Exchange Protocol, which is used to describe various mechanisms for distributing various types of service and topology state information among and between routers and for making intelligent routing decisions using this distributed service and topology state information.

[0041] An Authority is a single administrative domain consisting of a collection of routers; typically similar to an Autonomous System (AS) in a BGP network. An Authority can be a single network, a collection of networks, or a single managed entity for a group of routers. In an exemplary embodiment, an Authority is named using a text string. Authority names are unique and can be assigned / managed by a naming authority or other technology that ensures uniqueness. In an exemplary embodiment, a private naming authority is used, but a public naming authority (e.g., IANA or equivalent) can be used in alternative embodiments. In an exemplary embodiment, an Authority name is a resource name that complies with RFC 1737.

[0042] A neighborhood is an IP network of reachability. All router interfaces configured to be in the same neighborhood are expected to be mutually reachable. This includes interfaces separated by network boundaries, NATs, and firewalls but reachable from each other. In an exemplary embodiment, a neighborhood is a label (string value) applied to a network interface that describes the desired connectivity (peer relationship) between routers. Any two router interfaces that share at least one neighborhood label within an organization are assumed to be connected to a common L3 network, which is intended to make those two interfaces mutually reachable. Assigning two interfaces to the same neighborhood causes the routers to establish a peer relationship with each other. In an exemplary embodiment, each network interface on the SSR belongs to at least one neighborhood, and if the administrator does not configure the network interface, the SSR will automatically assign it a unique neighborhood name among all interfaces within the organization. A network interface can be a member of multiple neighborhoods and can contain a user-sorted list of neighborhoods that all describe the same non-unique L3 network. In this context, the user-ordered list specifies the ordering of the neighborhoods, where the first neighbor listed will be considered the "primary" neighborhood and will be the neighborhood associated with all inbound sessions arriving at that network interface for analysis data, redundant state information, and other interface-specific metrics. Two network interfaces belonging to the same neighborhood are effectively treated as having a direct neighbor relationship, even if the communication path between the two network interfaces passes through one or more other routers. In an exemplary embodiment, in order to constrain which interfaces attempt to peer with each other and avoid unnecessary peer relationships, the neighborhood of each interface can be assigned a topology type of mesh, hub, or spoke, where mesh interfaces attempt to peer with all other neighbor interfaces of type mesh or hub, hub interfaces attempt to peer with all other neighbor interfaces of type mesh, and spoke interfaces attempt to peer with all other neighbor interfaces of type mesh or hub.

[0043] A district is essentially a collection of neighborhoods. Each router participating in a district will receive link state metrics about every other router interface in the same district. This information can be used to aggregate service state availability to other districts.

[0044] A "tenant" is a single subnetwork that is isolated and separate from all other subnetworks, for example, for security, manageability, and analytics. This is similar to a VLAN or VxLAN or VRF. A tenant is a text string assigned by an organization or parent tenant.

[0045] A "service" is a single named application and is the target of a route. This is similar to an IP address after a DNS resolution or CIDR block. Services are named with a text string that usually matches the URL of the service. Services are represented by text strings used within routing protocols.

[0046] A "Service Group" is a portion of a subnet (tenant) that is to be isolated, for example, for manageability and analysis. A Service Group is represented by a text string used within routing protocols.

[0047] A "Qualified Service Name" or "QSN" is an addressable resource. This is a textual representation of a tenant, service group, or service. In an exemplary embodiment, each QSN has a unique authority and uses the URI generic syntax defined by RFC3986 in the form of QSN: / / Subtenant.Tenant.Authority / ServiceGroup / Service. Service groups are optional, and if they are not used, the QSN can be shortened to not include this text. Some exemplary embodiments of QSNs, tenants, service groups, and services are described in related U.S. Patent Application No. 15 / 054,781 filed on February 26, 2016 (now issued U.S. Patent No. 9,985,883), which is incorporated by reference above.

[0048] SVR stands for Security Vector Routing. This is how packets are forwarded between two peer SSRs in a 128T routing platform. SVR implements aspects of session-based routing as described in related U.S. Patent Application No. 14 / 833,571 (now issued U.S. Patent No. 9,762,485), which is incorporated by reference above.

[0049] Vector is a property of a neighborhood on a given router interface, and administrators can use it to apply control on the routing decision logic (path selection) adopted by the router. The neighborhood describes the topology (peer relationship) between routers, and the vector describes the path preference of the service business on this topology. Each neighborhood (within the interface) can contain the name of the vector, which is a label that allows administrators to attribute certain properties to the neighborhood to affect routing. Vectors can also be considered as names for peer relationships between two routers in a neighborhood. Once vectors are configured, administrators can assign priorities to these vectors within the service policy configuration element, for example, a service (via its policy) can indicate a preferred vector type or vector hierarchy for a particular service. For example, a video conferencing service may be configured to use MPLS vectors (if available), otherwise use basic Internet path vectors. In addition, service policies can assert that certain vectors will never be used for a given service. For example, HD video conferencing services may be unavailable or too expensive when sent over LTE, so in an exemplary embodiment, an administrator can assign a "never" priority to the LTE vector for HD video services. Additionally or alternatively, vectors may be associated with various metrics (e.g., cost or performance based metrics) for use in selecting routes. For example, if a network includes vectors A, B, C, D, with respective costs of 10, 20, 50, 60, and a route may use either vector A / C or vector B / D, then a router will typically select vector A / C with a total cost of 60 rather than vector B / D with a total cost of 80. Different routes to a particular destination may be calculated by assigning different costs to links for different services, e.g., for the purpose of Web traffic, a particular link may have a cost of X, and for the purpose of email traffic, a link may have a cost of Y, so that even though both types of traffic arrive at the same egress router, the routes for Web traffic and for email traffic traverse different paths through the network.

[0050] Unless the context requires otherwise, the terms "publication" and "announcement" (and variations thereof) may be used interchangeably.

[0051] A "set" consists of one or more members.

[0052] introduction

[0053] In an exemplary embodiment, a routing system for distributing multicast routing information for a multicast service includes multiple routers, the multiple routers including a multicast source router and a plurality of multicast receiver routers, the multiple routers providing a multicast service, wherein the routers are configured to exchange multicast information associated with the multicast service including identifications of the multicast source and the multicast receivers.

[0054] Exemplary embodiments are described herein with reference to a Session Smart Router (SSR) of the type sold by 128 Technologies, Inc. of Burlington, Massachusetts, but one of ordinary skill in the art will appreciate that various aspects of the described embodiments may be applied to other network devices, now or in the future, to overcome the types of network and configuration problems described herein.

[0055] As discussed above, service configuration for a large number of SSRs can be difficult. In addition, because the network is constantly changing, information about services and service reachability needs to be exchanged between SSRs because the network and application states are dynamic. For example, service routes are typically configured for services with known destinations - similar to static routes. In some cases, services use routes to learn the next hop. These routes can be learned in a variety of ways, such as via traditional routing protocols (e.g., OSPF, BGP, etc.), static routes, or connection routes. Each SSR can learn different routes by running different routing protocols. Routes ultimately need to be applied to services, applied to applications, and / or distributed to other SSRs. If some routes are withdrawn, some of these services may become unavailable, and this state change needs to be propagated. In addition, SSRs currently have no way of knowing whether the service is available at the final destination (last hop). From a network perspective, this lack of visibility can lead to incorrect routing of packets.

[0056] In an exemplary embodiment, routers within a network segment (e.g., within an organization or region as discussed below, up to and including the entire network) implement a service and topology exchange protocol (referred to herein as STEP) to exchange service and topology state information so that each router in the network segment that participates in STEP (referred to herein as a STEP router) obtains service and topology state information from all other STEP routers in the network segment and optionally also from STEP routers outside the network segment. Among other things, STEP allows STEP routers to propagate network state and network state changes and manage services across routers, for example, as more routers become part of an organization or region. A network can be segmented into multiple segments, and a STEP router can be a member of multiple segments, thereby participating in STEP exchanges within each segment of which it is a member. A STEP router in a segment can advertise services and routes both within the segment and outside the segment. When a service or route is advertised outside of the portion, the service or route can be advertised as an aggregate service or route, e.g., identifying a specific STEP router in the portion through which the service or route can be accessed, and optionally including an aggregate metric for the aggregate service or route (e.g., loss, latency, jitter, and / or cost values ​​for the aggregate service or route based on metrics of individual links / paths associated with the service or route within the network portion). Among other things, such segmented routing, e.g., segmenting a network and allowing advertisement of aggregate services and routes across network segments, can reduce the amount of information traffic required to distribute service and topology state information.

[0057] The STEP routers within each network segment are typically specified by configured relationships, e.g., which STEP routers belong to a particular organization or region. Based on these configured relationships, the STEP routers can directly or indirectly exchange service and topology state information, as discussed further below. The service and topology state information can include traditional link state information (e.g., obtained from traditional routing protocols, such as OSPF or BGP) and additional information, such as service level agreement (SLA) information (e.g., the service level agreement for a particular service, and whether the service is operating within the service level agreement), path metrics (e.g., configured link speed, actual calculated link speed, link state up / down, jitter, packet loss rate, latency, vector information and / or cost value for each path / vector), multicast membership and permission information, and other information relevant to making intelligent routing decisions. Thus, among other things, STEP provides STEP routers with more information than is available from traditional routing protocols alone, which allows each STEP router to make smarter routing decisions (including routing packets based on service level agreements (SLAs) and path metrics), make intelligent multicast routing decisions, and support intelligent source routing, to name just a few of the ways in which STEP can be utilized.

[0058] In certain exemplary embodiments, STEP is implemented using a centralized distribution system (referred to herein as a STEP server or STEP repository) for dynamically exchanging service and topology state information between and through routers so that the routers can make more intelligent routing decisions. Specifically, each router participating in STEP (hereinafter referred to as a STEP router) dynamically transmits its own service and topology state information to the STEP repository, and dynamically receives service and topology state information for one or more other STEP routers from the STEP repository based on the configured relationships between the STEP routers. The STEP repository is managed by a STEP server in any of the various network devices discussed below, and each STEP router implements a STEP client for the client-server model. Certain exemplary embodiments are described below in the context of the centralized distribution system, but it should be noted that STEP can be implemented using other mechanisms for distributing service and topology state information, some of which are described below.

[0059] It should be noted that a STEP router may include an SSR or other router that adds some or all of the STEP functionality described herein.

[0060] STEP is being developed to address the following challenges in current SSR network deployments, but it generally provides a mechanism for distributing information within a network that may be used for other purposes now or in the future:

[0061] Interact with multiple routing protocols

[0062] Between two SSR peers, BGP needs to be provisioned on top of the SVR in order to exchange BGP routes between the two SSRs. This does not scale well across multiple SSRs. There is also a need to map the routing information from these legacy routing protocols to the SSR world of services and service-routes. STEP provides an easy way to implement this. It also provides an extensible way to interact with any future legacy protocols such as ISIS, etc. if needed or desired. Using STEP, network administrators will be able to plug SSRs into any legacy router, map them to services and make them available to the entire network.

[0063] Multicast

[0064] For multicast (e.g., IGMP support), all multicast receivers for a group are known by the SSR. Using STEP, the receiver endpoints will be announced via the STEP repository and the best replication / rendezvous point can be determined to send the multicast packet to all receivers, e.g., the minimum tree required to distribute the multicast packet.

[0065] Endpoint availability

[0066] A remote SSR can route a service to another SSR where the service is no longer available. Service availability is not limited to routing or path status. The health API can also be used to query the final application status, rather than being limited to link status alone to determine service status. Currently, SSRs use path and interface failover techniques to address this limitation, which do not work in all cases, especially in the event of a complete outage and when services on other routers are also unavailable. STEP can propagate service availability information across the entire network so that each router can make intelligent decisions and minimize outages.

[0067] Accurately locate service outages across the network

[0068] STEP stores service and topology state information in a STEP repository. Thus, a STEP repository typically has a view of the entire network at any given time, and the STEP repository can also store historical information as service and topology state information updates are received from STEP routers. This current and historical information can be used for any of a variety of purposes, such as troubleshooting service and topology issues, making network management decisions (e.g., shutting down a particular router, or controlling what information a particular router announces via the STEP repository), and even restoring to a previous network state (e.g., by "replaying" a series of network state changes), to name a few. A service outage or heat map view of the entire network can be easily generated at any given time. This helps with fault isolation and enhances the ability to debug network problems.

[0069] Scalability

[0070] STEP allows networks to scale easily and provides insight into the entire network. STEP will also help network administrators easily design and scale existing or new networks and provide insight into service availability across the entire network. In certain exemplary embodiments, there will be two manifestations of STEP, referred to as "internal STEP" or "iSTEP" and "external STEP" or "eSTEP". Internal STEP is the protocol used to exchange services within an organization and is the primary focus of the following description. External STEP is the protocol used to exchange services across organizations and will be briefly discussed in the following description.

[0071] STEP Repository

[0072] Exemplary embodiments of STEP and various network elements for use with STEP are now described.

[0073] As discussed above, STEP routers participating in a STEP-enabled network publish services and topology state information maintained by a STEP server in a STEP repository. For convenience, the services and topology state information published by a given STEP router are referred to herein as STEP documents. In a specific exemplary embodiment, a STEP document is a document encoded in JavaScript Object Notation (JSON), but other mechanisms (e.g., HTML or binary encoded documents) may be used in various alternative embodiments. Service providers may also publish information to the STEP repository, such as announcing service information from their network / institution. The STEP information received by the STEP server from the STEP router, optionally also the STEP information received from the service provider, is selectively distributed to other STEP routers, and is used by the STEP router to intelligently route services to services and also react to network changes.

[0074] In certain exemplary embodiments, the STEP repository is built on an efficient and scalable in-memory database that follows a publish-subscribe model, referred to herein as a path tree database. In exemplary embodiments, the STEP repository / server performs the collection and distribution of service and topology state information, and all routing decisions (clients publish routing data and clients use the data to perform routing, such as shortest path first decisions) are done on the STEP routers, not on the STEP servers. However, in certain alternative embodiments, the STEP repository / server can be configured to make or contribute to routing decisions.

[0075] The path tree database is used to store all data in the STEP repository. As the name implies, each data set has its own path in the path tree database. In an exemplary embodiment, the following path definition format will be used to publish STEP related information from each STEP router:

[0076] / <authority-name> / <district-name> / <router-name> / step= <routerdocument>

[0077] in,

[0078] authority-name: The name of the authority to which the router belongs

[0079] District-name: The name of the area to which the router belongs.

[0080] router-name: The name of the router

[0081] step: a leaf storing the path to the json document

[0082] The following sections explain each area in detail. For now, an area can be viewed as a collection of neighborhoods and a way to divide routers within an organization.

[0083] Each STEP router publishes a set of router documents to the STEP repository. A STEP router can be a member of one or more regions, and each STEP router publishes a router document for each region of which it is a member. Each STEP router typically subscribes to the STEP documents of all other STEP routers in each region of which it is a member. In this way, each STEP router can be aware of the service availability in each region of which it is a member, and can apply algorithms on a per-service basis to determine the available paths for services in the network. Each STEP router runs routing (e.g., SPF) calculations periodically and does not receive any end notifications from the server.

[0084] In an exemplary embodiment, the following types of information will be stored in the STEP repository:

[0085] Service availability within each router

[0086] The peer paths available to each router

[0087] • External routes learned from other routing protocols if distributed into STEP Each of these types of information is discussed in more detail below.

[0088] The STEP repository provides a complete view of the availability of network services at any given time, and can also maintain a history of changes that have occurred in the network over time. This current and historical information can be used, among other things, to debug or fine-tune service policies, for example, to prioritize various services at different times of the day, and can also be used to effectively revert to a previous network state when necessary or desired. Other machine learning algorithms can also be applied to data obtained from the STEP repository to help influence services in the network.

[0089] PathTree Server as STEP Repository

[0090] The Path Tree Database is a lightweight, scalable in-memory subscription data store. It supports a socket-based publisher-subscriber model. Data sets are stored as various paths, and clients can add monitoring on various paths to be notified of changes. Examples are provided below.

[0091] / p1 / p2 / p3 / key="test"

[0092] in,

[0093] / p1 / p2 / p3 / key is the path

[0094] test is the value.

[0095] STEP clients can create paths and can also subscribe to notifications on any path. For example, a client can add a watch on the path / p1 / p2 and it will get notified when anything is created / changed / deleted under the / p1 / p2 path.

[0096] The pathtree client stores the dataset as JSON (although any data encoding may be used). Any further updates to the dataset are sent as JSON patch documents (JSON diffs) as specified in IETF RFC 6902 titled JavaScript Object Notation (JSON) Patch and available at https: / / tools.ietf.org / html / rfc6902, the entire contents of which are incorporated herein by reference. This provides an efficient way to update state and notify observers of the update, rather than sending an entire JSON file. This mechanism should be particularly useful for route change notifications, where only a small number of routes may be announced or withdrawn based on a route change. Therefore, the pathtree client only sends those change notifications.

[0097] The STEP server notifies all subscribers of any changes to the paths they subscribe to. The server preferably also keeps a history of all JSON diff updates to a particular path. These updates are considered network path changes or routing changes. These differences will be periodically combined into a single JSON document (by default this is configured to be 100 differences per path) to allow rolling and aggregation.

[0098] The path tree server is stateless and is not a persistent data storage device. If it is restarted, it will lose all state information, and the client must refill the data storage with the most recent state (i.e., the most recent STEP document).

[0099] In order to maintain the state in the path tree server, a separate path tree client will listen to all paths on the server and store them in a time series database. The path tree client can reside simultaneously with the path tree server, or it can also be remote. The analysis / network client can use the time series database to determine the changes of the network over time. This will be discussed in more detail below.

[0100] STEP Repository / Server Location

[0101] The STEP repository and STEP server can be hosted almost anywhere, but in practice they will reside in one of three locations:

[0102] Conductor

[0103] The STEP server can be located on Conductor. All routers have access to Conductor, which is how routers are initialized and booted. Therefore, in general, Conductor will be the natural (e.g., default) location for the STEP repository. If Conductor access from a router is over a "lossy" network or has high latency, the STEP repository should be hosted on a server close to the router or on the router itself.

[0104] Public servers accessible by all routers

[0105] The STEP server can be located on a separate server from the Conductor. This usually requires secure access from all routers.

[0106] The router itself (e.g., data center)

[0107] In some deployments, connectivity to the Conductor is unreliable and may be unavailable for long periods of time such that the routers will not be able to communicate with each other. In these cases, routing exchanges and forwarding should still be able to function normally without interruption. To achieve this, the STEP repository can reside on a router (usually a hub router) that is accessible to all routers in the domain. It should be noted that the STEP router hosting the STEP repository effectively acts as both a STEP server (for managing the STEP repository) and a STEP client (for transmitting service and topology state information to and for receiving service and topology state information from the STEP repository / server).

[0108] STEP Server and Client Devices

[0109] As discussed above, the STEP repository and STEP server may be implemented in any of various types of devices, such as, for example, a STEP router, a Conductor, or a server separate from the STEP router and the Conductor. Figure 1 1 is a schematic diagram showing the major components of a STEP server 100 according to an exemplary embodiment. Among other things, the STEP server 100 includes a data storage device 110 and a STEP server controller 120. The data storage device 110 includes a volatile memory (herein referred to as a volatile routing repository 111) in which a routing repository is stored and a persistent memory (herein referred to as a persistent history information 112) in which routing repository history STEP information is stored. The STEP server controller 120 typically includes a microcontroller and associated peripherals with software stored in a tangible non-transient computer-readable medium and running on a microprocessor to implement one or more computer processes that perform the STEP server functions described herein. When the STEP server 100 is implemented in a STEP router, the microcontroller on which the STEP server controller 120 is implemented can be the same microcontroller that runs other router functions such as route calculation and packet routing.

[0110] Figure 2 2 is a logic flow diagram of a STEP server controller 120 for implementing advanced STEP server functions according to an exemplary embodiment. In box 202, the STEP server controller 120 maintains a STEP repository in a data store. In box 204, the STEP server controller 120 receives service and topology state information from each STEP router in a plurality of STEP routers using a service and topology exchange protocol. In box 206, the STEP server controller 120 stores the received service and topology state information in the STEP repository. In box 208, the STEP server controller 120 transmits service and topology state information from the STEP repository to each router for at least one other router using the service and topology exchange protocol based on the configured relationships between the routers, so that each STEP router can make routing decisions based at least in part on the service and topology state information from at least one other router.

[0111] As discussed above, the STEP client is implemented in the STEP router. Figure 3 is a schematic diagram showing the major components of a STEP client 300 according to an exemplary embodiment. Among other things, the STEP client 300 includes a data storage device 310 and a STEP client controller 320. The STEP client controller 320 maintains a local STEP repository 311 in the data storage device 310, which is used to store STEP documents received from a STEP server. The STEP client controller 320 typically includes a microcontroller and associated peripherals with software stored in a tangible non-transient computer readable medium and running on a microprocessor to implement one or more computer processes that perform the STEP client functions described herein. The microcontroller on which the STEP client controller 320 is implemented can be the same microcontroller that runs other router functions such as route calculations and packet routing. For STEP, the router typically also includes a STEP enhanced routing engine 340, which uses the STEP information in the local STEP repository 311 and the traditional routing information 313 (e.g., static routes, connection routes, and / or routes from routing protocols such as OSPF or BGP) stored in the data storage device 310 to determine routes for the routing information base 314, according to which the STEP enhanced routing engine 340 routes packets.

[0112] Figure 4 4 is a logic flow diagram of a STEP client controller 220 for implementing advanced STEP client functionality according to an exemplary embodiment. In block 402, the STEP client controller 220 transmits service and topology state information to a STEP server using a service and topology exchange protocol. In block 404, the STEP client controller 220 receives service and topology state information for at least one other router from the STEP server using the service and topology exchange protocol based on configured relationships between routers. In block 406, the STEP client controller 220 stores the received service and topology state information for at least one other router in a local STEP repository for use in making routing decisions.

[0113] As discussed above, both the STEP server 100 and the STEP client 300 may be implemented in a router.

[0114] STEP Repository Redundancy

[0115] In an exemplary embodiment, a path tree server is a non-persistent data storage device. A path tree server can be deployed with multiple instances to increase resiliency. If there are multiple path tree servers, one of the servers will be selected as the primary server and the remaining servers will be secondary servers. In an exemplary embodiment, the selection can be based on the lowest boot timestamp or based on the highest configuration priority, but other selection schemes can be used. Clients connecting to the secondary servers proxy their requests to the primary server. The secondary server repository does not maintain any path tree state in it.

[0116] In the event of a master failure or reboot, one of the slaves will take over the role of master based on a selected scheme (e.g., based on the next lowest startup timestamp or based on the next highest configured priority). Any requests to the old master (now a slave) will be relayed to the new master. If priorities are configured, once the failed master with the highest priority comes back, it will take over as leader again. The new master needs to be repopulated by all routers since it does not have any state saved.

[0117] All STEP servers (primary and secondary) should be able to communicate with each other over L2 or L3 networks. STEP servers can be configured with priorities. In an exemplary embodiment, the highest priority server will be the primary server, and the remaining servers will be secondary servers. The STEP primary server can be configured taking into account the reachability constraints in the network. The next section describes the various locations where STEP servers can reside.

[0118] STEP Repository Configuration

[0119] The STEP repository location(s) and optional priority settings can be configured by the network administrator based on the needs of the network deployment. The data model changes for the STEP repository are given below.

[0120] grouping step-repo

[0121] leaf description

[0122] type string;

[0123]

[0124] The STEP server can be set up by configuring the following two parameters:

[0125] IP address / FQDN

[0126] A STEP server can be identified using an IP address or a fully qualified domain name (FQDN). A STEP server can be a Conductor, a standalone server, or a router itself. If this field matches the IP address / hostname of an interface on a router, then a STEP server will be set up on that router. A STEP service will be generated for each of these IP addresses, and corresponding service routes will be generated for each router so that STEP clients on the router can reach the STEP repository. This will be done by the configuration generator before the configuration is pushed to all routers. More details are provided below.

[0127] Priority

[0128] This is an optional parameter that is very useful in some network deployments. The priority indicates which server should be the primary server in case there are multiple servers. By default, the server with the highest uptime becomes the primary server. However, after priorities are configured, the server with the highest priority becomes the primary server. If it cannot become the primary server, the next highest priority becomes the primary server, and so on. If more than two STEP servers are deployed and some have priorities configured and others do not, the server with the highest priority that is active becomes the primary server. When all servers with configured priorities are unavailable, uptime is used as the discriminator for the remaining servers. This is useful for deployments where the primary server is designated on a node that is reachable from all network elements. This can even be a router (for example, in case of a Conductor or standalone server with a lossy connection).

[0129] STEP Documentation

[0130] In an exemplary embodiment, a STEP document is a JSON document published by each STEP router to the STEP repository. The following protobuf definition illustrates the different fields that make up the JSON.

[0131] syntax="proto3";

[0132] message IpPrefix{

[0133] / *IP address* /

[0134] string ipAddress = 1;

[0135] / * prefix length * /

[0136] int32 prefixLength = 2;

[0137] }

[0138] message ServicePolicy{

[0139] / *Service policy name* /

[0140] string name = 1;

[0141] / * Indicates that the path has an acceptable SLA

[0142] bool hasSla = 2;

[0143] }

[0144] message SlaValues{

[0145] / *Delay in milliseconds* /

[0146] uint32 latency = 1;

[0147] / *Percentage loss* /

[0148] double loss=2;

[0149] / *jitter in milliseconds* /

[0150] uint32 jitter = 3;

[0151] }

[0152] message PeerPath{

[0153] / *Unique name identifying the path to the target 128T peer* /

[0154] string identifier = 1;

[0155] / *Local interface host name* /

[0156] string hostname = 2;

[0157] / *Local interface IP address* /

[0158] string ipAddress = 3;

[0159] / *Target peer name* /

[0160] string peerName=4;

[0161] / *Vector associated with the path* /

[0162] repeated string vector = 5;

[0163] / *SLA value* /

[0164] SlaValues ​​slaValues ​​= 6;

[0165] / *Service strategy list* /

[0166] repeated servicePolicy=7;

[0167] }

[0168] enum RouteSourceType{

[0169] District = 0;

[0170] Authority = 1;

[0171] }

[0172] message RouteSourcePath{

[0173] / *Source type* /

[0174] RouteSourceType sourceType=1;

[0175] / *Source name* /

[0176] string name = 2;

[0177] }

[0178] message ServiceNexthop{

[0179] / * Vector associated with the next hop * /

[0180] repeated string vector = 1;

[0181] / *Region or institution list* /

[0182] repeated RouteSourcePath sourcePath=2;

[0183] }

[0184] message RouteNexthop{

[0185] / *Routing cost associated with the next hop* /

[0186] repeated int32 cost=1;

[0187] / *Region or institution list* /

[0188] repeated RouteSourcePath sourcePath;

[0189] }

[0190] message ServiceRoute{

[0191] / *Name of the configured service route* /

[0192] string name = 1;

[0193] / *Next hop list* /

[0194] repeated ServiceNexthop nexthop=2;

[0195] }

[0196] message Route{

[0197] / *IP prefix associated with the service* /

[0198] IpPrefix ip_prefix=1;

[0199] / *Next hop associated with the route* /

[0200] repeated RouteNexthop routeNexthop=2;

[0201] }

[0202] message ActivePeerPath{

[0203] / * Unique name identifying the active path to the target 128T peer * /

[0204] string identifier = 1;

[0205] }

[0206] message Service{

[0207] / *Service Name* /

[0208] string name = 1;

[0209]

[0210] / *Distribute to external routes in Step* /

[0211] repeated ExternalRoute externalRoute=4;

[0212] / *InterConnect indicating the path between nodes* /

[0213] Repeated string interconnect=5;

[0214] }

[0215] message Router{

[0216] / *Router name* /

[0217] string name = 1;

[0218] / *Nodes in the router* /

[0219] Repeated Node nodes=2;

[0220] }

[0221] The above protobuf definition provides a way for third-party routers to interact with the STEP router by publishing their router documents as JSON documents. Protobuf has accessors to get / set values, and they can be converted to / from JSON. The following is an example JSON representation of a document:

[0222] {

[0223] name:"EastRouter"

[0224] nodes:[{

[0225] name:"node1",

[0226] peerPaths:[

[0227] {

[0228] identifier:"peer1+3.5.6.7+node1+intf1+vlan0",

[0229] hostname:"EastRouter.node1.intf",

[0230] peerName:"peer1",

[0231] vector:["broadband","mpls"],

[0232] service-policy:[{

[0233] name:"test",

[0234]

[0235]

[0236]

[0237] The STEP document has the following fields which will be populated by each network element.

[0238] 1. Router

[0239] A router is a top level entity, which contains one or more nodes. Each STEP document belongs to a router. A router can have one or more nodes connected via an interconnect (backplane).

[0240] 2. Node

[0241] Each node lists services, peer paths reachable from that node, service availability, external routes distributed by other protocols, and available interconnections between multiple nodes. The presence of interconnections will be used to determine the reachability of service routes between nodes. If interconnections are absent from the document, this indicates that the path between the nodes is down, and some services hosted by (multiple) other nodes will not be accessible via "that" node. Service reachability will not take into account any peer paths (not present in the document) via down nodes.

[0242] 3. Services

[0243] The services section identifies all the services that each router is advertising. A router advertises a service if a route matches a configured service prefix or if a route for a configured service exists. In short, a service entry for a router essentially means that the router can provide that service.

[0244] A service is advertised with a prefix and a next hop. If a prefix has a next hop associated with it, it means the route was learned from a routing protocol and the next hop came from the route. A prefix within a service can be withdrawn if the route contributing to that prefix is ​​withdrawn. The narrower of the configured service prefixes is advertised. For example: If a service is configured with prefix 10.10.10.0 / 24 and the route that gets applied is 10.10.10.1 / 32, then the service will be advertised with the 10.10.10.1 / 32 prefix as it is narrower. Prefixes from routing protocols are applied to services only if the service is distributed to STEP. More details about this are described below.

[0245] Services can also have prefixes without a next hop. These are prefixes obtained directly from the service address configuration, for which service routes are configured. Service routes can be thought of as similar to static routes in that they are explicitly configured, but are service-specific.

[0246] The service routes section indicates the available configured local next hops. This section will only advertise reachable next hops. If the next hop is down, the service routes section will be empty.

[0247] 4. Peer Path

[0248] The peer path indicates all available paths from a given router to each peer. This information can be used to build a graph representing the network topology connections between routers.

[0249] Since SSR routing is service-oriented, peer paths alone do not give a complete picture of service availability. Each service has a service policy associated with it, and each peer path should be within an acceptable SLA. Each peer path has a list of service policies associated with it and indicates whether it is within an acceptable SLA for each policy. Therefore, each service can use this service policy information to determine whether these paths are available for a particular service. In an exemplary embodiment, the service policy for the SLA value includes a configurable hold down timer, and the path must remain within the SLA during this timer before being notified as being within acceptable limits to the STEP server. The router (STEP client) is responsible for adhering to the hold down timer and SLA thresholds to generate its STEP document.

[0250] SLA values ​​are also advertised per peer path. In an exemplary embodiment, each adjacency has a configurable timer value that can be set to periodically update these values. The SLA incorporates the loss, delay, and jitter values ​​of the path. These are typically measured on the router itself every few seconds, but are not updated frequently in the STEP repository to avoid swings (e.g., situations where a router alternately advertises a destination via one route and then another in rapid sequence or alternately advertises as unavailable and then available again, or alternately advertises an interface as closed and then open in rapid succession) and to avoid frequent routing updates that may prevent network convergence. For example, these values ​​can be updated every 5 minutes (as a rolling average), which can be overridden. These values ​​(if advertised) will be incorporated into routing (e.g., SPF) calculations to determine the best path based on the SLA.

[0251] 5. External Routing

[0252] External routes are routes distributed into STEP from some other routing protocol (e.g. BGP routes redistributed into STEP). In this case, the routing protocol is not advertised to any service, only to STEP so that all other routers can learn about this route. These can be redistributed back to BGP at another STEP router.

[0253] Neighborhood

[0254] Neighborhoods are labels applied to network interfaces to indicate network connectivity. When two network interfaces share the same neighborhood, this implies that they have network reachability. Each router can publish neighborhoods as part of a STEP document, including its vector, network interface, and lease information. This can be used to determine peer path connectivity between routers. An example configuration is given below.

[0255]

[0256] In an exemplary embodiment, the neighbors from all router configurations are read by Conductor, and the adjacency configuration is generated by the configuration generation code. The adjacency configuration on each router is used as the available peer paths. These peer paths will be announced as part of the STEP document. This will allow each peer to create a topology map of the entire network on a per-service basis.

[0257] area

[0258] Areas are logical groups of neighborhoods. STEP documents are typically shared between all routers in the same area. Areas do not have strict boundaries, but depend entirely on how the network topology is divided. This section provides examples of how to divide the same network topology into one area or multiple areas.

[0259] Single Region

[0260] Figure 5 is a diagram showing an exemplary topology of a region partitioned into multiple neighborhoods. In this example, the region name is "common" and there is a hub and spoke topology. Routers DC1 and DC2 are hubs. Routers Br1 and Br2 are spokes connected to router DC1. Routers Br3 and Br4 are spokes connected to router DC2. The following neighborhoods are defined:

[0261] 1.N1

[0262] All WAN interfaces of DC1, Br1, and BR2 are in the N1 neighborhood. This neighborhood is part of the "public" zone.

[0263] 2.N2

[0264] All WAN interfaces of DC2, Br3, and BR4 are in the N2 neighborhood. This neighborhood is also part of the "public" zone.

[0265] 3.N3

[0266] The WAN interface reachable between DC1 and DC2 is in neighborhood N3. This neighborhood is also part of the "public" zone.

[0267] In this example, all three areas are defined as part of the same area "Public". This means that all six routers publish their STEP documents to the same path on the STEP server. An example path for publishing documents is shown below:

[0268] <authority-name>:auth128

[0269] / auth128 / common / DC1 / step= <json>

[0270] / auth128 / common / DC2 / step= <json>

[0271] / auth128 / common / Br1 / step= <json>

[0272] / auth128 / common / Br2 / step= <json>

[0273] / auth128 / common / Br3 / step= <json>

[0274] / auth128 / common / Br4 / step= <json>

[0275] Multiple regions

[0276] Figure 6 is with Figure 5 Diagram of the same topology but divided into multiple regions. In this example, there are three regions, specifically region "east" which includes routers DC1, Br1, and Br2; region "west" which includes routers DC2, Br3, and Br4; and region "central" which includes routers DC1 and DC2. Each STEP router publishes its STEP document in its respective path. Figure 6 Example paths for the areas shown in:

[0277] <authority-name>:auth128

[0278] District east

[0279] / auth128 / east / DC1 / step= <json>

[0280] / auth128 / east / Br1 / step= <json>

[0281] / auth128 / east / Br2 / step= <json>

[0282] District west

[0283] / auth128 / west / DC2 / step= <json>

[0284] / auth128 / west / Br3 / step= <json>

[0285] / auth128 / west / Br4 / step= <json>

[0286] District central

[0287] / auth128 / central / DC1 / step= <json>

[0288] / auth128 / central / DC2 / step= <json>

[0289] As can be seen, router DC1 publishes its STEP documents in both the "East" and "Central" regions, and router DC2 also publishes its STEP documents in both the "West" and "Central" regions. Routers Br1 and Br2 peer with router DC1 only in the "East" region, so routers Br1 and Br2 only publish their STEP documents in the "East" region because their network topology and service availability do not need to be exposed to other regions on a per-branch basis. Similarly, routers Br3 and Br4 peer with router DC2 only in the "West" region, so routers Br3 and Br4 only publish their STEP documents in the "West" region because their network topology and service availability do not need to be exposed to other regions on a per-branch basis. If all branches were connected as a full mesh, then each branch router would need to know the service availability and reachability to every other branch, but this is not the case here. In this example, router DC1 can effectively hide all of its branches from router DC2, and vice versa.

[0290] In an exemplary embodiment, each router that is part of multiple areas will aggregate the services and routing information from one area and advertise it to another area. Therefore, the STEP documents for the same router on two different areas will look different. Additional details on how services are exchanged between areas are provided below.

[0291] Regional Configuration

[0292] According to an exemplary embodiment, the following are the data model changes required to configure a region. A region is an institutional-level container that contains a list of neighborhoods. Each neighborhood can have a list of regions associated with it.

[0293]

[0294] Default Region

[0295] In an exemplary embodiment, associating a neighborhood with a region is optional. When a neighborhood is not explicitly associated with a region, it is assigned the region "default region". This way, if the topology only requires a single region, there is no need to configure regions. Figure 5 In the topology described, if all neighbors were configured to have no regions instead of having region "public", then the pathTree server would have the following paths.

[0296] <authority-name>:auth128

[0297] / auth128 / default-district / DC1 / step= <json>

[0298] / auth128 / default-district / DC2 / step= <json>

[0299] / auth128 / default-district / Br1 / step= <json>

[0300] / auth128 / default-district / Br2 / step= <json>

[0301] / auth128 / default-district / Br3 / step= <json>

[0302] / auth128 / default-district / Br4 / step= <json>

[0303] In one exemplary embodiment, the following rules are used when configuring neighborhoods and regions:

[0304] If router R1 has one interface with neighbor N1 in area D1, and has another interface with no neighbor configured, then R1 will only publish router documents under area D1. It will not publish documents under the "default area".

[0305] If router R1 has one interface in neighborhood N1 in area D1 and another interface in another neighborhood N2 which is not part of any area, then R1 will publish the STEP document under D1 and "default area".

[0306] If router R1 does not have adjacencies configured on any of its interfaces, it will not publish any STEP documents.

[0307] Route calculation using STEP

[0308] The route (e.g., SPF) calculations are run on demand on the router using holddown timers, e.g., if there are any updates from the STEP repository (including local changes), then it will be scheduled to recalculate the path after a predetermined amount of time (e.g., five seconds). This generates service-based routes and next hops. These are pushed down to the routing agent to set up the forwarding information base (FIB) entries. The triggering of the timer indicates when the path is calculated, and there is no end notification from the server.

[0309] Once the router reads all STEP documents, it will run its routing algorithm (e.g., SPF via Dijkstra's algorithm) on all available paths advertised by other routers on a per-service basis. In some cases, this will be run on each service prefix if each service prefix has a different next hop (which may be the case when prefixes are assigned to services from other protocols).

[0310] The cost of each path is published in the STEP document and the service policy associated with each service can be obtained from the configuration (config). Based on this, the logical network topology is different for each service. SPF calculates the best path and the backup loop-free path for each service. In case the primary path is unavailable, the backup path will be used as a backup.

[0311] SLA values ​​are advertised periodically per peer path. The time for these updates can be configured per adjacency. Each peer path advertised also indicates whether the SLA is met per service policy. Service policies will have a path inhibition timer field that can be configured to control these updates. The following are example data model changes for path SLA updates: Data Model Changes for Path SLA Updates

[0312]

[0313] Data model changes for SLA throttling timers

[0314]

[0315] Service Exchange

[0316] In an exemplary embodiment, the following types of services are available on the router:

[0317] a) A wide range of services provided by the institution.

[0318] b) Local services that are local to a router or shared among N routers.

[0319] c) Hosted Services, for services hosted by a router for local access.

[0320] d) Router-local application identification service.

[0321] In an exemplary embodiment, among these service types, STEP only advertises the following services in the STEP document:

[0322] a) A wide range of services provided by the institution.

[0323] b) Local services shared between more than one router. If the service is local to the router, it will not be advertised.

[0324] The other two types of services are only relevant locally to the router and are therefore not published in the STEP document in the exemplary embodiment.

[0325] Figure 7 is a schematic diagram showing a topology including two routers that are peers to each other. In this example, router R2 has a service route for service S1, and there are two peer paths between routers R1 and R2. For example, consider service S1 is configured with prefix 1.2.3.0 / 24 and has a service-route on router R2.

[0326] Router R1

[0327] Get service S1 via configuration

[0328] There is no route matching service prefix S1

[0329] ·Has two peer paths

[0330] Router R1 does not have any service to advertise because it has no matching routes for that service and has not been configured with any service next hops. Therefore, the following is a sample STEP document for router R1:

[0331]

[0332] From the STEP document above, Router R1 does not advertise any services. However, it does have a peer path to the east router R2.

[0333] Router R2

[0334] Get service S1 via configuration

[0335] There is no route matching service prefix S1

[0336] • The local service route on node N1 is learned via configuration.

[0337] With two peer paths The following is a sample STEP document for router R2:

[0338]

[0339]

[0340] For router R2, service S1 is advertised as part of a STEP document with a service-route. This simply means that service S1 is available on router R2. When router R1 receives the STEP document from router R2, it finds that service S1 is available on router R2, and since the peer path is above the SLA, it will establish a service topology from router R1 to router R2 for service S1. When router R2 receives the STEP document from router R1, it finds that no service is being advertised. Therefore, the only next hop for service S1 will be the service route configured on router R2. The above example indicates how services can be exchanged between multiple routers in the same area.

[0341] Removal of router

[0342] A router may become unavailable due to any of a variety of reasons, such as, for example, a router failure, unavailability or poor communication connectivity to the router, a network administrator shutting down the router, or removing the router from the network configuration (e.g., by notification to a STEP server). This unavailability may be communicated to the STEP repository, and from there propagated to other routers that have subscribed to updates for the now unavailable router. For example, if a router fails or shuts down, or communication to the router is interrupted, the router may stop communicating with the STEP server / repository, in which case the STEP server may (after attempting to reestablish communication with the server for a predetermined number of times) update the STEP repository to indicate that the router is unavailable, such as by removing the state information of the router from the STEP repository or by updating the state information of the router to indicate unavailability. Similarly, if a router is removed from the network configuration, the STEP server may update the STEP repository to indicate that the router is unavailable, such as by removing the state information of the router from the STEP repository or by updating the state information of the router to indicate unavailability. In any case, the STEP server may immediately notify other routers that have subscribed to updates of the now unavailable router that the router is now unavailable, in which case these other routers may recalculate one or more routes to avoid the now unavailable router.

[0343] Redistribute the protocol into STEP

[0344] STEP routers often need to interact with other routing protocols (such as BGP, OSPF, etc.) to learn routes. STEP routers have the unique ability to selectively distribute these routes to STEP instead of running these protocols in the core. In a specific exemplary embodiment, the following routing protocols can be distributed to STEP:

[0345] a) BGP

[0346] b) OSPF

[0347] c) Static

[0348] d) Connected

[0349] The following is a sample configuration for distributing routing protocols into STEP:

[0350]

[0351]

[0352] uses redistribution;

[0353] }

[0354] }

[0355] This can be extended in the future to apply filtering policies on communities, peer groups, etc. to filter routes at a more granular level. In an exemplary embodiment, there are two ways to redistribute these routes into STEP:

[0356] a) Redistribute to the service of your choice

[0357] b) Redistribute as an external route

[0358] Redistribute the protocol into a service

[0359] Figure 8 is a diagram of an example of redistributing BGP into services. In this example, router R1 is peered with router R2, and router R2 establishes BGP peering with a non-STEP router (R3). Consider the following example configuration on router R2, where BGP is redistributed into service S1 via STEP:

[0360] Step

[0361] name:"step1"

[0362] redistribute

[0363] protocol:bgp

[0364] service:[{"S1"}]

[0365] Now, consider the same service S1 as in the previous example, with the same prefix 1.2.3.0 / 24. In this case, S1 has no traffic routes configured. The idea is to learn routes from BGP and redistribute them into service S1. For this example, assume that only one route is learned via BGP, specifically, route 1.2.3.4 / 32.

[0366] Router R1

[0367] Get service S1 via configuration

[0368] There is no route matching service prefix S1

[0369] ·Has two peer paths

[0370] Router R1 does not have any service to advertise because it has no matching routes for that service and has no service next hop configured. The following is a sample STEP document for router R1:

[0371]

[0372] From the above STEP document, it is clear that router R1 is not advertising any services. It has a peer path to the east router.

[0373] Router R2

[0374] Get service S1 via configuration

[0375] There is a BGP route matching service prefix S1. The narrower prefix is ​​advertised.

[0376] ·Has two peer paths

[0377] The following is a sample STEP document for router R2:

[0378]

[0379]

[0380] The next hop is provided as a cost. Since conventional routing protocols are not aware of vectors, the cost of the route is used directly. This cost will be used when calculating the best path and the vector magnitude on each path. In an exemplary embodiment, the AS path length is converted to a cost by multiplying the number of ASs in the path by a constant (e.g., 10), and the cost will be announced in the next hop. The AS path can also be announced in the document so that it can be propagated for future shipping situations.

[0381] For router R2, service S1 is advertised as part of a STEP document with a narrower prefix and with a next hop. This means that service S1 is available on router R2. Router R2 publishes service S1 as part of its router document because:

[0382] BGP is redistributed into service S1 in router R2

[0383] Routes learned from BGP are a subset of the service prefix

[0384] The same can be done for the other protocols listed in the enumeration, namely static, link, and OSPF.

[0385] Redistribute the protocol as external routes

[0386] With this option, routes learned from BGP will be distributed into STEP as external routes. One use case where this option is useful is to advertise connected routes to a peer router into BGP, where these routes are used as reverse routes for downstream non-SSRs. However, this is not considered the normal mode of operation and should be the least preferred way of advertising routes, as STEP is not considered a protocol for carrying traditional routes across a network.

[0387] Fig. 9 is a diagram of an example of redistributing BGP into STEP. In this example, router R2 learns routes via BGP by establishing a peer relationship with another router R3. In this case, router R2 is configured to distribute BGP into STEP. In this example, these routes are not distributed into services. This is an important difference from the previous example where routes were distributed into services. Consider this configuration on router R2, where BGP is redistributed into STEP:

[0388]

[0389] In this case, the route appears in the external routes section of the STEP document for router R2. Note that router R2 no longer advertises service S1 because there is no matching route for that service.

[0390] Router R2

[0391] Get service S1 via configuration

[0392] There is no route matching service prefix S1 because BGP is not distributed into the S1 service

[0393] Has external routes because BGP is distributed into STEP

[0394] ·Has two peer paths

[0395] The following is a sample STEP document for router R2:

[0396]

[0397]

[0398] The protocol section in the external routes section indicates which protocol is distributed into STEP. The document indicates that route 1.2.3.4 / 32 from BGP is distributed into STEP. This does not mean that this route is distributed back to another protocol on router R1. The presence of this route does not affect any services because it is not applied to any services. In certain exemplary embodiments, the only way these routes can be used is if one of the peers distributes these external routes back into BGP. Additional details on this are provided below.

[0399] Redistribute STEP into BGP

[0400] Each router can learn services and routes from the STEP repository and redistribute them back into BGP. The redistribution can be more granular at the service level, where a set of services can be redistributed. Some example data model changes for this are shown below, highlighted in bold.

[0401] This extension to the existing configuration provides a list of services that can be distributed into BGP. By default, using service enumeration, all services are redistributed into BGP.

[0402] New enumeration in BGP redistribution

[0403]

[0404]

[0405] Enhanced BGP routing policy configuration

[0406]

[0407]

[0408]

[0409] The "step" enumeration within the protocol identifies all external routes learned via STEP. These are routes that do not match any service but are distributed into STEP via other protocols (e.g. BGP, connected, static, etc.).

[0410] The "services" enumeration distributes all service prefixes learned from other routers into BGP if they exist in the router document, and withdraws them if they do not. The redistribute command has been extended to provide a list of services that can be distributed into BGP in case not all service prefixes need to be exposed. This gives each router more control over the services it chooses to advertise into BGP.

[0411] Multicast Services

[0412] Multicast has many applications where a source needs to copy packets to one or more receivers. Currently, SSR supports unicast services, which are delivered to one destination. Unicast services do not take into account multicast protocols such as the IGMP protocol, which are used to indicate which receivers are interested in a multicast group.

[0413] The access policy requirements for multicast services are also different from those for unicast services. Unicast services typically have access policies only for the source, while multicast services will benefit from access policies for both the source and the receiver on a per-service basis.

[0414] A service with a multicast IP address is a multicast service. A multicast service replicates packets to multiple endpoint destinations. The destinations can be local to a router or to a peer router. The following is an example of a multicast service definition according to an exemplary embodiment:

[0415]

[0416] Here, a multicast service named "mcast" is associated with the multicast address 233.252.0.2. It also has an access policy that allows tenants named "blue" and a sender policy that allows tenants named "red". It is important to understand these terms because they are different from the unicast world.

[0417] The access policy field indicates which receivers are allowed to accept packets from this multicast service. This is different from the way unicast services use access policies. Unicast services use access policies for the originator of the packet (i.e., whether the source can access the service). However, for multicast services, it is the access policy for the receivers.

[0418] The access policy ensures that IGMP packets are received only from allowed receiver tenants on the service. The multicast address indicates the multicast group. The multicast receivers can be learned dynamically via the IGMP protocol.

[0419] In the example above, the access policy allows receivers that are classified as tenant "blue". Here, the router will accept IGMP joins from any interface on which the tenant "blue" is configured. IGMPv2 Membership Query messages for the 233.252.0.2 group are sent out from all interfaces that have access to the multicast service. Any interface on the router with a tenant that does not have access to the service will drop all IGMP Membership Report messages received for the multicast group. Thus, multicast services can impose access controls on receivers.

[0420] The multicast-sender-policy indicates which sources are allowed to send packets to the multicast service. Some exemplary data model changes for multicast-sender-policy are shown below:

[0421]

[0422] Any multicast service requires a source that generates multicast packets. The sender policy imposes access policies on the sender. In the example above, the sender policy allows tenant "red". This means that if the source is classified as tenant "red", the source is allowed to send packets to this multicast group.

[0423] In an exemplary embodiment, a multicast listener can be configured on an interface. By default, the receiver (also referred to as a listener) will be set based on the tenant-based access policy that matches the interface tenant. However, there may be situations where this needs to be overridden on a per-interface basis. The following is an example configuration definition for configuring a multicast listener in an exemplary embodiment:

[0424]

[0425] The multicast listener configuration can be used to override the current service access policy. It can be used to enable a receiver to join any multicast service using the enable tag. It can also be used to disable listeners on an interface even if the multicast service allows them via the access policy. Due to the wide organizational range of tenants in the exemplary embodiment, this will provide more fine-grained control over receivers in the case of outliers within some routers.

[0426] In an exemplary embodiment, there are two different deployment use cases for multicast services, namely point-to-multipoint SVR and multicast proxy.

[0427] For point-to-multipoint SVR, the SVR path refers to the secure vector route between two routers, which is point-to-point for unicast services in the exemplary embodiment. But for multicast services, the router copies the sourced packet to all other routers that have receivers on it. Hence, it is called point-to-multipoint SVR. Fig.21 In the example, the data center has a multicast server behind the SSR router, which will be the source of the multicast service. Each branch - branch 1 and branch 2 has two multicast clients, each of which is a receiver. Consider the same service "mcast" defined in the example above, with a multicast address of 233.252.0.2. Each multicast client will send an IGMP join message to the branch router for the multicast group 233.252.0.2. Therefore, each branch router will register two receivers for this group. The source packet originated at the data center needs to be sent to both branches.

[0428] In a STEP environment, all STEP routers, including any STEP routers in a PIM (Protocol Independent Multicast) cloud, can obtain information about a multicast service and determine which router(s) and paths will be used to distribute source packets. Specifically, each participating router advertises any multicast source(s) and / or multicast receiver(s) associated with the router, and the router can make routing decisions based on the advertised information (such as selecting the best "rendezvous point" router(s) in the network, e.g., the minimum tree required to distribute the multicast packets). For example, a router associated with one or more multicast receivers (referred to herein as a multicast receiver router) will announce that it is a multicast receiver router along with information about the multicast receivers. However, multicast services of the type described herein can be supported in a non-STEP environment, for example, by setting up service routes for each of these branch routers on a data center. The following is Fig. 22 An example service routing configuration for the network configuration shown in:

[0429] Service Routing

[0430] Name: branch1_service_route

[0431] Service: mcast

[0432] Peers: Branch 1

[0433] Service Routing

[0434] Name: branch2_service_route

[0435] Service: mcast

[0436] Peer: Branch 2

[0437] With the above configuration, any packet sent by the multicast server to the multicast group 233.252.0.2 will be forwarded to each branch router via the SVR path. It is important to understand that the SVR path mentioned here is a unicast path rather than a multicast. In an exemplary embodiment, a multicast packet from a source will be sent to each branch as a unicast packet, using network address translation (NAT) to convert the SVRIP address and port of each path and carry the original SVRIP address and port in the metadata field in the packet. At the branch, the metadata will be used to find the multicast service and send the packet to all receivers associated with it. It should be noted that after the branch router receives the unicast packet with metadata, the branch router can establish an association between the converted address / port number and the original address / port number in the metadata for processing future packets associated with the multicast service, and thereafter, the source can stop sending the metadata in subsequent packets to the branch router in order to reduce the overhead caused by the metadata. It is also important to note that in the above example, the head-end (source) router replicates the packet to all other routers, and there is no multicast tree used for such packet distribution, and as more branch routers are added, the head-end replication may become too inefficient. Therefore, in order to scale more efficiently, the exemplary embodiment can make the multicast stream join an existing multicast tree downstream or have a replication endpoint that can replicate to other endpoints.

[0438] For multicast proxy, a router can deliver multicast services by joining an existing multicast tree and "proxying" packets between unicast and multicast. For example, referring again to the "mcast" service with address 233.252.0.2 Fig. 22 , the data center can send multicast packets to the intermediate PIM network, where the PIM network is aware of the multicast group (e.g., in an exemplary embodiment, the PIM network needs to know the actual multicast service IP address being replicated and does not support multicast address translation). This is different from the point-to-multipoint SVR environment discussed above in that the data center router transmits multicast packets instead of unicast packets, and packets for unicast transmission do not have to be replicated to multiple branches, that is, only one copy of the source packet needs to be transmitted to the PIM network. Therefore, this scheme is more scalable than the point-to-multipoint SVR scheme.

[0439] It should be noted that SSR supports encryption for point-to-point SVR paths, and can therefore easily provide encryption in a point-to-multipoint SVR scenario. Providing encryption in a multicast proxy scenario is more complex because there are multiple receivers, but for example a set of common encryption keys can be distributed to all receivers so that source packets can be encrypted for all receivers at once.

[0440] The functionality of the spoke router is the same as that of a point-to-multipoint deployment for interfaces with multicast listeners enabled. It receives IGMP reports from interfaces that allow multicast listeners. The main difference here is that the spoke router needs to forward these reports to the PIM network. To achieve this, the interface can be configured to act as a multicast report proxy (e.g., the tenant of the interface with PIM proxy enabled should be allowed in the multicast sender policy list). This will cause the spoke router to join the PIM network for multicast group 233.252.0.2 and will begin receiving multicast packets from the data center. These packets will in turn be forwarded to the multicast receivers.

[0441] The following is an example data model for setting up an interface as a multicast proxy:

[0442]

[0443] Here, when the interface is configured for multicast report proxy, it will forward all multicast reports received from any other network interface that has multicast listeners enabled.

[0444] In an exemplary embodiment, the IGMP join will be listed in a display of the routing information base, for example, as follows:

[0445]

[0446] Multicast support in STEP

[0447] In an exemplary embodiment, a multicast service operates largely like any other service, except that it is advertised by a router only when a multicast (eg, IGMP) join is received for a configured multicast address.

[0448] Fig.10 is a schematic diagram showing a topology including a multicast configuration with no receivers. In this example, router R1 is the source. Routers R2 and R3 are both potential receivers. Initially, there are no receivers on routers R2 and R3, and therefore neither router R2 nor router R3 will advertise a multicast service. As a result, router R1 cannot find a service route for the service, and therefore will not forward packets. The source packets will be dropped at router R1.

[0449] STEP helps in dynamically discovering multicast receivers for a particular service. There is no PIM or legacy protocols running in the core. Receivers are just discovered as part of the multicast service like any other service.

[0450] Fig.11 It shows Fig.10 Figure 1 shows the topology of Router R2 but now Router R2 has received IGMP Joins on both of its interfaces. Router R2 will now advertise the multicast address with two service routes. There are two service routes because there are two interfaces from which the IGMP Join was received. This is similar to receiving a route from another routing protocol or a new service route being configured. If Router R2 receives IGMP Leaves from all receivers, it will stop advertising the service. Since R2 will be advertising a multicast service, the following is a sample STEP document for Router R2:

[0451]

[0452]

[0453] Here, router R1 will discover via STEP that service S1 is available on router R2, and therefore it sends all multicast traffic from the source to router R2, which in turn forwards the packets to all receivers.

[0454] Exchange of services between regions

[0455] A STEP router publishes a router document for each area it is a member of. In the case where a router is part of more than one area, the routes and services learned from one area will be aggregated and published to another area where it is the next hop (i.e. a router in one area will not publish all the other peer information it has learned to another area). In this way, routers in one area will be hidden from another area. This helps to better segment the network because all routers do not need to know about all other routers in the network.

[0456] Fig.12 is with Figure 6 Diagram of the same topology. In this example, there are three zones, specifically the zone named "east" which includes routers DC1, Br1, and Br2; the zone named "west" which includes routers DC2, Br3, and Br4; and the zone named "central" which includes routers DC1 and DC2. Therefore, routers DC1 and DC2 are part of two zones.

[0457] Consider service S1 is published by router Br1 in region "East" and service S2 is published by router Br3 in region "West". Branches Br1 and Br2 will not discover service S2, and branches Br3 and BR4 will not discover service S1. However, since routers DC1 and DC2 share the same region "Central", services from region "East" can be known by Br3 and Br4, and vice versa.

[0458] The STEP document published by DC1 in zone "China" will have service S1, but with a local next hop and cost. The cost here is the total cost of the vector to reach service S1 on branch Br1. Router DC2 performs similar operations for service S1.

[0459] The following is an example STEP document for each of these routers: Router Br1

[0460] Get service S1 and service routing for S1 via configuration

[0461] Release service S1 to region "East"

[0462]

[0463] Router Br3

[0464] Get service S2 and the service route for S2 via configuration Publish service S2 to region "West"

[0465]

[0466] Router DC1

[0467] Learn about service S2 from DC2 via zone "China"

[0468] Publish the learned service S2 to region "East" at the associated cost

[0469] Publish service S1 to region "center"

[0470] The peer topology between regions is not exposed.

[0471] Publish the DC1 document in the region "East"

[0472]

[0473] Publish the DC1 document in the zone "Medium"

[0474]

[0475]

[0476] Router DC3

[0477] · Learn about service S1 from DC2 via zone "China"

[0478] Publish the learned service S1 to region "West" at the associated cost

[0479] Publish service S2 to region "center"

[0480] No peer topology is exposed between regions

[0481] Publish the DC2 document in the region "West"

[0482]

[0483]

[0484] Publish the DC2 document in the zone "China"

[0485]

[0486]

[0487] There is no STEP document for routers Br2 and Br4 because they do not advertise any services.

[0488] The above example illustrates how services are learned and advertised between regions. It is possible to learn about the same service S1 from region "West" via DC2. This simply means that service S1 is also available in region "West". To all routers in region "East", it will appear as just another next hop on DC1.

[0489] Fig.18 is a logic flow chart for publishing aggregated routes or services according to an exemplary embodiment. In block 1902, a first router receives service and topology state information for at least one other router. In block 1904, the first router uses the received service and topology state information to identify a route or service from another router, and the route or service for the other router is available for access by the second router through the first router. In block 1906, the first router calculates an aggregate metric for the route or service available through the first router. In block 1908, the first router publishes the route or service including the aggregate metric and uses the first router as the next hop of the published route or service. In certain exemplary embodiments, the first router publishes the route or service by transmitting the route or service to a central repository, which is configured to communicate the route or service to the second router. As discussed herein, the first router may be a member of a first area and a second area, the second router may be a member of the second area, the first router may receive service and topology state information from at least one other router in the first area, and the first router may publish the route or service to the second router in the second area in a manner that hides information related to the route or service from the first area from the second router.

[0490] Loop prevention with STEP

[0491] The exchange of services between areas can cause one area to relearn what it advertised to another area, which can result in routing loops. Fig.13 is a schematic diagram of a topology including service exchange between areas that causes loops. In this example, router R2 hosts service route SR1 for service S1 and advertises it to router R3. Router R3 in turn advertises it to router R2 located in area "West". Router R3 then advertises it back to router R2. Therefore, when router R2 receives an update from router R1, it will think that there is another path available for service S1 via router R1, when in fact router R2 has received its own advertisement. The same situation can also occur in the direction from router R2 to router R1. In that case, router R2 will receive an update from router R3. This causes a loop in the network.

[0492] To prevent loops, the router source path is appended to each route advertised into another area. The loop prevention algorithm is as follows:

[0493] Each router that publishes aggregated routes and services from one area to another will append the area name as part of the next hop, which is where the services / routes are aggregated from. Since services are distributed throughout the network, the area path will be appended to the next hop.

[0494] If a router receives a service prefix / route with an area in the source path, and the router is a member of that area, the router shall ignore that prefix / next hop.

[0495] This will ensure that the same service prefix advertised by one zone will not be returned to itself via another zone.

[0496] Fig.14 It shows Fig.13 A schematic diagram of a topology that does not include service exchange between areas with loop avoidance. In this example, router R2 has a service route SR1 for service S1 in area "South". The following occurs:

[0497] R2 advertises S1 in region "middle", appending the region "south" from which SR1 was learned. The source path list will have [south]

[0498] R3 advertises S1 in region "west", adding the region "central" from which SR1 was learned. The source path list will have [south,central]

[0499] R1 advertises S1 in region "east", and additionally region "west" from which SR1 was learned. The source path list will have [south,central,west]

[0500] R2 learns about service S1 from area "East" and finds that area "South" to which it belongs is already in the advertised service route and will therefore ignore it. This avoids loops.

[0501] Fig.19 is a logic flow diagram for loop detection and prevention according to an exemplary embodiment. In block 2002, a given router in a first area publishes a first route or service from a first area to a second area by transmitting a first publication including the first route or service and a first source path for the first route or service, wherein the first area name is included in the first source path. In block 2004, the given router receives a publication of a second route or service from another area including a second source path. In block 2006, the given router determines whether the second source includes the first area name. In block 2008, when the second source path does not include the first area name, the given router processes the second route or service as a newly learned route or service in the first area. In block 2010, when the second source path does include the first area name, the given router ignores the second route or service.

[0502] Source-based routing using STEP

[0503] STEP will support the use of source-based routing to route packets in the network. In source-based routing, the source router of a packet or a group of related packets (such as for TCP or other communication sessions) determines the path that the packet will take based on its routing algorithm, taking into account the service and topology state information received for one or more other routers via STEP. The source router includes a metadata field in the packet (or usually in the first packet of the session), wherein the metadata field specifies the router through which (multiple) packets are carried, for example, in the form of a router list. Each router on the path (referred to as a "waypoint" router in this article) checks the metadata to identify the next expected router on the path, and modifies the packet to forward the packet to the next expected router-for example, by modifying the destination address of the packet to the address of the next expected router. The waypoint router also typically modifies the source address of the packet to the address of the waypoint router itself, and can modify other fields of the packet, such as the source port, destination port, and protocol field. The original source and destination address information for the session may also be carried in the packet as a meta-packet so that each waypoint router can associate the packet with a particular session and so that the final router along the path can restore the source and destination address information in the packet back to the original source and destination address information. These operations are described, for example, in related U.S. Patent Application No. 14 / 833,571 (now issued U.S. Patent No. 9,762,485), which is incorporated by reference above, but it should be noted that for source-based routing, the intermediate waypoint routers are not required to select the next waypoint router, but rather the next waypoint router is obtained from the metadata in the received packet. As part of this process, the waypoint router may remove itself from the list of routers in the packet metadata so that only any remaining waypoint routers along the intended path remain in the list of routers, but this is not technically required (and, in some embodiments, the waypoint router may be excluded from the list of routers because the waypoint router is implicitly included in the path by virtue of receiving the packet). Each waypoint router also typically establishes forward (and optionally, reverse) association information to associate the session packet(s) with the specified path so that subsequent packets associated with the session can be identified and forwarded along the specified path, which packets typically do not include metadata fields. The last waypoint router on the path forwards the packet to its intended destination, typically also removing the metadata fields from the packet and restoring the original source and destination addresses for the packet. Subsequent packets associated with the session traverse the waypoint routers based on the forward (and optionally reverse) association information.Examples of such forward and reverse association information and packet forwarding based on the forward and reverse association information are described in related US Patent Application No. 14 / 833,571 (now issued US Patent No. 9,762,485), which is incorporated by reference above.

[0504] Split routing is very powerful and can be interoperable across heterogeneous networks. STEP goes a step further in providing service level routing separation (i.e., not all paths are available to all routers on a per-service basis). One router's view of service path availability may be different from the advertising router's view of service path availability. Therefore, in an exemplary embodiment, the list of routers picked by the source router must be followed by other routers.

[0505] Fig.15 is a schematic diagram of a topology including source-based routing within the same region. In this example, router R1 determines that the path to be traversed for service S1 is via R2 and R4. Router R1 adds R2 and R4 to the router list in its metadata. There is a path from router R2 to router R4 via router R3, but since router R2 checks the metadata in the packet, it will comply with the router list and forward the packet to R4 instead of R3. It should be noted that the router list sent by router R1 can exclude router R2 because router R1 sends packets to router R2, so including router R2 in the router list can be considered redundant. Similarly, the router list sent by router R2 can exclude router R4 because router R2 sends packets to router R4, so including router R4 in the router list can be considered redundant. Alternatively, assuming that a router never appears twice in a router list, the router list can remain intact as the packet propagates from router to router, and each router only needs to check its own router list and then identify the next router (if any) to receive the packet.

[0506] Fig.15 is a simple example showing how source-based routing works in an exemplary embodiment. Without source-based routing, R2 would make an independent routing decision, which could send the packet to R3, and R3 could send the packet back to R1. Therefore, source-based routing can help with loop prevention.

[0507] In an exemplary embodiment, when access to a route or service spans multiple zones, the list of routers in the metadata does not cross zone boundaries. Fig.16 is a schematic diagram showing a topology including source-based routing across multiple regions. In this example, router R1 determines that the path traversed for service S1 in region "East" is via router R2. Therefore, router R1 sends a packet with a router list (R2) to router R2 in region "East". Router R2 pops itself out of the metadata, determines a path to router R3 via router R4 in region "West", adds a new router list (R4, R3) based on its calculated path to the final destination in region "West", and forwards the packet with the new router list to router R4. Router R4 removes itself from the metadata and passes to router R3 on (R3) in the router list. Router R3 removes itself from the router list and, seeing that it is the last router in the list, sends the packet to the final destination. Here, the router list in the metadata does not cross region boundaries. Each router will only route packets between routers in the same region. When a packet crosses regions, a new router list is added to continue source-based routing if needed.

[0508] It should be noted that the metadata treatment is backward compatible. Any existing router will ignore the new metadata field and will operate as it does today. If a packet arrives without the router list metadata (e.g. from a non-STEP enabled router), any packet received in a new STEP enabled router will forward the packet to the next available destination.

[0509] Fig. 20 21 is a logic flow chart of source-based routing according to an exemplary embodiment. In box 2102, a source router determines a path for a route or service, which includes an ordered list of consecutive routers to receive packets associated with the route or service starting from a first consecutive router and ending with a destination router. In box 2104, the source router transmits a packet with a metadata field to the first consecutive router, and the metadata field includes a list of at least one remaining router in the ordered list of routers to receive packets associated with the route or service. In box 2106, starting from the first consecutive router, each consecutive router determines whether the router is a destination router, and if the router is not a destination router, the packet is forwarded to the next consecutive router in the ordered list of routers. The source router can be configured to include the first consecutive router in the metadata field or exclude the first consecutive router from the metadata field. Each consecutive router can be configured to remove itself from the metadata field before forwarding the packet to the next consecutive router. Each consecutive router can be configured to forward the packet to the next consecutive packet by changing the destination address of the packet to the address of the next consecutive router and optionally also changing the source address of the packet to the address of the router. The destination router may be configured to remove the metadata field from the packet and forward the packet to the destination. Alternatively, the destination router may be configured to determine a second path to the destination for the route or service, the second path comprising a second ordered list of consecutive routers to receive packets associated with the route or service, and for transmitting the packet, the new metadata field comprises a list of at least one remaining router in the second ordered list of routers to receive packets associated with the route or service.

[0510] Note that source-based routing can be used in one area but not in another. Fig.16 , router R1 may use source-based routing in region "East", while router R2 may use a different routing scheme (e.g., using traditional routing, including STEP-enhanced routing, or using other routing structures such as MPLS) in region "West", or vice versa.

[0511] Network Assessment Using STEP

[0512] The STEP repository has STEP documents from all STEP routers in the network that advertise the availability of their services. This means that the STEP repository can provide a view of the entire network at any given time, and can also provide a history of changes that have occurred in the network over a period of time.

[0513] In an exemplary embodiment, a user interface (e.g., a web client) will be enhanced to provide a service-level and network-level view relative to the data contained in the STEP repository. Since the STEP repository is non-persistent, the STEP monitoring client on Conductor will listen to all STEP changes in the network and store them in a persistent time series database. The raw data will be stored and aggregated for a configured amount of time. There will also be an interface for viewing the contents of the STEP repository, for example to debug routing problems.

[0514] The following is an example of a "show" command that lists all STEP repositories and the number of clients connected to each repository:

[0515] Shows the STEP repository

[0516]

[0517] The location indicates where these STEP repositories are hosted. The main repository is where all records are stored. All other repositories proxy requests to the main repository. The client section indicates the number of clients connected to each repository. On the main repository, the number of clients preferably includes proxy requests from other STEP repositories.

[0518] Below is an example of the summary command, which shows the number of areas and the number of routers in each area.

[0519] Show STEP repository overview

[0520] Agency: t128

[0521] Region: 2

[0522] Name Router

[0523] Area A 4

[0524] Area B 2

[0525] Client connections: 6

[0526] Each router repository can be queried independently to see the current state of what is advertised by each router. It shows each area that the router is a member of and the advertisements made by the router in each area.

[0527] Show STEP repository router R1 <area>

[0528] Region A

[0529] Peer Path:

[0530] Peer-path-id1

[0531] SLA (updated 2 minutes ago)

[0532] Latency: 20ms

[0533] Loss: 0%

[0534] Jitter: 10ms

[0535] Service Strategy

[0536] Strategy 1: Meeting SLAs

[0537] Strategy 2: Not meeting SLA

[0538] Serve:

[0539] Service S1

[0540] 1.1.1.0 / 24nexthop{vector A}

[0541] 1.1.1.1 / 32nexthop{vectorB,sourcePath:DistrictB}

[0542] Service S2

[0543] 1.1.1.0 / 24nexthop{vector A}

[0544] External Routing:

[0545] protocol

[0546] BGP

[0547] 5.5.5.5 / 32nexthop{cost1,sourcePath:DistrictB}

[0548] Area B

[0549] Peer Path:

[0550] Peer-path-id2

[0551] SLA (updated 3 minutes ago)

[0552] Latency: 10ms

[0553] Loss: 1%

[0554] Jitter: 0ms

[0555] Service Strategy

[0556] Strategy 1: Meeting SLAs

[0557] Strategy 2: Meeting SLAs

[0558] Serve:

[0559] Service S1

[0560] 1.1.1.1 / 32nexthop{vector B}

[0561] The previous commands provide an overview of the network from the perspective of each router. When troubleshooting a problem in the network, the last changes that occurred in the network will be more useful than a view of the entire network. The following command shows the last changes. The following is an example of showing the last changes. Show STEP repository updates <area> <last update number>

[0562] Region A

[0563] 1 minute ago

[0564] +R1

[0565] Service S1

[0566] 1.1.1.0 / 24nexthop{vector A}

[0567] -R2

[0568] External Routing

[0569] 2.2.2.2 / 24nexthop{cost1}

[0570] 2 minutes ago

[0571] +R3

[0572] Peer Path ID1

[0573] Service Strategy

[0574] Strategy 1: Not meeting SLA ...

[0576] The user interface (e.g., web client) will be enhanced to show the history of STEP repository changes. The STEP repository has a diff of all network topology changes for each region. Therefore, network topology changes at any point in time can be replayed on the web to show router changes, path SLA changes, and network outages. This will serve as a very powerful tool to monitor network changes and pinpoint outages during specific time periods.

[0577] Fig.17 is a schematic wireframe diagram showing a heatmap view of a network.

[0578] Aggregate Routes and Services

[0579] As discussed above, in the case where a router is part of more than one area, routes or services learned from a first area will be aggregated and published to a second area, with the router acting as the next hop for the aggregated route or service (i.e., a router in one area will not publish all of the other peer information it has learned to another area). In this way, the routers in the first area will be hidden from the second area, i.e., the routers in the second area will know that the route or service is available from the router in the first area that published the route or service, but will not know the specific way in which the route or service is provided in the first area. This helps to better segment the network, as the routers in the second area do not need to know about all of the routers in the first area.

[0580] Additionally, the routers may publish aggregate routes or services with aggregate path metrics, allowing routers in the second area to evaluate the aggregate route or service as an entity without knowing the details of the route or service in the first area.

[0581] Additionally or alternatively, to prevent loops, the router in the first area appends the first area name to the source path of the published route or service. Then, if the router in the first area receives a publication of a route or service from another area and the first area name is in the source path of the published route or service, the router will ignore the published route or service.

[0582] It is important to note that a router in the second area may receive advertisements for a particular aggregate route or service from multiple routers in the first area, and each router may have a different path metric. Thus, for example, if a particular route or service is available through two routers in a particular area, the routers in the other area may select the router with the best metric for that particular route or service.

[0583] Alternative release mechanism

[0584] The exemplary STEP embodiment is described above with reference to a publish-subscribe model, in which a STEP router publishes STEP documents to a STEP server and subscribes to the STEP server to receive service and topology state information from other routers. However, in alternative embodiments, STEP may be implemented using other mechanisms to selectively distribute service and topology state information between routers to achieve substantially the same functionality as described above.

[0585] As an example, the STEP server may be configured to implement a "push" mechanism for selectively transmitting service and topology state information to routers. Here, for example, rather than the STEP routers subscribing to receive the service and topology state information, the STEP routers may distribute the service and topology state information received from the STEP routers based on the configuration information without the STEP routers subscribing to receive the service and topology state information.

[0586] As another example, STEP routers can exchange service and topology state information through a mesh transmission mechanism based on configuration information. Here, for example, each STEP router can be configured to exchange service and topology state information with one or more other STEP routers (including in multiple areas), and then the STEP routers can establish peer-to-peer direct or indirect communication connections to exchange service and topology state information.

[0587] As another example, STEP routers may exchange service and topology state information through a peer-to-peer delivery mechanism, wherein a STEP router delivers service and topology state information to other STEP routers so that all STEP routers obtain service and topology state information for other STEP routers from which service and topology state information is needed. For example, if router A is adjacent to router B, and router B is adjacent to router C, then router C may deliver its own service and topology state information and optionally other collected service and topology state information to router B, and router B may in turn deliver its own service and topology state information and service and topology state information received from router C to router A.

[0588] Thus, STEP generally involves selectively distributing service and topology state information among STEP routers so that the STEP routers may have additional information upon which to make routing decisions and may be implemented using a variety of distribution mechanisms.

[0589] It should also be noted that many of the above applications can be supported in non-STEP routing systems through other publishing mechanisms. For example, a non-STEP router can advertise aggregate routes or services to neighboring routers, for example, as part of a link state exchange.

[0590] Other matters

[0591] It should be noted that the headings above are used for convenience and should not be construed as limiting the invention in any way.

[0592] Various embodiments of the present invention may be implemented, at least in part, in any conventional computer programming language. For example, some embodiments may be implemented in a procedural programming language (e.g., "C") or in an object-oriented programming language (e.g., "C++"). Other embodiments of the present invention may be implemented as preconfigured, stand-alone hardware elements and / or as preprogrammed hardware elements (e.g., application specific integrated circuits, FPGAs, and digital signal processors), or other related components.

[0593] In alternative embodiments, the disclosed apparatus and methods (e.g., see the various flow charts above) may be implemented as a computer program product for use with a computer system. Such an implementation may include a series of computer instructions fixed on a tangible, non-transient medium, such as a computer-readable medium (e.g., a floppy disk, CD-ROM, ROM, or fixed disk). The series of computer instructions may embody all or part of the functionality previously described herein with respect to the system.

[0594] Those skilled in the art will appreciate that such computer instructions may be written in a variety of programming languages ​​for use with many computer architectures or operating systems. In addition, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communication technology, such as optical, infrared, microwave or other transmission technology.

[0595] Such a computer program product may also be distributed as a removable medium with accompanying printed or electronic documentation (e.g., roll-up software), pre-loaded with a computer system (e.g., on a system ROM or fixed disk), or distributed from an electronic bulletin board or server on a network (e.g., the Internet or the World Wide Web), among other ways. In fact, some embodiments may be implemented in a software as a service model ("SAAS") or a cloud computing model. Of course, some embodiments of the present invention may be implemented as a combination of software (e.g., a computer program product) and hardware. Other embodiments of the present invention are implemented as complete hardware or complete software.

[0596] The computer program logic implementing all or part of the functionality previously described herein may be executed at different times on a single processor (e.g., concurrently) or may be executed at the same or different times on multiple processors and may run under a single operating system process / thread or under different operating system processes / threads. Thus, the term "computer process" generally refers to the execution of a set of computer program instructions, regardless of whether different computer processes are executed on the same or different processors, and regardless of whether different computer processes are running under the same operating system process / thread or under different operating system processes / threads.

[0597] It is important to note that embodiments of the present invention may employ conventional components, such as conventional computers (e.g., off-the-shelf PCs, mainframes, microprocessors), conventional programmable logic devices (e.g., off-the-shelf FPGAs or PLDs), or conventional hardware components (e.g., off-the-shelf ASICs or discrete hardware components), which, when programmed or configured to perform the non-conventional methods described herein, produce non-conventional devices or systems. Thus, the inventions described herein are not conventional in any way, because even when conventional components are used to implement embodiments, the resulting devices and systems (e.g., STEP server controllers and STEP client controllers) are necessarily non-conventional, because absent special programming or configuration, the conventional components do not inherently perform the described non-conventional functions.

[0598] The activities described and claimed herein provide technical solutions to problems encountered in the art that are not, as a whole, well understood, customary, or conventional, and in any event provide practical applications that improve and enhance computers and computer routing systems.

[0599] Potential claims

[0600] Various embodiments of the present invention may be characterized by potential claims listed in the paragraphs following this paragraph (and before the actual claims provided at the end of this application). These potential claims form part of the written description of the application. Therefore, the subject matter of the following potential claims may be presented as actual claims in subsequent proceedings involving this application or any application claiming priority based on this application. The inclusion of such potential claims should not be interpreted as meaning that the actual claims do not cover the subject matter of the potential claims. Therefore, the decision not to present these potential claims in subsequent proceedings should not be interpreted as donating the subject matter to the public.

[0601] Potential subject matter that may be claimed related to the service and topology exchange protocol (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) includes, but is not limited to:

[0602] P1. A routing system for implementing a service and topology exchange protocol (STEP), the routing system comprising:

[0603] A primary STEP server configured to maintain the STEP repository; and

[0604] A plurality of routers, each router comprising a STEP client communicating with a primary STEP server; wherein:

[0605] The STEP client of each router is configured to transmit, using a service and topology exchange protocol, a STEP document containing service and topology state information for at least one route or service available through the router to a master STEP server for storage in a STEP repository;

[0606] The master STEP server is configured to transmit service and topology state information from the STEP repository for at least one other router to the STEP client of each router based on the configured relationships between the routers using the service and topology exchange protocol; and each router is configured to make routing decisions based at least in part on the service and topology state information from the at least one other router.

[0607] P2. A system according to claim P1, wherein the STEP document comprises a JSON patch file.

[0608] P3. A system according to claim P1, wherein the information in the STEP repository is organized as a path tree database, and wherein each STEP document includes a path definition identifying a router for storing service and topology status information of the router in the path tree database.

[0609] P4. The system according to claim P1 further comprises at least one secondary STEP server configured to proxy STEP requests to the primary STEP server.

[0610] P5. A system according to claim P1, wherein at least one router is a member of multiple areas and transmits separate STEP documents containing service and topology status information for each area of ​​which it is a member.

[0611] P6. A system according to claim P1, wherein at least one router is a member of multiple areas and receives service and topology status information of routers in each area of ​​which it is a member.

[0612] P7. A system according to claim P1, wherein the service and topology state information transmitted by the router also includes a service level agreement for a given service and an indication of whether the given service is within the service level agreement.

[0613] P8. A system according to claim P1, wherein at least one router is a member of an area and transmits service and topology state information including routes or services learned from outside the area.

[0614] P9. A system according to claim P1, wherein at least one router transmits service and topology state information including at least one path metric for a route or service.

[0615] P10. The system of claim P1, wherein the master STEP server is separate from the router.

[0616] P11. A system according to claim P1, wherein the master STEP server is in one of the routers.

[0617] P12. A server for implementing a service and topology exchange protocol (STEP), the server comprising:

[0618] data storage device; and

[0619] A Service and Topology Exchange Protocol (STEP) server controller in communication with a plurality of routers, the STEP server controller being configured to:

[0620] maintaining a STEP repository in a data storage device;

[0621] receiving a STEP document containing service and topology state information from each of the plurality of routers using a service and topology exchange protocol for storage in a STEP repository; and

[0622] Based on the configured relationships between the routers, service and topology state information for at least one other router from the STEP repository is transmitted to each router using a service and topology exchange protocol, the transmitted service and topology state information enabling each router to make routing decisions based at least in part on the service and topology state information from the at least one other router.

[0623] P13. A server according to claim P12, wherein the STEP document comprises a JSON patch file.

[0624] P14. A server according to claim P12, wherein the information in the STEP repository is organized as a path tree database, and wherein each STEP document includes a path definition identifying a router for storing service and topology status information of the router in the path tree database.

[0625] P15. A server according to claim P12, wherein at least one router is a member of multiple areas and transmits separate STEP documents containing service and topology status information for each area of ​​which it is a member.

[0626] P16. A server according to claim P12, wherein at least one router is a member of multiple areas and receives service and topology status information for the router in each area of ​​which it is a member.

[0627] P17. A server according to claim P12, wherein the server is separate from the router.

[0628] P18. A server according to claim P12, wherein the server is in a router among routers.

[0629] P19. A router for implementing a service and topology exchange protocol (STEP), the router comprising:

[0630] Data storage device;

[0631] A Service and Topology Exchange Protocol (STEP) client controller that communicates with a STEP server, the STEP client controller being configured to:

[0632] communicating service and topology state information for at least one route or service available through the router to a STEP server using a service and topology exchange protocol;

[0633] receiving service and topology state information for at least one other router from a STEP server using a service and topology exchange protocol based on configured relationships between the routers; and

[0634] storing the received service and topology state information for at least one other router in a data store; and

[0635] A routing engine is configured to make routing decisions based at least in part on service and topology state information for at least one other router.

[0636] P20. The router according to claim P19, wherein the STEP document comprises a JSON patch file.

[0637] P21. A router according to claim P19, wherein the information in the STEP repository is organized as a path tree database, and wherein each STEP document includes a path definition identifying a router for storing service and topology status information of the router in the path tree database.

[0638] P22. A router according to claim P19, wherein the router is a member of multiple areas and transmits separate STEP documents, the public STEP documents containing service and topology status information for each area of ​​which it is a member.

[0639] P23. A router according to claim P19, wherein the router is a member of multiple areas and receives service and topology status information of routers in each area of ​​which it is a member.

[0640] P24. A router according to claim P19, wherein the service and topology state information transmitted by the router also includes a service level agreement for a given service and an indication of whether the given service is within the service level agreement.

[0641] P25. A router according to claim P19, wherein the router is a member of an area and transmits service and topology state information including routes or services learned from outside the area.

[0642] P26. A router according to claim P19, wherein the service and topology state information transmitted by the router includes at least one metric for a route or a service.

[0643] P27. The router according to claim P19, wherein the router further comprises a STEP server configured to maintain a STEP repository.

[0644] P28. A system according to claim P1, wherein a given STEP document includes only service and topology state information changes.

[0645] P29. A system according to claim P1, wherein the given service and topology state information transmitted by the master STEP server to the STEP client of a given router only includes service and topology state information changes.

[0646] P30. A server according to claim P12, wherein a given STEP document only includes service and topology state information changes.

[0647] P31. A server according to claim P12, wherein the given service and topology state information transmitted by the master STEP server to the STEP client of a given router only includes service and topology state information changes.

[0648] P32. A router according to claim P19, wherein a given STEP document only includes service and topology state information changes.

[0649] P33. A router according to claim P19, wherein a given service and topology state information transmitted by the master STEP server to the STEP client of a given router only includes service and topology state information changes.

[0650] Potential subject matter that may be claimed related to segment-based metrics (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) includes, but is not limited to:

[0651] P1. A routing system, comprising:

[0652] a first router; and

[0653] a second router, wherein the first router is configured to receive service and topology state information for at least one other router; identify, using the received service and topology state information, a route or service from another router for which the second router has access through the first router; calculate an aggregate metric for the routes or services available through the first router; and publish the routes or services including the aggregate metric to the second router, with the first router as a next hop for the published routes or services.

[0654] P2. The system of claim P1, wherein the first router publishes the route or service by transmitting the route or service to a central repository, the central repository being configured to communicate the route or service to the second router.

[0655] P3. A system according to claim P1, wherein:

[0656] The first router is a member of the first area and the second area;

[0657] The second router is a member of the second area;

[0658] The first router receives service and topology state information from at least one other router in the first area; and

[0659] The first router publishes the route or service to a second router in the second area in a manner that hides information related to the route or service from the first area from the second router.

[0660] P4. A system according to claim P3, wherein the route or service is in the first area.

[0661] P5. A system according to claim P3, wherein the route or service is in a third area.

[0662] P6. The system of claim P3, wherein the first area is associated with a first area name, and wherein the first router is configured to publish a route or service including a source path for the published route or service to a second router in the second area, wherein the first area name is included in the source path.

[0663] P7. The system of claim P6, wherein the first router is configured to receive a published route or service including a source path from another area, and append the first area name to the source path.

[0664] P8. A router, comprising:

[0665] data storage device; and

[0666] A Service and Topology Exchange Protocol (STEP) client controller configured to:

[0667] receiving service and topology state information for at least one other router, and storing the received service and topology state information in a data storage device;

[0668] identifying, using the received service and topology state information, a route or service from another router for which the second router has access through the first router and for which the route or service is available;

[0669] Calculating an aggregate metric for routes or services available through the router; and publishing the routes or services including the aggregate metric to a second router and using the router as a next hop for the published routes or services.

[0670] P9. A router according to claim P8, wherein the STEP client controller is configured to publish the route or service by transmitting the route or service to a central repository, which is configured to communicate the route or service to the second router.

[0671] P10. The router according to claim P8, wherein:

[0672] The router is a member of a first area and a second area;

[0673] The second router is a member of the second area;

[0674] The router receives service and topology state information from at least one other router in the first area; and

[0675] The router publishes the route or service to a second router in the second area in a manner that hides information related to the route or service from the first area from the second router.

[0676] P11. The router according to claim P10, wherein the route or service is in the first area.

[0677] P12. The router according to claim P10, wherein the route or service is in a third area.

[0678] P13. The router of claim P10, wherein the first area is associated with a first area name, and wherein the router is configured to publish a route or service including a source path for the published route or service to a second router in a second area, wherein the first area name is included in the source path.

[0679] P14. The router according to claim P13, wherein the router is configured to receive a published route or service including a source path from another area, and append the first area name to the source path.

[0680] P15. A routing system for detecting and avoiding loops between a plurality of routers organized into a plurality of regions, the routing system comprising:

[0681] A plurality of routers are organized into a plurality of areas, including at least a first area and a second area, each area being associated with a different area name, the plurality of routers including a first router that is a member of the first area and the second area, the first router being configured to:

[0682] publishing the first route or service from the first region to the second region by transmitting a first advertisement including the first route or service and a first source path for the first route or service, wherein the first region name is included in the first source path;

[0683] receiving a second advertisement of a second route or service including a second source path from another region;

[0684] determining whether the second source path includes the first area name;

[0685] When the second source path does not include the first area name, processing the second route or service as a newly learned route or service in the first area; and

[0686] When the second source path does include the first area name, the second route or service is ignored.

[0687] P16. The system of claim P15, wherein the first route or service advertised by the first router further identifies the first router as a next hop for the first route or service in the first area.

[0688] P17. The system according to claim P15, wherein publishing the first route or service from the first area to the second area comprises:

[0689] receiving a first publication from another region including the first source path; and

[0690] Append the first region name to the first source path in the first publication.

[0691] P18. The system of claim P15, wherein the first router transmits the first publication to a central repository and receives the second publication from the central repository, the central repository being configured to communicate the route or service to at least one router in the second region.

[0692] P19. A router for detecting and avoiding loops between a plurality of routers organized into a plurality of areas, the plurality of areas comprising at least a first area and a second area, each area being associated with a different area name, the router being a member of the first area and the second area, the router comprising:

[0693] A controller configured to:

[0694] publishing the first route or service from the first region to the second region by transmitting a first advertisement including the first route or service and a first source path for the first route or service, wherein the first region name is included in the first source path;

[0695] receiving a second advertisement of a second route or service including a second source path from another region;

[0696] determining whether the second source path includes the first area name;

[0697] When the second source path does not include the first area name, treating the second route or service as a newly learned route or service of the first area; and

[0698] When the second source path does include the first area name, the second route or service is ignored.

[0699] P20. The router according to claim P19, wherein the first route or service published by the controller also identifies the first router as a next hop for the first route or service in the first area.

[0700] P21. The router according to claim P19, wherein publishing the first route or service from the first area to the second area comprises:

[0701] receiving a first publication from another region including the first source path; and

[0702] Append the first region name to the first source path in the first publication.

[0703] P22. The router of claim P19, wherein the first router transmits the first publication to a central repository and receives the second publication from the central repository, the central repository being configured to communicate the route or service to at least one router in the second region.

[0704] Potential subject matter that may be claimed (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) related to the distribution of multicast information includes, but is not limited to:

[0705] P1. A routing system for distributing multicast routing information for a multicast service, the routing system comprising:

[0706] A plurality of routers, including a multicast source router and a plurality of multicast receiver routers, provide a multicast service, wherein the routers are configured to exchange multicast information associated with the multicast service, the multicast information including identifications of the multicast source and the multicast receivers.

[0707] P2. The system according to claim P1, wherein each router is configured to transmit the router's multicast information to a STEP repository using a Service and Topology Exchange Protocol (STEP), and to receive multicast information of other routers from the STEP repository.

[0708] P3. A system according to claim P2, wherein the central repository is managed by a master STEP server.

[0709] P4. A system according to claim P3, wherein the master STEP server is in one of the routers.

[0710] P5. A system according to claim P3, wherein the main STEP server is in a device separate from the router.

[0711] P6. A system according to claim P2, wherein the multicast information is transmitted to the STEP server in a STEP document.

[0712] P7. A system according to claim P6, wherein the STEP document is a JSON document.

[0713] P8. A system according to claim P6, wherein the information in the STEP repository is organized as a path tree database, and wherein each STEP document includes a path definition identifying a router for storing multicast information of the router in the path tree database.

[0714] P9. A system according to claim P1, wherein:

[0715] The multicast source complies with a tenant-based sender access policy that specifies at least one source tenant that is allowed to send packets to the multicast service; and

[0716] The multicast receivers comply with a tenant-based receiver access policy that specifies at least one receiver tenant that is allowed to receive packets from the multicast service.

[0717] P10. The system of claim PI, wherein the router is configured to determine an optimal rendezvous point router for distributing packets associated with the multicast service based on the exchanged multicast information.

[0718] P11. A router for distributing multicast routing information for a multicast service, the router comprising:

[0719] a data storage device storing multicast information associated with a multicast service, the multicast information including identification of a multicast source and multicast recipients; and

[0720] A controller is configured to exchange multicast information associated with a multicast service, the multicast information including identification of a multicast source and multicast recipients.

[0721] P12. The system according to claim P11, wherein each router is configured to transmit the router's multicast information to a STEP repository using a Service and Topology Exchange Protocol (STEP), and to receive multicast information of other routers from the STEP repository.

[0722] P13. A system according to claim P12, wherein the central repository is managed by a master STEP server.

[0723] P14. A system according to claim P13, wherein the master STEP server is in one of the routers.

[0724] P15. A system according to claim P13, wherein the main STEP server is in a device separate from the router.

[0725] P16. A system according to claim P12, wherein the multicast information is transmitted to the STEP server in a STEP document.

[0726] P17. A system according to claim P16, wherein the STEP document is a JSON document.

[0727] P18. A system according to claim P16, wherein the information in the STEP repository is organized as a path tree database, and wherein each STEP document includes a path definition identifying a router for storing multicast information of the router in the path tree database.

[0728] P19. A system according to claim P11, wherein:

[0729] The multicast source complies with a tenant-based sender access policy that specifies at least one source tenant that is allowed to send packets to the multicast service; and

[0730] The multicast receivers comply with a tenant-based receiver access policy that specifies at least one receiver tenant that is allowed to receive packets from the multicast service.

[0731] P20. The system of claim P11, wherein the router is configured to determine an optimal rendezvous point router for distributing packets associated with the multicast service based on the exchanged multicast information.

[0732] Potential subject matter that may be claimed (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) related to multicast source and receiver access control includes, but is not limited to:

[0733] P1. A routing system for providing multicast access control, the routing system comprising:

[0734] A plurality of routers, the plurality of routers comprising a multicast source router and a plurality of multicast receiver routers, the plurality of routers providing a multicast service, wherein the routers are configured to implement a multicast access control policy for the multicast service, including a receiver access policy controlling which multicast receivers are allowed to receive packets from the multicast service, and a sender access policy controlling which multicast sources are allowed to send packets to the multicast service for distribution to the multicast receivers.

[0735] P2. The system of claim PI, wherein the sender access policy comprises a tenant-based sender access policy that specifies at least one source tenant that is allowed to send packets to the multicast service.

[0736] P3. The system of claim PI, wherein the receiver access policy comprises a tenant-based receiver access policy that specifies at least one receiver tenant that is allowed to receive packets from the multicast service.

[0737] P4. A system according to claim P3, wherein the router only accepts multicast joins from interfaces associated with the at least one receiving tenant.

[0738] P5. A system according to claim P3, wherein the router only accepts multicast joins from interfaces associated with the at least one receiving tenant unless a tenant-based receiving access policy is overridden by a configuration on one or more interfaces.

[0739] P6. A system according to claim P5, wherein at least one router is configured to accept multicast joins from interfaces that are not designated recipient tenants.

[0740] P7. A system according to claim P5, wherein at least one router is configured to reject multicast joins from an interface that is a designated receiver tenant.

[0741] P8. The system of claim P3, wherein the router is configured to transmit the membership query message on an interface associated with the at least one recipient tenant.

[0742] P9. A system according to claim P3, wherein the router is configured to discard membership report messages on any interface having a tenant that does not have access to the multicast service.

[0743] P10. The system of claim 1, wherein the routers are configured to exchange multicast information associated with the multicast service, the multicast information comprising identifications of multicast sources and multicast recipients.

[0744] P11. The system according to claim P10, wherein each router is configured to transmit the multicast information of the router to a central repository and receive the multicast information of other routers from the central repository.

[0745] P12. The system of claim P10, wherein at least the source router is configured to determine an optimal rendezvous point router for distributing packets associated with the multicast service based on the exchanged multicast information.

[0746] P13. The system of claim PI, wherein the multicast source router is configured to transmit unicast packets for the multicast service to each multicast receiver router associated with at least one multicast receiver.

[0747] P14. The system of claim P1, wherein the multicast source router is configured to join a multicast tree and transmit multicast packets to a plurality of multicast receiver routers.

[0748] P15. A router for providing multicast access control, the router comprising:

[0749] a data storage device storing multicast access control policies for a multicast service, including a receiver access policy that controls which multicast receivers are permitted to receive packets from the multicast service and a sender access policy that controls which multicast sources are permitted to send packets to the multicast service for distribution to the multicast receivers; and

[0750] A controller configured to enforce a multicast access control policy for a multicast service.

[0751] P16. The router according to claim P15, wherein the sender access policy comprises a tenant-based sender access policy that specifies at least one source tenant that is allowed to send packets to the multicast service.

[0752] P17. The router according to claim P15, wherein the receiver access policy comprises a tenant-based receiver access policy that specifies at least one receiver tenant that is allowed to receive packets from the multicast service.

[0753] P18. The router according to claim P17, wherein the controller is configured to accept multicast joins only from interfaces associated with the at least one receiving tenant.

[0754] P19. The router of claim 17, wherein the controller is configured to accept multicast joins only from interfaces associated with the at least one receiver tenant unless a tenant-based receiver access policy is overridden by a configuration on one or more interfaces.

[0755] P20. A router according to claim P19, wherein the controller is configured to accept multicast joins from interfaces that are not designated recipient tenants.

[0756] P21. A router according to claim P19, wherein the controller is configured to reject multicast joins from an interface that is a designated receiver tenant.

[0757] P22. The router according to claim P17, wherein the controller is configured to transmit the membership query message on an interface associated with the at least one recipient tenant.

[0758] P23. A router according to claim P17, wherein the controller is configured to discard membership report messages on any interface having a tenant that does not have access to the multicast service.

[0759] P24. A router according to claim P15, wherein the controller is configured to exchange multicast information associated with the multicast service with other routers, the multicast information including identification of any multicast sources and any multicast recipients associated with the router.

[0760] P25. The router according to claim P24, wherein the controller is configured to transmit multicast information of the router to a central repository and receive multicast information of other routers from the central repository.

[0761] P26. The router according to claim P24, wherein the controller is configured to determine an optimal rendezvous point router for distributing packets associated with the multicast service based on the exchanged multicast information.

[0762] P27. The router according to claim P15, wherein the controller is configured to transmit a unicast packet for the multicast service to each multicast recipient router associated with at least one multicast recipient.

[0763] P28. The router according to claim P15, wherein the controller is configured to join a multicast tree and transmit multicast packets to a plurality of multicast receiver routers.

[0764] Potential subject matter that may be claimed (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) related to a central authority for distributing service and topology state information changes includes, but is not limited to:

[0765] P1. A routing system for implementing a service and topology exchange protocol (STEP), the routing system comprising:

[0766] A primary STEP server that is configured to maintain the STEP repository; and

[0767] A plurality of routers, each router comprising a STEP client communicating with a primary STEP server; wherein:

[0768] The STEP client of each router is configured to communicate service and topology state information of at least one route or service available through the router to the master STEP server for storage in the STEP repository using the service and topology exchange protocol; and

[0769] The master STEP server is configured to determine, for each router, based at least in part on the service and topology state information received from the routers, whether the STEP repository includes any service and topology state information changes for the router, and to communicate only the service and topology state information changes to the STEP client of each router for which there are service and topology state information changes using the service and topology exchange protocol.

[0770] P2. A system according to claim P1, wherein the service and topology state information changes transmitted by the master STEP server include JSON patch files.

[0771] P3. A system according to claim P1, wherein the information in the STEP repository is organized as a path tree database, and wherein the service and topology state information received from the router includes a path definition identifying the router for storing the service and topology state information of the router in the path tree database.

[0772] P4. The system according to claim P1 further comprises at least one secondary STEP server configured to proxy STEP requests to the primary STEP server.

[0773] P5. A system according to claim P1, wherein at least one router is a member of multiple areas and transmits separate service and topology state information for each area of ​​which it is a member.

[0774] P6. A system according to claim P1, wherein at least one router is a member of multiple areas and receives service and topology state information changes for each area of ​​which it is a member from the master STEP server.

[0775] P7. A system according to claim P1, wherein the service and topology state information transmitted by the router also includes a service level agreement for a given service and an indication of whether the given service is within the service level agreement.

[0776] P8. A system according to claim P1, wherein at least one router is a member of an area and transmits service and topology state information including routes or services learned from outside the area.

[0777] P9. A system according to claim P1, wherein at least one router transmits service and topology state information including at least one path metric for a route or service.

[0778] P10. The system of claim P1, wherein the master STEP server is separate from the router.

[0779] P11. A system according to claim P1, wherein the master STEP server is in one of the routers.

[0780] P12. A server for implementing a service and topology exchange protocol (STEP), the router comprising:

[0781] data storage device; and

[0782] A STEP server controller in communication with a plurality of routers, each router including a STEP client, the STEP server controller being configured to:

[0783] maintaining a STEP repository in a data storage device;

[0784] receiving, from a STEP client of each router, service and topology state information for at least one route or service available through the router using a service and topology exchange protocol;

[0785] Store the received service and topology status information in the STEP repository;

[0786] determining, for each router, whether the STEP repository includes any service and topology state information changes for the router based at least in part on the service and topology state information received from the router; and

[0787] Using the service and topology exchange protocol, only service and topology state information changes are communicated to the STEP client of each router for which there are service and topology state information changes.

[0788] P13. A server according to claim P12, wherein the service and topology state information changes transmitted by the STEP server controller include JSON patch files.

[0789] P14. A server according to claim P12, wherein the information in the STEP repository is organized as a path tree database, and wherein the service and topology status information received from the router includes a path definition identifying the router for storing the service and topology status information of the router in the path tree database.

[0790] P15. A server according to claim P12, wherein at least one router is a member of multiple areas and transmits separate service and topology status information for each area of ​​which it is a member.

[0791] P16. A server according to claim P12, wherein at least one router is a member of multiple areas and receives service and topology state information changes for each area of ​​which it is a member from the STEP server controller.

[0792] P17. A server according to claim P12, wherein the server is separate from the router.

[0793] P18. A server according to claim P12, wherein the server is in a router among routers.

[0794] Potential subject matter that may be claimed (prefaced with the letter "P" to avoid confusion with the actual claims set forth below) related to source-based routing across multiple zones includes, but is not limited to:

[0795] P1. A routing system for routing packets for a route or service, the routing system comprising:

[0796] A plurality of routers including a source router, wherein:

[0797] The source router is configured to receive service and topology state information for at least one other router from a STEP repository using a service and topology exchange protocol based on configured relationships between the routers; determine a first path to a destination of a route or service based on the service and topology state information, the first path comprising an ordered list of consecutive routers to receive packets associated with the route or service starting from the first consecutive router and ending at the destination router; and send a packet with first metadata to the first consecutive router, the first metadata comprising a list of at least one remaining router in the ordered list of routers to receive packets associated with the route or service; and

[0798] Starting with a first successive router, each successive router is configured to receive a packet and determine whether the router is a destination router based on metadata associated with the received packet; and

[0799] When the router is not the destination router, the packet is forwarded to the next consecutive router in the ordered list of routers.

[0800] P2. The routing system according to claim P1, wherein the source router is configured to include the first successive router in the first metadata.

[0801] P3. The routing system according to claim P1, wherein the source router is configured to exclude the first successive router from the first metadata.

[0802] P4. A routing system according to claim P1, wherein each successive router is configured to remove itself from the first metadata before forwarding the packet to the next successive router.

[0803] P5. A routing system according to claim P1, wherein each successive router is configured to forward the packet to the next successive router by changing the destination address of the packet to the address of the next successive router.

[0804] P6. A routing system according to claim P5, wherein each successive router is configured to forward the packet to the next successive router by further changing the source address of the packet to the address of the forwarding router.

[0805] P7. A routing system according to claim P1, wherein the destination router is configured to forward the packet to the destination without metadata.

[0806] P8. The routing system of claim P1, wherein the source router is configured to include second metadata in the packet, the second metadata comprising session identification information.

[0807] P9. A routing system according to claim P1, wherein the destination router is configured to determine a second path to the destination of the route or service and transmit packets with second metadata, the second path including a second ordered list of consecutive routers to receive packets associated with the route or service, and the second metadata including a list of at least one remaining router in the second ordered list of routers to receive packets associated with the route or service.

[0808] P10. A router for routing packets for a route or service, the router comprising:

[0809] data storage device; and

[0810] A controller, the controller comprising source router logic configured to:

[0811] receiving service and topology state information for at least one other router from a STEP repository using a service and topology exchange protocol based on configured relationships between the routers; determining a first path to a destination of a route or service based on the service and topology state information, the first path comprising an ordered list of consecutive routers to receive packets associated with the route or service starting from the first consecutive router and ending at the destination router; and

[0812] A packet is sent to a first consecutive router with first metadata including a list of at least one remaining router in the ordered list of routers to receive packets associated with the route or service.

[0813] P11. The router of claim P10, wherein the source router logic is configured to include the first successive router in the first metadata.

[0814] P12. The router of claim P10, wherein the source router logic is configured to exclude the first successive router from the first metadata.

[0815] P13. The router of claim P10, wherein the source router logic is configured to include second metadata in the packet, the second metadata comprising session identification information.

[0816] P14. The router according to claim P10, wherein the controller further comprises a serial router logic configured to:

[0817] receiving a packet and determining, based on metadata associated with the received packet, whether the router is a destination router; and

[0818] When the router is not the destination router, the packet is forwarded to the next consecutive router in the ordered list of routers.

[0819] P15. A router according to claim P14, wherein the successive router logic is configured to remove itself from the first metadata before forwarding a packet to the next successive router.

[0820] P16. A router according to claim P14, wherein the successive router logic is configured to forward the packet to the next successive router by changing the destination address of the packet to the address of the next successive router.

[0821] P17. A router according to claim P16, wherein the successive router logic is configured to forward the packet to the next successive router by further changing the source address of the packet to the address of the forwarding router.

[0822] P18. A routing system according to claim P14, wherein when the router is a destination router, the continuous router logic is configured to forward the packet to the destination without metadata.

[0823] P19. A routing system according to claim P14, wherein the continuous router logic is configured to determine a second path to the destination of the route or service and transmit packets with second metadata, the second path including a second ordered list of continuous routers to receive packets associated with the route or service, and the second metadata including a list of at least one remaining router in the second ordered list of routers to receive packets associated with the route or service when the router is the destination router.

[0824] in conclusion

[0825] Although the above discussion discloses various exemplary embodiments of the present invention, it is apparent that those skilled in the art may make various modifications that will achieve some of the advantages of the present invention without departing from the true scope of the present invention. Unless the context otherwise requires, any reference to the "invention" is intended to refer to exemplary embodiments of the present invention and should not be construed as referring to all embodiments of the present invention. The described embodiments are to be considered in all respects as illustrative and not restrictive.< / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / json> < / routerdocument> < / district-name> < / authority-name>

Claims

1. A first router of a plurality of routers, the first router comprising a processing circuit system, the processing circuit system being configured to: sending first multicast information to a server storing a central repository of multicast information, the first multicast information specifying a multicast service associated with a multicast group, wherein the first multicast information identifies a multicast source device as being associated with the first router; receiving, for a second router of the plurality of routers connected to a multicast receiver device, second multicast information specifying the multicast service from the server, wherein the second multicast information identifies the multicast receiver device as being associated with the second router; receiving packets for the multicast service from the multicast source device; Determine the second router among the plurality of routers based on the first multicast information and the second multicast information; as well as The packets are forwarded to the second router for distribution to the multicast receiver devices.

Images