Source provisioning service infrastructure

Abstract

A head-end node in one or more network autonomous systems utilizes a protocol to instantiate a service on a tail-end node. The head-end node can use a service request mechanism enabled by the protocol to request service instantiation on the tail-end node without requiring the network operator to manually configure the tail-end node, or even to have access to the tail-end node. Furthermore, the protocol can provide mechanisms to define handling attributes (e.g., quality of service (QoS) attributes, maximum transmission unit (MTU) settings, etc.) for traffic of the service, a service confirmation mechanism for the head-end node to determine that the service has been instantiated on the tail-end node, etc. In this way, the head-end node can be used to instantiate a service on a tail-end node without the network operator needing to have direct access to the tail-end node to manually configure the tail-end node.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 547,735, filed December 10, 2021, which claims priority to U.S. Provisional Patent Application No. 63 / 226,906, filed July 29, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the mechanisms and techniques by which head nodes initiate service configuration on tail nodes. Background Technology

[0004] An Autonomous System (AS) is a large network or group of networks that includes network devices that utilize a common routing policy. An AS has a set of Internet Protocol (IP) prefixes that are provided to the network devices within the network(s) and is generally controlled and overseen by a single entity or organization. Various protocols exist between one or more ASs for communication, such as Virtual Private Wire Service (VPWS), Ethernet Virtual Private Network (EVPN), and so on.

[0005] For example, EVPN enables users to connect distributed sites using Layer 2 (L2) virtual bridges. Generally, an EVPN consists of customer edge (CE) devices (e.g., hosts / servers, routers, switches, etc.) connected to a provider edge (PE) router. In some examples, the PE router may include a multiprotocol label switching (MPLS) edge switch, which operates at the edge of the MPLS infrastructure. Additionally, VPWS L2 VPNs utilize L2 services over MPLS to build a topology that connects end-customer sites within the VPN. The services configured in these Layer 2 VPNs are called VPWS. You can configure a VPWS instance for each VPWS Layer 2 VPN on each associated edge device.

[0006] EVPN-VPWS networks provide a framework for delivering VPWS using EVPN signaling mechanisms. The advantages of VPWS with EVPN mechanisms include single-active or fully active multi-homing capabilities, and support for inter-Autonomous System (AS) options associated with Border Gateway Protocol (BGP) signaling VPNs.

[0007] Traditionally, to configure services (e.g., VPWS instances) on devices such as edge devices (e.g., routers), network operators must access each edge device and instantiate the service on it. However, manually configuring each device is cumbersome and error-prone. Furthermore, network operators often lack direct access to edge devices, for example, when they are located in different network ASs, and cannot configure new services on these edge devices. Attached Figure Description

[0008] The following detailed description will be provided with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of the reference numeral(s) identifies the drawing in which that numeral(s) first appears. The same reference numerals are used in different drawings to indicate similar or identical items. The systems depicted in the drawings are not to scale, and the components within the drawings may not be depicted to scale relative to each other.

[0009] Figure 1 The diagram illustrates the system architecture of an example Autonomous Network System (AS), where a network operator configures headend routers with services, and the headend routers use protocols to send messages to enable services on tailend routers.

[0010] Figure 2 The diagram illustrates the system architecture of an example network with multiple autonomous systems, where the network operator configures headend routers with services, and the headend routers use protocols such as Border Gateway Protocol (BGP) to send messages to enable services on tailend routers.

[0011] Figure 3 The diagram illustrates a sample of the Service Request Type-Length-Value (TLV) of a BGP message that provides information for instantiating services for tail routers.

[0012] Figure 4 The diagram illustrates a service acknowledgment TLV (Transmission Line Value) for BGP messages that a tail router can send to a head router.

[0013] Figure 5 The diagram illustrates a sample of the Service Attribute TLV (TLV) of a BGP message that indicates traffic processing parameters communicated by a service on a tail router.

[0014] Figure 6The diagram illustrates a service measurement TLV (Total Values) in BGP messages that indicate the metrics to be collected by the tail router that instantiated the service.

[0015] Figure 7 The diagram illustrates a service Yang data TLV that may include BGP messages containing Yang data for instantiating tail routers.

[0016] Figure 8 The diagram illustrates a flowchart of an example method by which a headend router uses a protocol to provide instantiation information to a tailend router, which can be used to instantiate services on the tailend router.

[0017] Figure 9 The diagram illustrates a flowchart of an example method by which a tail router instantiates a service using instantiation information provided by a head router.

[0018] Figure 10 This is a computer architecture diagram, illustrating an exemplary computer hardware architecture for implementing computing devices that can be utilized to realize various aspects of the technologies proposed herein. Detailed Implementation

[0019] Overview

[0020] The independent claims describe various aspects of the invention, and the dependent claims describe preferred features. A feature of one aspect may be applied individually to each aspect or in combination with other aspects.

[0021] This disclosure describes a technique by which a first router uses message passing in a protocol to provide instantiation information to a second router in order to instantiate a service on the second router.

[0022] A first method of implementing the techniques described herein may include receiving input from a network operator at a first router, the input causing a service to be instantiated on the first router. In this first method, the first router generates an advertisement message indicating the service instantiated on the first router and the path associated with reaching the service on the first router, and populates the advertisement message with service request attributes, the service request attributes including information for enabling the service on a second router. Generally, this information may include a service identifier indicating the service requested to be enabled on the second router, and service location information indicating the location where the service is enabled on the second router. Additionally, the first method may include sending the advertisement message including the service request attributes from the first router to the second router.

[0023] A second method of implementing the techniques described herein may include techniques for a trailing router to instantiate a service using instantiation information provided from a headend router. The second method may include receiving an advertisement message from the headend router at the trailing router. Generally, the advertisement message may include an indication of a path associated with reaching the service instantiated on the headend router, including a service request attribute requesting the trailing router to instantiate the service. The second method may also include instantiating the service on the trailing router at least in part based on the request. Optionally, in some cases, the second method may also include sending an acknowledgment message from the trailing router to the headend router, the acknowledgment message including measurement information.

[0024] Furthermore, the techniques described herein can be executed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described above.

[0025] Example Implementation

[0026] This disclosure describes a technique in one or more autonomous network systems where a head node uses a protocol such as Border Gateway Protocol (BGP) to send service signaling and instantiate services on a tail node. For example, a head node can use a service request mechanism enabled by the protocol to request service instantiation on a tail node without requiring the network operator to manually configure the tail node or even have configuration access to it. In addition to the service request mechanism, the protocol may further provide mechanisms to define processing attributes for service traffic (e.g., quality of service (QoS) attributes, Maximum Transmission Unit (MTU) settings, etc.), service acknowledgment mechanisms for the head node to determine that a service has been instantiated on the tail node, and so on. Thus, the head node can be used to instantiate services on the tail node without the network operator needing direct access to the tail node for manual configuration.

[0027] As mentioned above, manually instantiating nodes such as PE routers with new services is cumbersome and error-prone for network operators. The technology described in this article eliminates the need for network operators to perform these operations, and also eliminates the need for network controllers and protocols. Instead, it leverages routing protocols to provide on-demand connectivity for source configurations.

[0028] Any routing protocol can be used to implement the techniques described herein. However, leveraging BGP to source-configure new services on tail nodes may be advantageous because BGP supports inter-AS environments and can extend support to EVPN services. Furthermore, EVPN and L3 services are also driven or enabled by BGP protocols. Network operators may have direct access to head nodes and can configure or instantiate new services on them. The head nodes can then use routing protocols to push meaningful information about the instantiation of new services to tail nodes. In this way, tail nodes can be instantiated with new services without requiring network operators to manually instantiate services or even have access to the tail nodes.

[0029] As mentioned above, BGP can be used as a routing protocol to push instance information to tail nodes. Generally, when configuring services on a router, EVPN uses BGP Auto Discovery to advertise appropriate routes to inform remote PE routers about new available services and reachability information. When advertising is sent using extended BGP communities such as route destinations, route policies, etc., BGP route advertising may be limited to a subset of remote PE routers. When a remote PE router receives an EVPN route (e.g., a tail router), it can use this information to enable the service based on its local configuration. In the case of VPWS services, EVPN per EVPN instance (EVI) - Ethernet Auto Discovery (EAD) routes are used to announce the reachability of new services.

[0030] Along with route advertisements, new optional BGP path transition attributes can be used to request remote PE routers to install, enable, instantiate, and so on, services. This new attribute can be a BGP service request attribute and is defined as a set of elements encoded in a TLV-based format. The service request TLV can include various information, such as a request identifier (ID) for handling duplicate requests, a service (ID) identifying the service to be instantiated, a Media Access Control (MAC) address indicating the port onboard the remote PE router, a Virtual Local Area Network (VLAN) tag for the remote PE router, and so on. The service request TLV can then be used by the remote PE router to instantiate the requested service.

[0031] In some examples, additional TLVs, such as service attribute TLVs, may be included in the BGP service request attributes. Service attribute TLVs may include attributes to be used for the service once the service is instantiated, such as Quality of Service (QoS) indicating how much bandwidth is allowed or allocated on the service, Maximum Transmission Unit (MTU) settings defining the maximum packet size that the service can transmit to avoid fragmentation or packet loss, and so on.

[0032] In addition, BGP service request attributes may include additional TLVs, such as service measurement TLVs. Service measurement TLVs may include requests for information that can be used for operations, administration, and management (OAM). For example, a service measurement TLV may include a request for timestamp data that can be used to measure the round-trip delay between a service request and a service acknowledgment sent from a remote PE router.

[0033] While the following technologies are often described with reference to MPLS and / or segment routing (SR), these technologies are equally applicable to underlying and transport protocols such as SR version 6 (SRv6), Virtual Extensible LAN (VxLAN), and so on. Furthermore, these technologies are applicable to various IP tunneling protocols, such as Generic UDP Encapsulation (GUE), MPLS-over-UDP (MPLSoUDP), Generic Routing Encapsulation (GRE), Generic Protocol Extension (GPE), Point-to-Point Protocol over Ethernet (PPPoE), and so on. Additionally, although the technologies described in this article are based on VPWS, the technologies surrounding BGP are equally applicable to L2 bridging services and L3 VPN services in terms of address families.

[0034] Certain implementations and embodiments of this disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are illustrated. However, these various aspects may be implemented in many different forms and should not be construed as limited to the implementations described herein. This disclosure covers variations of the embodiments as described herein. Similar numerals always refer to similar elements.

[0035] Figure 1The system architecture diagram 100 of the example network autonomous system (AS) 102 is shown, in which the network operator configures the headend router 104 with services, and the headend router 104 uses protocols to send messages to enable services on the tailend router 106.

[0036] Network AS102 is a large network or group of networks that includes network devices utilizing a common routing policy. Network AS102 has a set of IP prefixes that are provided to network devices within the network(s) and are generally controlled and overseen by a single entity or organization. Various protocols exist for communication between one or more autonomous systems, such as VPWS, EVPN, etc. In some examples, network AS102 may be an MPLS network that uses labels instead of IP addresses or Layer 3 information to exchange packets, an IP network that uses unique IP addresses to transmit packets, etc. In various examples, network AS102 may be an MPLS / IP network where IP packets are encapsulated within packets with header labels (e.g., label switching).

[0037] As shown in the figure, network operator 110 can enable and / or configure services on headend router 104 at point "1". In some cases, headend router 104 is a PE router located at the edge of the provider network and connected to a customer edge router located at the customer's premises. The service can be any type of service, such as a VPWS L2 service between two customers connected via two PE routers (104 and 106). In some examples, network operator 110 can access the headend router via configuration access 112, but not the tail router 106. In other examples, it may be time-consuming and error-prone for network operator 110 to gain access to each PE router and configure each PE router using the service. Therefore, it is advantageous for network operator 110 to utilize its configuration access 112 to headend router 104 and enable remote circuitry on tail router 106 via one or more protocols. That is, network operator 110 wants the ability to inform tail router 106 about new service configurations, their activation, and their application.

[0038] To facilitate this, headend router 104 can use BGP auto-discovery (and / or other protocols) to advertise services. Once a service is configured on headend router 104, the appropriate route to the service is advertised in BGP, informing remote PE routers (e.g., tailend router 106) about the new available service and reachability information. BGP route advertisement can be limited to a subset of remote PEs. Techniques such as route destinations, routing policies, etc., can be used.

[0039] While any routing protocol can be used to perform the techniques described herein, leveraging BGP to source-configure new services on tail router 106 may be advantageous because BGP supports inter-AS environments and can extend support to EVPN services. Furthermore, EVPN and L3 services are also driven or enabled by the BGP protocol. After network operator 110 configures or instantiates a new service on head router 104 using direct configuration access 112, head router 104 can then use the routing protocol to push meaningful information about the instantiation of the new service to tail router 106.

[0040] As mentioned above, BGP can be used as a routing protocol to push instantiation information to tail nodes. Generally, when configuring services on a router, EVPN uses BGP auto-discovery to advertise appropriate routes to inform remote PE routers about new available services and reachability information. When advertising is sent using extended BGP communities such as route destinations, route policies, etc., BGP route advertising may be limited to a subset of remote PE routers. When a remote PE router receives an EVPN route (e.g., tail router 106), it can use this information to enable the service based on its local configuration. In the case of VPWS services, EVPN per EVPN instance (EVI) - Ethernet Auto-Discovery Routes (EAD) are used to announce the reachability of new services.

[0041] At point “2”, the headend router 104 can generate and send an advertisement message 114 that includes service request attributes. Along with the route advertisement(s) 114, new optional BGP path transition attributes can be used to request the tailend router(s) 106 to install, enable, instantiate, etc., the service. This new attribute can be a BGP service request attribute and is defined as a set of elements encoded in a TLV-based format. The service request TLV can include various information, such as a request ID for handling duplicate requests, a service ID for identifying the service to be instantiated, a MAC address indicating the port on which the tailend router(s) 106 is mounted, a VLAN tag for the remote PE router, etc. The service request TLV can then be used by the tailend router(s) 106 to instantiate the requested service.

[0042] In some examples, additional TLVs, such as service attribute TLVs, may be included in the BGP service request attributes. Service attribute TLVs may include attributes to be used for the service once the service is instantiated, such as Quality of Service (QoS) indicating how much bandwidth is allowed or allocated on the service, Maximum Transmission Unit (MTU) settings defining the maximum packet size that the service can transmit to avoid fragmentation or packet loss, and so on.

[0043] In addition, BGP service request attributes may include additional TLVs, such as service measurement TLVs. Service measurement TLVs may include requests for information that can be used for operations, administration, and management (OAM). For example, a service measurement TLV may include a request for timestamp data that can be used to measure the round-trip delay between a service request and a service acknowledgment sent from a remote PE router.

[0044] At point “3”, the trailing router 106 can enable the service based on the service request TLV included in the advertisement message 114. For example, the trailing router 106 can obtain service configuration information from a location where the service is available, indicated in the service request of the advertisement message 114. After the service is instantiated on the trailing router 106, the trailing router 106 can then generate and send an acknowledgment message 116 indicating that the service has been enabled.

[0045] Generally, an Autonomous System (AS) 102 can be any type of network having a set of connection IP routing prefixes under the control of one or more operators of a managing entity. AS 102 can connect to the Internet using a generic, well-defined routing policy. An Internet Service Provider (ISP) is an example of AS 102. AS 102 may include one or more networks implemented using any feasible communication technology, such as wired and / or wireless methods and / or technologies. Distributed applications 102 may each include any combination of Personal Area Networks (PANs), Local Area Networks (LANs), Campus Area Networks (CANs), Metropolitan Area Networks (MANs), Extranets, Intranets, the Internet, short-range wireless communication networks (e.g., ZigBee, Bluetooth, etc.), and Wide Area Networks (WANs)—including centralized and / or distributed—and / or any combination, permutation, and / or aggregation thereof. AS 102 may include devices, virtual resources, or other nodes that transmit packets from one network segment to another from nodes in a computer network. Although described as headend router 104 and tailend router 106, routers 104 / 106 can be any type of PE or CE router, or any other type of networking node on which services can be instantiated according to the technologies described herein.

[0046] Figure 2The diagram illustrates the system architecture of an example network with multiple autonomous systems, where the network operator configures headend routers with services, and the headend routers use protocols (such as Border Gateway Protocol (BGP)) to send messages to enable services on tailend routers. (The diagram is repeated in the original text.) Figure 1 Similar to, Figure 1 The operation also applies to Figure 2 .

[0047] Figure 2 The diagram illustrates an inter-AS link between two distinct networks, AS202 and AS204. Each network, AS202 and AS204, may have one or more user-network interfaces (UNIs) 208A and 208B, which represent the physical demarcation points between the responsibilities of the subscriber (e.g., customer edge or CE) and the responsibilities of the service provider. Similarly, each network, AS202 and AS204, may have one or more external network-to-network interfaces (ENNIs) 206 and 206B, which represent the demarcation points between two operator networks (e.g., AS202 and AS204) operating as separate management domains.

[0048] In this example, network operator 110 has unique configuration access to headend router 104 and other routers in network AS202. Network operator 110 may wish to provide service connectivity to tail router 106, where new configurations are remotely pushed. While remotely fulfilling requests from headend router 104, operator 110 can assign ingress and egress attributes to the tail circuit, such as QoS policies, MTU, etc. Network AS202 may also be connected to many other networks via different ENNI-ENNI links.

[0049] Generally, network operator 110 may know a set of rules and information related to the tail network to be deployed. This information may include network AS204 information, tail router 106 ID, interface name, VLAN ID, etc. As shown, head router 104 can use a BGP210 connection to send an advertisement message 114 including service request attributes. Then, tail router 106 can use the information included in the service request to instantiate the service and send service confirmation messages 116 to head router 104 and / or different devices accessible to network operator 110.

[0050] In order to Figure 1 and Figure 2As described above, when mounting the tail device 106, the network operator 110 may need to possess various information associated with the tail device 106. For example, the network operator 110 may need information such as: BGP ASN number, BGP EVPN VRF indicated by an EVPN instance or a set of BGP routing targets, service identifier (e.g., "pseudowire ID", a known template pre-configured on the tail router 106, etc.), chassis ID (e.g., the IP address specifying the router ID to which the device is connected, port identifiers to which the device to be mounted are (e.g., port MAC address, port name, port ID, etc.), Ethernet label for the mounted device (e.g., single-label or dual-label VID), and / or any attributes related to the service level agreement (e.g., bandwidth, MTU, etc.). This information can be used to send a service request / advertisement message 114 to the tail router and can be included in the service request 114.

[0051] Figure 3 Figure 300 illustrates a service request type-length-value (TLV) BGP message that provides information for instantiating services for tail routers.

[0052] In the case of VPWS service, the EVPN per EVI EAD route is used to advertise the reachability of the new service. Along with this route, new BGP path transition attributes are also defined, a portion of which... Figure 3 The diagram shows what is referred to as BGP service request attributes. BGP service request attributes are defined as a set of elements encoded in a TLV-based format. Service request TLVs can exist in BGP service request attributes appended to EVPN type 1 by EVI / EAD NLRI, and the example format is shown in [example format]. Figure 3 As shown in the image.

[0053] Generally, a service request TLV 302 may have a type "1" and a length of 306 "X", which is the total length in bytes of the value portion of the TLV. The service request TLV 302 may include a request ID 308, which may be a 4-byte value provided by the headend router 104. The request ID 308 can be used for various purposes, such as handling duplicate requests. The service request TLV 302 may also include a service ID 310, which may be a 4-byte value identifying the service to be instantiated. In the case of VPWS, the service ID 310 may be equivalent to an Ethernet tag ID. The service ID 310 may be used to describe a specific template ID that describes the service to be instantiated and is known to the tail router 106. The service request TLV may also include the MAC address 312 of the port to which the user of the device is mounted, and one or more VLAN tags 316, which may be Ethernet tag values ​​enabled by the mounting router 106, and may be single-tag or dual-tag VIDs.

[0054] Figure 4 Figure 400 illustrates an example of a Service Acknowledgment TLV 402 (SAIT) message that a tail router can send to a head router. The SAIT TLV 402 can exist in the BGP Service Request attributes appended to EVPN Type 1 by EVI / EAD NLRI and has… Figure 4 The example format shown is (the format may differ in some examples). Type 404 can be "2", and length 406 can be "X", where "X" is the total length in bytes of the value portion of TLV 402. Additionally, the service acknowledgment TLV 402 may include a request ID 408 (which may be a 4-byte value provided by the headend router 104 in the service request TLV) and a service ID 410 (which may be a 4-byte value identifying the service enabled by the tail router 106). The service acknowledgment TLV 402 may also include an IP length 412, which is the length of the tail router 106's IP address (e.g., IPv6, IPv4, etc.). Furthermore, the service acknowledgment TLV 402 may include a tail IP address 414, which is the actual IPv4 or IPv6 address of the tail router 106 that has instantiated the service.

[0055] Figure 5 Figure 500 illustrates an example of a service attribute TLV in a BGP message that indicates traffic processing parameters communicated by a service on a tail router.

[0056] Service attribute TLV 502 can exist in the BGP service request attributes appended to EVPN type 1 by EVI / EAD NLRI, and has the following characteristics: Figure 5The example format shown is valid (other formats may be used). This format can be extended or modified. The Service Attribute TLV can be extended or modified based on network operator requirements. Type 504 can be "3" and length can be "X", indicating the total length in bytes of the value portion of Service Attribute TLV 502. Service Attribute TLV 502 may include a QoS field 508, which indicates the QoS metric of the service, such as the amount of bandwidth allowed on the service. Additionally, Service Attribute TLV 502 may include an MTU setting 510, which defines the maximum packet size that the service can transmit to avoid fragmentation or packet loss, etc.

[0057] Although not illustrated, Service Attribute TLV 502 can be extended to include additional attributes such as VLAN actions / rewrites (e.g., push, pop, switch operations), segment routing ODN parameters, the use of predefined Ethernet source and destination MAC addresses, and so on. Similarly, the list in Service Attribute TLV 502 can also be enhanced with Layer 3 or multicast-specific attributes.

[0058] Figure 6 Figure 600 illustrates a service measurement TLV 602, which is a BGP message indicating the metrics to be collected by the tail router that instantiates the service.

[0059] Service measurement TLV 602 can exist in the BGP service request attributes appended to EVPN type 1 by EVI / EAD NLRI, and has the same... Figure 6 The format is similar to that shown, but it can be modified or different in some examples. The format can also be extended or modified. Type 604 can be type "4", and the service measurement TLV 602 can include a headend timestamp field 606. The headend timestamp 606 can be a 4-byte value provided by the headend router 104, and its purpose is to measure round-trip latency (request / acknowledgment). The network operator 110 can then determine how much time was spent instantiating and enabling a new service on the tail router 106.

[0060] Figure 7 Figure 700 illustrates a sample Yang data TLV 702, which may include a BGP message containing Yang data for instantiating the tail router of the service.

[0061] Service Yang data TLV 702 can exist in the BGP service request attributes attached to EVPN type 1 by EVI / EAD NLRI, and has the following characteristics: Figure 7The format shown is valid, but it can be extended or modified in some examples. Service Yang Data TLV 702 can have a type 704 of "5" and include Yang data, which can be a string value carrying a Yang data model. Service Yang Data TLV 702 provides network operator 110 with a flexible way to use the Yang data model to make direct requests as if the request came from the controller via the Netconf / Yang API.

[0062] Figure 8 and Figure 9 Flowcharts for example methods 800 and 900 are shown, illustrating at least part of the methods described above. Figures 1-7 This article describes various aspects of the functionality performed by devices in a distributed application architecture as described in [the previous text]. Figure 8 and Figure 9 The described logical operations can be (1) implemented as a sequence of computer-implemented actions or program modules running on a computing system and / or (2) implemented as interconnected machine logic circuits or circuit modules within the computing system.

[0063] The implementation of the various components described herein depends on the choice of computing system performance and other requirements. Therefore, the logical operations described herein are referred to differently as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented using software, firmware, special-purpose digital logic, and any combination thereof. It should also be understood that it is possible to perform operations that are more complex than... Figure 8 and Figure 9 The operations shown and described herein may be more or fewer. These operations may also be performed in parallel or in a different order than those described herein. Some or all of these operations may also be performed by components other than those specifically identified. While the techniques described in this disclosure are referenced to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or components of any configuration.

[0064] Figure 8 The diagram illustrates a flowchart of an example method 800 in which a headend router 104 provides instantiation information to a tailend router 106 using a protocol. This instantiation information can be used to instantiate a service on the tailend router 106. The method may involve a first router (e.g., headend router 104) providing instantiation information to a second router (e.g., tailend router 106) using a protocol (e.g., BGP or another routing protocol), which can then be used to instantiate a service on the second router.

[0065] At 802, the first router can receive input from the network operator that enables the service to be instantiated on the first router. For example, the network operator 110 can provide configuration information to the first router, which enables the first router to provide the service.

[0066] At 804, the first router may generate an advertisement message indicating the service instantiated on the first router and the path associated with reaching the service on the first router. For example, headend router 104 may generate advertisement message 114 indicating that a service is instantiated and one or more paths are used to reach the service instantiated on headend router 104.

[0067] At 806, the first router may populate the advertisement message with service request attributes, which include information for enabling the service on the second router. For example, the headend router 104 may populate the advertisement message 114 with information that the tailend router 106 can use to instantiate the service. In some cases, this information may include a service identifier and service location information, where the service identifier indicates the service requested to be enabled on the second router, and the service location information indicates the location where the second router enables the service.

[0068] At point 808, the first router can send an advertisement message including service request attributes to the second router. For example, the head router 104 can send an advertisement message 114 to the tail router 106, instructing it to enable the service on the tail router 106.

[0069] Figure 9 The diagram illustrates a flowchart of an example method 900 where the tail router instantiates a service using instantiation information provided by the head router.

[0070] At 902, the trailing router 106 can receive an advertisement message from the leading router. In some cases, the advertisement message may include an indication of a path and a service request attribute associated with reaching a service instantiated on the leading router, the service request attribute including a request for the trailing router to instantiate the service.

[0071] At 904, the trailing router 106 can instantiate the service, at least in part, based on the request. At 906, the trailing router 106 can send an acknowledgment message to the leading router, indicating that the service has been instantiated on the trailing router.

[0072] Figure 10 An example computer architecture is shown for a computer 1000 capable of executing program components for implementing the functions described above. Figure 10The computer architecture shown illustrates conventional routers, switches, nodes, or other computing devices and can be used to execute any of the software components proposed herein. In some examples, computer 1000 may correspond to headend router 104, tailend router 106, and / or another device described herein, and may include networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

[0073] Computer 1000 includes a substrate 1002, or “motherboard,” which is a printed circuit board to which many components or devices can be connected via a system bus or other electrical communication path. In an exemplary configuration, one or more central processing units (CPUs) 1004 operate in conjunction with a chipset 1006. The CPU 1004 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of computer 1000.

[0074] The CPU 1004 performs operations by transitioning from one discrete physical state to the next, where state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements typically include electronic circuitry, such as flip-flops, that maintains one of two binary states, and electronic circuitry, such as logic gates, that provides the output state based on a logical combination of the states of one or more other switching elements. These basic switching elements can be combined to create more complex logic circuits, including registers, adder-subtractor units, arithmetic logic units, floating-point units, and so on.

[0075] Chipset 1006 provides an interface between CPU 1004 and the remaining components and devices on substrate 1002. Chipset 1006 may provide an interface with RAM 1008, which is used as main memory in computer 1000. Chipset 1006 may further provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 1010 or non-volatile RAM (NVRAM), for storing basic routines that facilitate booting computer 1000 and transferring information between various components and devices. ROM 1010 or NVRAM may also store other software components necessary for the operation of computer 1000 according to the configuration described herein.

[0076] Computer 1000 can operate in a networked environment, using logical connections to remote computing devices and computer systems via a network (e.g., network 1024). Chipset 1006 may include functionality for providing network connectivity via NIC 1012 (e.g., a Gigabit Ethernet adapter). NIC 1012 enables computer 1000 to connect to other computing devices via network 1024. It should be understood that multiple NICs 1012 may be present in computer 1000 to connect the computer to other types of networks and remote computer systems.

[0077] Computer 1000 can be connected to storage device 1018, which provides non-volatile storage for the computer. Storage device 1018 can store operating system 1020, programs 1022, and data, which have been described in more detail herein. Storage device 1018 can be connected to computer 1000 via storage controller 1014, which is connected to chipset 1006. Storage device 1018 can consist of one or more physical storage units. Storage controller 1014 can be connected to physical storage units via a serial-attached SCSI (SAS) interface, a serial advanced technology attachment (SATA) interface, a fiber channel (FC) interface, or other types of interfaces used for physical connection and data transfer between the computer and physical storage units.

[0078] Computer 1000 can store data on storage device 1018 by changing the physical state of physical storage units to reflect the stored information. In different embodiments of this specification, the specific changes in physical state can depend on various factors. Examples of such factors include, but are not limited to, the technology used to implement the physical storage units, whether storage device 1018 is characterized as primary or secondary storage, etc.

[0079] For example, computer 1000 can store information in storage device 1018 by issuing instructions through storage controller 1014 to change the magnetic properties of a specific location within a disk drive unit, the reflection or refraction properties of a specific location in an optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in a solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of this specification; the foregoing examples are provided merely for convenience. Computer 1000 can further read information from storage device 1018 by detecting the physical state or characteristics of one or more specific locations within the physical storage unit.

[0080] In addition to the aforementioned high-capacity storage device 1018, computer 1000 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. Those skilled in the art will understand that a computer-readable storage medium is any available medium that provides non-transitory storage of data and is accessible by computer 1000. In some examples, operations performed by devices such as headend router 104, tailend router 106, etc., and / or any components included therein, may be supported by one or more devices similar to computer 1000. In other words, some or all of the operations performed by headend router 104, tailend router 106, and / or any components included therein, may be performed by one or more computer devices 1000.

[0081] By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory or other solid-state storage technologies, compact disc ROM (CD-ROM), digital versatile disc (DVD), high-definition DVD (HD-DVD), Blu-ray or other optical storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information in a non-transitory manner.

[0082] As briefly mentioned above, storage device 1018 may store operating system 1020 used to control the operation of computer 1000. According to one embodiment, the operating system includes a LINUX operating system. According to another embodiment, the operating system includes a MICROSOFT operating system from Redmond, Washington. The server operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be used. Storage device 1018 may store other systems, applications, and data used by computer 1000.

[0083] In one embodiment, storage device 1018 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computer 1000, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform computer 1000 by specifying how CPU 1004 transitions between states. According to one embodiment, computer 1000 has access to a computer-readable storage medium storing computer-executable instructions that, when executed by computer 1000, perform the above-described... Figures 1-9 The various processes described herein. The computer 1000 may also include a computer-readable storage medium storing instructions for performing any other computer-implemented operations described herein.

[0084] The computer 1000 may also include one or more input / output controllers 1016 for receiving and processing input from a number of input devices, such as a keyboard, mouse, touchpad, touchscreen, stylus, or other types of input devices. Similarly, the input / output controllers 1016 may provide output to a display, such as a computer monitor, flat panel display, digital projector, printer, or other types of output devices.

[0085] As described herein, computer 1000 may include one or more of a headend router 104, a tailend router 106, and / or other devices. Computer 1000 may include one or more hardware processors 1004 (processors) configured to execute one or more stored instructions. The processors 1004(s) may include one or more cores. Additionally, computer 1000 may include one or more network interfaces configured to provide communication between computer 1000 and other devices, such as the communication described herein performed by headend router 104 and / or tailend router 106. Network interfaces may include devices configured to couple to a personal area network (PAN), wired and wireless local area network (LAN), wired and wireless wide area network (WAN), etc. For example, network interfaces may include interfaces with Ethernet, Wi-Fi, etc. TM Compatible devices, etc.

[0086] Program 1022 may include any type of program or process so that the headend router 104 and / or the tailend router 106 perform the techniques described in this disclosure.

[0087] In summary, this paper describes a technique for head nodes in one or more autonomous network systems to instantiate services on tail nodes using a protocol. Head nodes can use a service request mechanism enabled by the protocol to request service instantiation on tail nodes without requiring network operators to manually configure or even access the tail nodes. Furthermore, the protocol provides mechanisms to define processing attributes for service traffic (e.g., Quality of Service (QoS) attributes, Maximum Transmission Unit (MTU) settings, etc.), service acknowledgment mechanisms for head nodes to determine if a service has been instantiated on a tail node, and so on. Thus, head nodes can be used to instantiate services on tail nodes without requiring network operators to manually configure the tail nodes through direct access.

[0088] Although the invention has been described with reference to specific examples, it should be understood that the scope of the invention is not limited to these specific examples. Since other modifications and variations made to adapt to specific operational requirements and environments will be apparent to those skilled in the art, the invention is not to be considered limited to the examples chosen for disclosure purposes, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the invention.

[0089] While this application describes embodiments with specific structural features and / or methodological actions, it should be understood that the claims are not necessarily limited to the specific features or actions described. Rather, the specific features and actions merely illustrate some embodiments that fall within the scope of the claims of this application.

Claims

1. A method for a first router to provide instantiation information, which can be used to instantiate services on the second router, to a second router using a protocol, the method comprising: The system receives input from the network operator at the first router, which causes the service to be instantiated on the first router. An announcement message is generated at the first router, the announcement message indicating the service instantiated on the first router and the path associated with reaching the service on the first router; The announcement message is populated with service request attributes, which include information for enabling the service on the second router, including: A service identifier, indicating the service requested to be enabled on the second router; and Service location information, which indicates the location where the second router enables the service; and The first router sends the announcement message, which includes the service request attributes, to the second router. The protocol is Border Gateway Protocol (BGP), which provides BGP path attributes associated with the path indicated in the announcement message. The BGP path attributes are a collection of elements encoded as type-length-value (TLV).

2. The method of claim 1, wherein: The service request attribute is a service request TLV that includes the information mentioned above. and The service location information includes: The media access control (MAC) address associated with mounting the service onto the second router; as well as Instructions for a Virtual Local Area Network (VLAN) are provided, in which the service is carried over to the second router via the VLAN.

3. The method as described in claim 1 or 2, wherein, The method further includes: The notification message is populated using a service acknowledgment TLV, wherein the service acknowledgment TLV includes: The service identifier indicating that the service is enabled on the second router; and The Internet Protocol (IP) address associated with the second router.

4. The method of claim 3, further comprising: Instantiate the service on the second router; and The second router sends an acknowledgment message to the first router, the acknowledgment message indicating that the service has been instantiated on the second router.

5. The method as described in claim 1 or 2, wherein, The method further includes: The notification message is populated with a service attribute TLV, wherein the service attribute TLV includes at least one of the following: Quality of Service (QoS) information indicating the amount of bandwidth allocated to the service; or The maximum transmission unit (MTU) of the packets conveyed by the service.

6. The method as described in claim 1 or 2, wherein, The method further includes: The notification message is populated with a service measurement TLV, which includes a request for measurement information indicating the round-trip delay associated with the notification message and the acknowledgment message.

7. The method of claim 6, further comprising sending an acknowledgment message from the second router to the first router, the acknowledgment message including the measurement information.

8. A headend router, comprising: One or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform operations, the operations including: Receive input from the network operator, which causes the service to be instantiated on the headend router; An announcement message is generated according to the protocol, which indicates the service instantiated on the headend router and the path associated with reaching the service on the headend router; The announcement message is populated with service request attributes, which include information for enabling the service on the tail router, including: Indicates the service identifier of the service requested to be enabled on the tail router; and Service location information indicating the location where the tail router enables the service; and Send the announcement message, including the service request attributes, to the tail router. The protocol is Border Gateway Protocol (BGP), which provides BGP path attributes associated with the path indicated in the announcement message. The BGP path attributes are a collection of elements encoded as type-length-value (TLV).

9. The headend router as described in claim 8, wherein: The service request attribute is a service request TLV that includes the information mentioned above. and The service location information includes: The media access control (MAC) address associated with carrying the service to the tail router; as well as Instructions for a Virtual Local Area Network (VLAN) are provided, in which the service is carried over to the tail router via the VLAN.

10. The headend router as described in claim 8 or 9, further comprising: The notification message is populated using a service acknowledgment TLV, wherein the service acknowledgment TLV includes: The service identifier indicating that the service is enabled on the tail router; and The Internet Protocol (IP) address associated with the tail router.

11. The headend router as described in claim 10, further comprising: Instantiate the service on the tail router; The tail router sends an acknowledgment message to the head router, the acknowledgment message indicating that the service has been instantiated on the tail router.

12. The headend router as described in claim 8 or 9, wherein, Also includes: The notification message is populated with a service attribute TLV, wherein the service attribute TLV includes at least one of the following: Quality of Service (QoS) information indicating the amount of bandwidth allocated to the service; or The maximum transmission unit (MTU) of the packets conveyed by the service.

13. The headend router as described in claim 8 or 9, wherein, Also includes: The notification message is populated with a service measurement TLV, which includes a request for measurement information indicating the round-trip delay associated with the notification message and the acknowledgment message.

14. The headend router as described in claim 13, further comprising: The tail router sends an acknowledgment message to the head router, the acknowledgment message including the measurement information.

15. A method for a tail-end router to instantiate a service using instantiation information provided by a head-end router, the method comprising: The tail router receives an announcement message from the head router, the announcement message including: An indication of a path, which is associated with reaching a service instantiated on the headend router; and Service request attributes, including a request to require the tail router to instantiate the service; and The service is instantiated on the tail router at least in part based on the request. The notification message is sent using the Border Gateway Protocol (BGP), which provides BGP path attributes associated with the path indicated in the notification message. The BGP path attributes are a set of elements encoded as type-length-value (TLV) elements.

16. The method of claim 15, wherein: The service request attribute is a service request TLV that includes the following: The media access control (MAC) address associated with carrying the service to the tail router; as well as Instructions for a Virtual Local Area Network (VLAN) are provided, in which the service is carried over to the tail router via the VLAN.

17. The method of claim 15 or 16, wherein: The notification message includes a service confirmation TLV, which includes: Indicates the service identifier that the service is enabled on the tail router; and The Internet Protocol (IP) address associated with the tail router.

18. The method of claim 17, further comprising sending an acknowledgment message from the tail router to the head router, the acknowledgment message indicating that the service has been instantiated on the tail router.

19. The method of claim 15 or 16, wherein: The notification message includes a service attribute TLV, which includes at least one of the following: Quality of Service (QoS) information indicating the amount of bandwidth allocated to the service; or The maximum transmission unit (MTU) of the packets conveyed by the service.

20. The method of claim 15 or 16, wherein: The service request attribute is a service request TLV that includes the following: The media access control (MAC) address associated with carrying the service to the tail router; as well as Instructions for a Virtual Local Area Network (VLAN) are provided, in which the service is carried over to the tail router via the VLAN.

21. A headend router, comprising: A device for receiving input from a network operator, which causes a service to be instantiated on the headend router; A means for generating, according to a protocol, an announcement message indicating a service instantiated on the headend router and a path associated with the service on the headend router; Means for populating the announcement message with service request attributes including information for enabling the service on the tail router, the information including: Indicates the service identifier of the service requested to be enabled on the tail router; and Service location information indicating the location where the tail router enables the service; and A means for sending the announcement message, including the service request attributes, to the tail router. The protocol is Border Gateway Protocol (BGP), which provides BGP path attributes associated with the path indicated in the announcement message. The BGP path attributes are a collection of elements encoded as type-length-value (TLV).

22. The headend router of claim 21, further comprising means for implementing the method of any one of claims 2 to 7.

23. A tail router that instantiates a service using instantiation information provided by a head-end router, the tail router comprising: A means for receiving an announcement message from a headend router, the announcement message including: An indication of the path associated with reaching the service instantiated on the headend router; and This includes the service request attribute of the request that requires the tail router to instantiate the service; and A means for instantiating the service on the tail router at least in part based on the request. The notification message is sent using the Border Gateway Protocol (BGP), which provides BGP path attributes associated with the path indicated in the notification message. The BGP path attributes are a set of elements encoded as type-length-value (TLV) elements.

24. The tail router of claim 23, further comprising means for implementing the method of any one of claims 16 to 20.

25. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method as claimed in any one of claims 1 to 7 or any one of claims 15 to 20.

26. A computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method as claimed in any one of claims 1 to 7 or any one of claims 15 to 20.

Images