Patent Publication Number: US-9887766-B2

Title: Layer-2 extension services

Description:
PRIORITY CLAIM 
     This application is a continuation of U.S. patent application Ser. No. 14/325,533, entitled LAYER-2 EXTENSION SERVICES, filed Jul. 8, 2014; which is a continuation of U.S. patent application Ser. No. 12/761,882, entitled, LAYER-2 EXTENSION SERVICES, filed Apr. 16, 2010; which claims priority to U.S. Provisional Application No. 61/170,359, entitled DISTRIBUTED BASE STATION SATELLITE TOPOLOGY filed on Apr. 17, 2009, and also claims priority to U.S. Provisional Application No. 61/254,554, entitled LAYER-2 EXTENSION SERVICES, filed on Oct. 23, 2009, each of which are incorporated by reference in their entirety for any and all purposes. 
    
    
     FIELD 
     The present invention relates, in general, to ground segment networks, and more particularly, to non-routed backhaul ground segment networks. 
     BACKGROUND 
     Satellite communications system are becoming ubiquitous for communicating large amounts of data over large geographic regions. In typical satellite communications systems, end consumers interface with the systems through user terminals. The user terminals communicate, via one or more satellites, with one or more gateways. The gateways may then process and route the data to and from one or more networks according to various network protocols and tags processed at the network layer and above (e.g., layers 3 and above of the Open System Interconnection Reference Model (OSI) stack). 
     While utilizing higher layers to route communications may provide certain features, such as enhanced interoperability, it may also limit certain capabilities of the network. For example, routing limits the types of tags that can persist across multiple sub-networks. For these and/or other reasons, it may be desirable to provide ground-segment networking with enhanced functionality. 
     SUMMARY OF THE INVENTION 
     In one embodiment, a method of providing layer-2 extension services through a non-routed ground segment network, is described. The method includes providing a Layer-2 (L2) interface between a node of the non-routed ground segment network and a service provider, assigning a virtual tagging tuple to the service provider and receiving service provider traffic at a node of the non-routed ground segment network. The method further includes tagging the service provider traffic with the virtual tagging tuple, and switching the tagged service provider traffic through the non-routed ground segment network according to the virtual tagging tuple. 
     A system for providing layer-2 extension services through a non-routed ground segment network, is described. The system includes a plurality of nodes of the non-routed ground segment network. The nodes are in communication with each other over a substantially persistent layer-2 connection. The system further includes a first node is locally coupled with a layer-2 network associated with a service provider. The service provider being associated with a virtual tagging tuple. The system also includes a second node is in operative communication with a plurality of customers. The second node being geographically remote from the first node. At least a portion of traffic communicated with the plurality of customers and associated with the service provider is tagged with the virtual tagging tuple, and each of the plurality of nodes is configured to switch the portion of the traffic at L2 according to the virtual tagging tuple. 
     In further embodiment, a machine-readable medium for providing layer-2 extension services through a non-routed ground segment network, is described. The machine-readable medium includes instructions for providing a Layer-2 (L2) interface between a node of the non-routed ground segment network and a service provider, assigning a virtual tagging tuple to the service provider and receiving service provider traffic at a node of the non-routed ground segment network. The machine-readable medium further includes instructions for tagging the service provider traffic with the virtual tagging tuple, and switching the tagged service provider traffic through the non-touted ground segment network according to the virtual tagging tuple. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       A further understanding of the nature and advantages of the present invention may be realized by reference to the remaining portions of the specification and the drawings wherein like reference numerals are used throughout the several drawings to refer to similar components. In some instances, a sublabel is associated with a reference numeral to denote one of multiple similar components. When reference is made to a reference numeral without specification to an existing sublabel, it is intended to refer to all such multiple similar components. 
         FIG. 1  illustrates a typical satellite communications system having a typical gateway in communication with a routed network. 
         FIG. 2  shows an embodiment of a satellite communications system having a number of user terminals in communication with a non-autonomous gateway via a satellite, according to various embodiments. 
         FIG. 3  shows an embodiment of a satellite communications system having a user terminal in communication with a non-autonomous gateway via a satellite, where the non-autonomous gateway is further in communication with nodes of a non-routed ground segment network using virtual tagging tuples, according to various embodiments. 
         FIG. 4A  shows an embodiment of a satellite communications system used for communication between two clients over a non-routed ground segment network, according to various embodiments. 
         FIG. 4B  shows an illustrative communication link for an enterprise customer in a system, like the one shown in  FIG. 4A . 
         FIG. 4C  shows an illustrative data flow through the communication link of  FIG. 4B . 
         FIG. 5 , an embodiment of a non-autonomous gateway is shown as part of a portion of a non-routed ground segment network, according to various embodiments. 
         FIG. 6  shows an embodiment of a communications system having multiple non-autonomous gateways, like the non-autonomous gateway of  FIG. 5 , in communication with a more detailed illustrative embodiment of a core node, according to various embodiments. 
         FIG. 7  shows embodiments of various modules in communication with one or more multilayer switches, according to various embodiments. 
         FIG. 8  shows an embodiment of an autonomous gateway, according to various embodiments. 
         FIG. 9  shows an embodiment of a satellite communications system that distributes autonomous gateways and non-autonomous gateways across a number of geographically dispersed regions, according to various embodiments. 
         FIG. 10  shows an embodiment of a portion of a communications system configured to facilitate layer-2 extension services, according to various embodiments. 
         FIG. 11  shows a flow diagram of a method for providing layer-2 extension services across a non-routed ground segment network, according to various embodiments. 
         FIG. 12  is a simplified block diagram illustrating the physical components of a computer system that may be used in accordance with an embodiment of the present invention. 
     
    
    
     DESCRIPTION 
     The ensuing description provides exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing an exemplary embodiment, it being understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims. Some of the various exemplary embodiments may be summarized as follows. 
     In many typical satellite communications systems, end consumers interface with the systems through user terminals. The user terminals communicate, via one or more satellites, with one or more gateways. The gateways may then process and route the data to and from one or more networks according to various network protocols and tags processed at the network layer and above (e.g., layers 3 and above of the Open System Interconnection Reference Model (OSI) stack). 
     For example,  FIG. 1  illustrates a typical satellite communications system  100 . The satellite communications system  100  include a number of user terminals  130  in communication with a gateway  115  via a satellite  105 . For example, a subscriber of satellite communications services desires to access a web page using a browser. The subscriber&#39;s client  160  (e.g., a client application running on customer premises equipment controlled by the subscriber) may communicate an HTML request through a respective one of the user terminals  130 . A user antenna  135  in communication with the respective user terminal  130  communicates the request to the satellite  105 , which, in turn, sends the request to the gateway  115  through a provider antenna  125 . 
     The gateway  115  receives the request at a base station  145  configured to service that user terminal  130  and included with a satellite modem terminal system (SMTS)  140 . The SMTS  140  sends the request data to a routing module  150 , in communication with a gateway module  155 . The routing module  150  and gateway module  155  work together to determine and generate routing data for communicating the request data through a routed ground segment network  120 . Typically, the gateway module  155  may be a control plane application which sets up connectivity to the router. Even where actual routing is not done by the gateway module  155 , components of the gateway  115  may implement routing functions. 
     As used herein, a “routed network” refers to a network having a number of routers, configured to use protocols at layer-3 and above the OSI stack (e.g., or substantially equivalent types of protocols) to route data through the network. The “routing module”, as used herein, is intended to broadly include any type of network device configured to route at layers 3 and above the OSI stack (e.g., or provide substantially similar network layer functionality). Particularly, routing is intended to be distinguished from switching (e.g., at layer 2 of the OSI stack (e.g., or substantially similar functionality), as will become more clear from the description below. 
     While utilizing higher layers to route communications may provide certain features, such as enhanced interoperability, it may also limit certain capabilities of the network. As one exemplary limitation, at each node where a layer-3 routing decision is made, determining the appropriate routing may involve parsing packet headers, evaluating parsed header information against routing tables and port designations, etc. The steps may limit the amount and type of traffic that can be sent over the network, as well as the protocols available for transport on the network. 
     In another exemplary limitation, at each router, layer-2 headers are typically stripped off and replaced with other tags to identify at least the next routing of the data through the network. As such, it is impossible to maintain a single network between routed terminals. In other words, a packet which is generated at one LAN, passes through one or more routers (i.e., at layer-3 or above) and is received at another LAN, will always be considered to be received from a different network. Accordingly, any benefit of a single network configuration is unattainable in a layer-3 routed network. For example, tags for supporting proprietary service provider networks, Multiprotocol Label Switching (MPLS), and/or other types of networks are impossible to maintain across large geographic regions (e.g., multiple LANs, WANs, subnets, etc.) of a routed ground segment network  120 . 
     In the illustrative example, internet protocol (IP) and/or other tags are used to route the request data to an appropriate IP address for use in satisfying the subscriber&#39;s request. When a response to the request is received by the routed ground segment network  120 , layer-3 and/or higher-layer tags are again used to route the response data through the network to the appropriate base station  145  in the appropriate gateway  115 . The base station  145  then communicates the response data to the client  160  via the provider antenna  125 , the satellite  105 , the subscriber antenna  135 , and the user terminal  130 . 
     Embodiments address these limitations of the routed ground segment network  120  in various ways, for example, through the use of core nodes.  FIG. 2  shows an embodiment of a satellite communications system  200  having a number of user terminals  130  in communication with a non-autonomous gateway  215  via a satellite  105 , according to various embodiments. The non-autonomous gateway  215  is in communication with other nodes of a non-routed ground segment network  220  (e.g., other non-autonomous gateways  215 ) via one or more core nodes  265 . Embodiments of the satellite communications system  200  effectively provide mesh-like layer-2 connectivity between substantially all the nodes of the non-routed ground segment network  220 . 
     In various embodiments, components of the non-routed ground segment network  220  (e.g., components of the gateways  115 , core nodes  265 , etc.) are implemented, in whole or in part, in hardware. They may include one or more Application Specific Integrated Circuits (ASICs) adapted to perform a subset of the applicable functions in hardware. Alternatively, the functions may be performed by one or more other processing units, on one or more integrated circuits. In other embodiments, other types of integrated circuits may be used (e.g., Structured/Platform ASICs, Field Programmable Gate Arrays and other Sime-Custom ICs), which may be programmed. Each may also be implemented, in whole or in part, with instructions embodied in a computer-readable medium, formatted to be executed by one or more general or application specific controllers. 
     In various embodiments, the satellite  105  is geostationary satellite, configured to communicate with the user terminals  130  and gateways  115  using reflector antennae, lens antennae, array antennae, phased array antennae, active antennae, or any other mechanism for reception of such signals. In some embodiments, the satellite  105  operates in a multi-beam mode, transmitting a number of narrow beams, each directed at a different region of the earth. With such multi-beam satellite  105 , there may be any number of different signal switching configurations on the satellite  105 , allowing signals from a single gateway  115  to be switched between different spot beams. In one embodiment, the satellite  105  is configured as a “bent pipe” satellite, wherein the satellite  105  may frequency convert the received carrier signals before retransmitting these signals to their destination, but otherwise perform little or no other processing on the contents of the signals. In various embodiments, there could be a single carrier signal or multiple carrier signals for each service or feeder spot beam. In some embodiments, the subscriber antenna  135  and user terminal  130  together comprise a very small aperture terminal (VSAT), with the subscriber antenna  135  measuring less than one meter in diameter and having approximately 2 watts of power. In other embodiments, a variety of other types of subscriber antennae  135  may be used at the user terminal  130  to receive the signal from the satellite  105 . 
     In certain embodiments, the satellite communications system  200  has its nodes (e.g., non-autonomous gateways  215 , core nodes  265 , etc.) distributed over a large geographic region (e.g., across the United States of America). Each core node  265  may be configured to support up to twenty non-autonomous gateways  215 , each non-autonomous gateway  215  may be configured to support up to four user links, and each user link may support thousands of clients  160 . For example, the satellite  105  may operate in a multi-beam mode, transmitting a number of spot beams, each directed at a different region of the earth. Each spot beam may be associated with one of the user links, and used to communicate between the satellite  105  and thousands of user terminals  130 . With such a multi-beam satellite  105 , there may be any number of different signal switching configurations on the satellite  105 , allowing signals from a single gateway  115  to be switched between different spot beams. 
     In one illustrative case, a subscriber of satellite communications services desires to access a web page using a browser. The subscriber&#39;s client  160  (e.g., a client application running on customer premises equipment controlled by the subscriber) may communicate an HTML request through a respective one of the user terminals  130 . A user antenna  135  in communication with the respective user terminal  130  communicates the request to the satellite  105 , which, in turn, sends to the request to the non-autonomous gateway  215  through a provider antenna  125 . 
     The non-autonomous gateway  215  receives the request at a base station  245  configured to service that user terminal  130  and included with in a satellite modem termination system (SMTS)  240 . Unlike in  FIG. 1 , where the SMTS  140  sends the request data to a routing module  150 , the SMTS  240  of  FIG. 2  sends the request data to one or more layer-2 (L2) switches  247 . The L2 switches  247  forward the data to a core node  265  or other node of the non-routed ground segment network  220  according to layer-2 (e.g., or substantially equivalent) information. For example, unlike the router module  150  of  FIG. 1 , the L2 switches  247  may not expend substantial resources analyzing higher layer tags (e.g., parsing IP headers) and may not strip off tags for the sake of packet routing. Furthermore, all terminals, code nodes, non-autonomous gateways, autonomous gateways, etc., are all able to be on a single contiguous network. 
     In some embodiments, all data in the non-routed ground segment network  220  being communicated between two non-autonomous gateways  215  passes through at least one core node  265 . The core node  265  may include one or more multilayer switches  250  and a gateway module  255 . It is worth noting that, while embodiments of the typical gateway  115  of  FIG. 1  are shown to include gateway modules  155 , embodiments of the non-autonomous gateways  215  do not include gateway modules  255 . In some embodiments, the gateway module  255  of the core node  265  is substantially the same as the gateway module  155  of  FIG. 1 . 
     When data is received at the core node  265  it may be processed in a number of different ways by the one or more multilayer switches  250 . In some embodiments, the multilayer switches  250  process higher-layer information to provide certain types of functionality. For example, it may be desirable to handle packets in certain ways according to virtual private networking (VPN) tags, voice-over-IP (VoIP) designations, and/or other types of higher-layer information. 
     It is worth noting that embodiments of the multilayer switches  250  are configured to process routing-types of information without stripping data from the packets. In this way, embodiments of the satellite communications system  200  effectively provide mesh-like layer-2 connectivity between substantially all the nodes of the non-routed ground segment network  220 . One feature of this type of the layer-2 connectivity is that embodiments may perform higher layer processing only (e.g., or primarily) at the core nodes  265 , which may substantially speed up communications through the non-routed ground segment network  220 . Another feature is that embodiments of the non-routed ground segment network  220  may allow certain types of information (e.g., VPLS tags, proprietary network services tags, etc.) to persist across multiple sub-networks. These and other features will be further appreciated from the description below. 
     In some embodiments, the layer-2 connectivity across the non-routed ground segment network  220  is further enable through the use of virtual tagging tuples.  FIG. 3  shows an embodiment of a satellite communications system  300  having a user terminal  130  in communication with a non-autonomous gateway  215  via a satellite  105 , where the non-autonomous gateway  215  is further in communication with nodes of a non-routed ground segment network  220  using virtual tagging tuples  375 , according to various embodiments. As illustrated, the non-autonomous gateway  215  is in communication with other nodes of the non-routed ground segment network  220  via a tuple-enabled communication link  370 . 
     Embodiments of the tuple-enable communication link  370  are configured to carry traffic according to a virtual tagging tuple  375 . The virtual tagging tuple  375  may be configured to have one or more elements that virtually define information about data relevant to communicating the data through the non-routed ground segment network  220 . In one embodiment, the tuple-enable communication link  370  is implemented as a 10-Gigabit LAN PHY cable (an Ethernet cable configured according to certain local area network (LAN) physical layer (PHY) standards). 
     Each virtual tagging tuple  375  may “reserve” or “carve out” a certain portion of the tuple-enabled communication link  370  (e.g., the fiber trunk). Each portion may be associated with (e.g., purchased by) an entity. For example, the tuple-enabled communication link  370  may be virtually shared among a number of entities via the virtual tagging tuples  375 , and the allotment for each entity may be based on the amount carved out for the entity. For example, if the tuple-enabled communication link  370  represents ten Gigabits per second to “sell”, virtual tagging tuples  375  may be purchased in fractions of that link capacity (e.g., one Gigabit increments). Each entity may then be serviced according to a quality of service structure or other service level agreement, according to the capacity purchased. Further, each entity may be provided with certain types of functionality associated with one or more of its virtual tagging tuples  375 . 
     In one embodiment, the tuple-enabled communication link  370  is a fiber-optic trunk configured according to IEEE Standard 802.1 Q-2005 (available at http://standards.ieee.org/getieee802/download/802.1Q-2005.pdf). Each virtual tagging tuple  375  may be implemented as a “VLAN tag” according to the 802.1Q standard. For example, where the tuple has two elements, “double tagging”, or “Q-in-Q” tagging may be used according to the 802.1Q standard. 
     For example, a request for content (e.g., an HTML page, a document file, a video file, an image file, etc.: is sent from a client  160  client to a user terminal  130 . The request is transmitted up to the satellite  105  and back down to the non-autonomous gateway  215  via the subscriber antenna  135  and the provider antenna  125 . Components of the non-autonomous gateway  215  (e.g., one or more L2 switches  247 ) are configured to add virtual tagging tuples  375  to the data packets. 
     The virtual tagging tuples  375  added to the data packets may include an entity designation and a location of the entity, implemented as an ordered pair. For example, the entity may be “XYZ Corp”, with an entity designation of “205” (or some other numeric, alpha, or alphanumeric designation). Furthermore, “XYZ Corp.” may be associated with any number of locations. For example, “XYZ Corp.” may have locations in Denver, Colo., San Francisco, Calif. and Rapid City, S. Dak., and each of these locations may be assigned a location identifier. For example, Denver, Colo. may be assigned “001”, San Francisco, Calif. may be assigned “360”, and Rapid City, S. Dak. may be assigned “101”, as their location identifiers. Accordingly, virtual tagging tuple  375  “(205,001)” may indicate traffic associated with “XYZ Corp.” and destined for Denver, Colo., while virtual tagging tuple  375  “(205,001)” would indicate traffic associated with “XYZ Corp.” and destined for Rapid City, S. Dak. 
     Additional entity designations may be generated. For example, “Co.A” may have a “D24” designation, while “Co.C” may have a “450” designation. Furthermore, location identifiers may be used by multiple entities. For example, virtual tagging tuple  375  “(D24, 360)” may indicate traffic assigned to “Co.A” destined for San Francisco, Calif., while virtual tagging tuple  375  “(205,360)” indicates traffic assigned to “XYZ Corp.” also destined for San Francisco. Alternatively, each entity may have its own customized location identifier(s). 
     In various embodiments of the non-routed ground segment network  220 , the virtual tagging tuples  375  are used to communicate the packets throughout the network without using port-based routing, destination addresses, header parsing, etc. The packets may effectively be communicated among nodes of the non-routed ground segment network  220  as if the nodes are part of a single subnet. Even geographically remote non-autonomous gateways  215  may communicate as if part of a local area network (LAN). For example, as described above, based on virtual tagging tuple  375  entity and location designations, packets may be forwarded to designated locations anywhere in the non-routed ground segment network  220 . The virtual tagging tuples  375  may be used by gateway modules, switches, cross-connects, core nodes, peering routers, and/or any other node of the non-routed ground segment network  220 . 
     In various embodiments, clients  160  may use the satellite communications system  300  to communicate, via the non-routed ground segment network  220 , to any addressable location in communication with the non-routed ground segment network  220 . For example, clients  160  may communicate with service providers, the Internet, content delivery networks (CDNs), other clients  160 , etc.  FIG. 4A  shows an embodiment of a satellite communications system  400  used for communication between two clients  160  over a non-routed ground segment network  220 , according to various embodiments. In some embodiments, the satellite communications system  400  is substantially equivalent (e.g., an extended illustration of) the satellite communications system  200  of  FIG. 2 . 
     A first client  160   a  is in communication with a first non-autonomous gateway  215   a  via a respective subscriber antenna  135   a  and provider antenna  125 , and the satellite  105 . The first non-autonomous gateway  215   a  is in communication with one or more core nodes  265  (illustrated as a first core node  265   a  and an nth core node  265   n ). For example, data is communicated from the first client  160   a , destined for a second client  160   b . The data is received by a first base station  245   a  in a first SMTS  240  in the first non-autonomous gateway  215   a . The data is then switched by one or more first L2 switches  247   a  and sent over a first LAN PHY cable  370   a  to one or more first multilayer switches  250   a  in the first core node  265   a . In the first core node  265   a , the data from the first client  160   a  may be processed (e.g., interpreted, parsed, switched, etc.) at one or more layers by the first multilayer switches  250   a  and/or a first gateway module  255   a.    
     The first core node  265   a  is in communication with at least a second core node  265   b . The first core node  265   a  may determine, for example as a function of an associated virtual tagging tuple  375  or a higher-layer tag, that the data from the first client  160   a  should be passed to the second core node  265   b . The second core node  265   b  may further process the communications at one or more layers by second multilayer switches  250   b  and/or a second gateway module  255   b.    
     The second core node  265   b  may pass the data to an appropriate second non-autonomous gateway  215   b , for example, over a second LAN PHY cable  370   b . The second non-autonomous gateway  215   b  may then switch the data at layer 2 and pass the data to an appropriate second base station  245   b  in a second SMTS  240   b  in the second non-autonomous gateway  215   b . For example, the second base station  245   b  is configured to support (e.g., or is currently switched or tuned to support) a spot beam being used to service the second client  160   b . The second base station  245   b  may communicate the data from the second non-autonomous gateway  215   b  to the second client  160   b  via a respective provider antenna  125   b  and subscriber antenna  135   b , and the satellite  105 . 
     It is worth noting that, while the first core node  265   a  and/or the second core node  265   b  may process the data at multiple layers, embodiments of the core nodes  265  are configured to maintain layer-2 connectivity across the communication. In fact, the non-autonomous gateways  215 , core nodes  265 , and other nodes may all be part of a non-routed ground segment network (e.g., like the non-routed ground segment network  220  of  FIG. 2 ), an embodiments of the non-routed ground segment network may effectuate layer-2 connectivity between any two of its nodes. For example, the first non-autonomous gateway  215   a  and the second non-autonomous gateway  215   b  act as if they are on a single subnet (e.g., LAN), regardless of the number of nodes through which the data passes, the distance over which it is communicated, the number of sub-networks employed, etc. 
     It will be appreciated that a large non-routed ground segment network may include a number of different types of nodes, for example, to account for various client densities and locations, topologies (e.g., mountain ranges, lakes, etc.), etc. Furthermore, satellite communications network  400  enables, for example, client 1  160   a  and client 1  160   b  to function on the same network. As such, both clients are able to have an IP address on the same sub-net (e.g., 192.168.1*), receive the same services, receive a multicast or a broadcast message, etc. In other words, client 1 and client 2 are able to be connected in the same manner similar to if it were located in the same room connected to the same switch. 
     Of course many of these features further involve use of one or more types of data stack throughout a communication link. For example,  FIG. 4B  shows an illustrative communication link for an enterprise customer in a system in communication with an enterprise network  405 , like the one shown in  FIG. 4A , and  FIG. 4C  shows an illustrative data flow through the link in  FIG. 4B . As illustrated, the communication link  450  of  FIG. 4B  provides connectivity between enterprise customer premises equipment (CPE)  160  and an enterprise head-end  405 . Communications on the communication link  450  may pass from the enterprise remote site to a gateway  215  (e.g., from the CPE  160  to the gateway via a user terminal and a satellite link  105 ), from the gateway  215  to a core node  265  (e.g., from an L2 backhaul switch in the gateway to a gateway and L2/L3 switch in the core), and from the core to the enterprise head-end  405  (e.g., from the L2/L3 switch in the core to a peer router in the head-end via a leased line). The data flow  460  in  FIG. 4C  shows illustrative data stacks at various locations ( 410 ,  415 ,  420  and  425 ) in the communication link  450  of  FIG. 4B . It is worth noting, for example, that the bottom four layers of the illustrative data stack remains intact throughout the communication link  450 . 
     As discussed above, the non-routed ground segment network (e.g., like the network  400  of  FIG. 4A ) may include a number of different types of nodes in various types of configurations. Some of these different types of nodes and node configurations are described with reference to  FIGS. 5-9 . Turning first to  FIG. 5 , an embodiment of a non-autonomous gateway  215  is shown as part of a portion of a non-routed ground segment network  220 . 
     The non-autonomous gateway  215  includes a number of SMTSs  240 . Embodiments of each SMTS  240  include multiple base stations. For example, each base station may be implemented on a circuit card or other type of component integrates into the SMTS  240 . The illustrated non-autonomous gateway  215  includes four STMSs  240 , each in communication with two L2 switches  247 . For example, each SMTS  240  is coupled with both L2 switches  247  to provide redundancy and/or other functionality. Each L2 switch  247  may then be in communication) e.g., directly or via other nodes of the non-routed ground segment network  220  that are not shown) with one or more cores nodes  265 . For example, each L2 switch  247  may be in communication with a single core node  265 , so that the non-autonomous gateway  215  is effectively in substantially redundant communication with two core nodes  265 . 
     Embodiments of the non-autonomous gateway  215  are configured to support other types of communication, for example, with other networks. In one embodiments, one or more service providers are in communication with the non-routed ground segment network  220  via one or both of the L2 switches  247  or one or more of the core nodes  265 . In one embodiment, the non-autonomous gateway  215  includes an access router  560 . The access router  560  may be configured to interface with (e.g., provide connectivity with) one or more out-of-band networks  570 . 
     As described above, the L2 switches  247  in the non-autonomous gateway  215  are in communication with one or more core nodes  265  so as to facilitate persistent layer-2 connectivity.  FIG. 6  shows an embodiment of a communications system  600  having multiple non-autonomous gateways  215 , like the non-autonomous gateway  215  of  FIG. 5 , in communication with a more detailed illustrative embodiment of a core node  265 , according to various embodiments. As in  FIG. 5 , each non-autonomous gateway  215  includes multiple SMTSs  240 , each in communication with multiple L2 switches  247 . Each L2 switch  247  is shown to be in communication with a core node  265 , so that the non-autonomous gateway  215  is effectively in substantially redundant communication with multiple core nodes  265 . Further, in some embodiments, each core node  265  is in communication with each other core node  265 , either directly or indirectly. for example, the core nodes  265  may be in communication in a ring-like topology, a mesh-like topology, etc. 
     As discussed above, the non-autonomous gateways  215  communicate with the core nodes  265  using layer-2 connectivity between one or more L2 switches  247  in the non-autonomous gateways  215  and one or more multilayer switches  250  in the core nodes  265 . The illustrative first core node  265 - 1  is in communication with multiple-non-autonomous gateways  215  via two multilayer switches  250 . In various embodiments, the multilayer switches  250  are in communication with each other either directly or indirectly (e.g., via a gateway module  255 ). 
     In some embodiments, the gateway module  255  includes one or more processing components for processing traffic received at the multilayer switches  250 . In one embodiment, the gateway module  255  includes a traffic shaper module  645 . Embodiments of the traffic shaper module  645  are configured to help optimize performance of the communications system  600  (e.g., reduce latency, increase effective bandwidth, etc.), for example, by delaying packets in a traffic stream to conform to one or more predetermined traffic profiles. 
     The multiplayer switches  250  may further be in communication with one or more networks  605 . The networks  605  may include the internet  605   a , one or more CDNs  605   b , one or more MPLS or VPLS networks  605   c , etc. In some embodiments, the core node  265  includes an interface/peering node  670  for interfacing with these networks  605 . For example, an Internet service provider or CDN service provider may peer with the core node  265  via the interface/peering node  670 . 
     Embodiments of the multilayer switches  250  process data by using one or more processing modules in communication with the multilayer switches  250 . For example, as illustrated, the multilayer switches  250  may be in communication with acceleration modules  650 , provisioning modules  655 , and/or management modules  660 . Communications with some or all of these modules may be protected using components, like firewalls  665 . For example, certain modules may have access to (and may use) private customer data, proprietary algorithms, etc., and it may be desirable to insulate that data from unauthorized external access. In fact, it will be appreciated that many types of physical and/or logical security may be used to protect operations and data of the core nodes  265 . For example, each core node  265  may be located within a physically secured facility, like a guarded military-style installation. 
       FIG. 7  shows embodiments of various modules in communication with one or more multilayer switches  250 , according to various embodiments. As in the first core node  265 - 1  of  FIG. 6 ,  FIG. 7  shows multilayer switches  250  in communication with acceleration modules  650 , provisioning modules  655 , and management modules  660 . The multilayer switches  250  are in communication with the provisioning modules  655  and management modules  660  via a firewall  665 . It is worth noting that the illustrated modules are intended only to show one non-limiting embodiment. Many other types of modules, units, groupings, configurations, etc., are possible according to other embodiments. 
     In one embodiment, the acceleration modules  650  include beam-specific acceleration modules  702  and a failover module  704  which detects a connection failure and redirects network traffic to a backup or secondary connection. Embodiments of the acceleration modules  650  provide various types of application. WAN/LAN, and/or other acceleration functionality. In one embodiment, the acceleration modules  650  implement functionality of AcceleNet applications from intelligent Compression Technologies, Inc. (“ICT”), a division of ViaSat, Inc. This functionality may be used to exploit information from higher layers of the protocol stack (e.g., layers 4-7 of the OSI stack) through use of software or firmware operating in each beam-specific acceleration module  702 . The acceleration modules  650  may provide high payload compression, which may allow faster transfer of the data and enhances the effective capacity of the network. In some embodiments, real-time types of data (e.g., User Datagram Protocol (UDP) data traffic) bypass the acceleration modules  650 , while non-real-time types of data (e.g., Transmission Control Protocol (TCP) data traffic) are routed through the accelerator modules  350  for processing. For example, IP television programming may bypass the acceleration modules  650 , while web video may be sent to the acceleration modules  650  from the multilayer switches  250 . 
     In one embodiment, the provisioning modules  655  include a AAA/Radius module  712 , a DHCP/DNS module  714 , a TFTP/NTP module  716 , and a PKI modules  718 . Embodiments of the AAA/Radius module  712  perform certain types of authentication and accounting functionality. For example, the AA/Radius module  712  may implement functionality of an Authentication Authorization Accounting (AAA) server, a Remote Authentication Dial-In User Service (RADIUS) protocol, an Extensible Authentication Protocol (EAP), a network access server (NAS), etc. Embodiments of the DHCP/DNS module  714  implement various IP management functions, including Dynamic Host Configuration Protocol (DHCP) interpretation, Domain Name System (DNS) look-ups and translations, etc. Embodiments of the TFTP/NTP module  716  implement various types of protocol-based functions, including file transfer protocols (e.g., File Transfer Protocol (FTP), trivial file transfer protocol (TFTP), etc.), synchronization protocols (e.g., Network Time Protocol (NTP)), etc. Embodiments of the PKI module  718  implement various types of encryption functionality, including management of Public Key Infrastructures (PKIs), etc. 
     In one embodiment, the management modules  660  includes an authentication/accounting module  722 , a terminal/shell modules  724 , a packet analysis module  726 , an SNMP/Syslog modules  728 , etc. Embodiments of the authentication/accounting module  722  implement various authentication and accounting functions that may be similar to or different from those of the AAA/Radius module  712 . For example, the authentication/accounting module  722  may control certain billing functions, handle fair access policies (FAPs), etc. Embodiments of the terminal/shell module  724  implement various types of connectivity with individual devices. Embodiments of the packet analysis module  726  implement various packet analysis functions. For example, the packet analysis module  726  may collect packet-level information and/or statistics for use in certain types of accounting functions. Embodiments of the SNMP/Syslog module  728  implement various network protocol management and logging functions. For example, the SNMP/Syslog module  728  may use the Simple Network Management Protocol (SNMP) to expose network management information and the Syslog standard to log network messages. 
     It is worth noting that the functionality of the various modules is described as occurring within one or more core modules  265 , and the core modules are in communication with a distributed network of non-autonomous gateways  115  and/or other nodes. While this type of distributed non-routing networking may be preferred in many environments, it may be difficult (e.g., not cost-effective or technologically inefficient) or impractical for a gateway to communicate with a core node  265 . As such, it may be desirable in some environments to implement a so-called autonomous gateway having at least some of the combined functionality of a non-autonomous gateway  215  and a core node  265 . 
       FIG. 8  shows an embodiment of an autonomous gateway  815 , according to various embodiments. in some embodiments, the autonomous gateway  815  includes one or more SMTSs  240 , which may be implemented substantially as the SMTSs  240  of the mom-autonomous gateway  215  of  FIG. 2 . The SMTSs  240  may be in communication with one or more multilayer switches  250 . The multilayer switches  250  may be in communication with a gateway module  255  and an interface/peering node  670 . The interface/peering node  670  may be in communication with one or more other networks  605 . It is worth noting that the gateway module  255  may include other functionality in certain embodiments. For example, the illustrated embodiment includes a traffic shaper module  645 . In other embodiments, the traffic shaper module  645  may be implemented differently or as part of a different component. The multilayer switches  250  may be configured to process data using one or more modules. For example, the multilayer switches  250  may be in communication with acceleration modules  650 , provisioning modules  655 , and/or management modules  660 , for example, through one or more firewalls  665 . It will be appreciated that, unlike the typical gateway  115  of  FIG. 1 , in accordance with aspects of the present invention, embodiments of the autonomous gateway are able to implement some of the enhanced (e.g., Layer-2 connectivity-enabled) functionality of the non-autonomous gateways  215  and core nodes  265 . 
       FIG. 9  shows an embodiment of a satellite communications system  900  that distributes autonomous gateways  815  and non-autonomous gateways  215  across a number of geographically dispersed regions  905 , according to various embodiments. In one embodiment, a first geographic region  905   a , a second geographic region  905   b  and a sixth geographic region  905   f  represent environments where it is not cost-effective to provide communications with core nodes  265 . As such, these geographic regions  905  as illustrated as having autonomous gateways  815 . For example, autonomous gateways  815  may be used in island regions, geographically remote regions, regions with particular types of topologies (e.g., large mountain ranges), etc. 
     In contrast to the above-mentioned regions (geographic regions  905   a ,  905   b , and  905   f ), a third geographic region  905   c , a fourth geographic region  905   d , and a fifth geographic region  905   e  indicate regions where it is cost-effective to implement a core-based non-routed ground segment network  220 . As illustrated, each non-autonomous gateway  215  is either directly or indirectly in communication with at least one core node  265  (e.g., typically two core nodes  265 ). Other components may also be included in the non-routed ground segment network  220 . For example, additional switches  910 , optical cross-connects  920 , etc. may be used. Further, while the non-routed ground segment network  220  is configured to provide point-to-point layer-2 connectivity, other types of connectivity may also be implemented between certain nodes. For example, one or more VPLS networks may be implemented to connect certain nodes of the non-routed ground segment network  220 . 
     In various embodiments, core nodes  265  may be located on a new or existing fiber run, for example, between metropolitan areas. In some configurations, the core nodes  265  may be located away from the majority of spot beams (e.g., in the middle of the country, where much of the subscriber population lives closer to the outsides of the country). In alternative embodiments, core nodes  265  may be located near the majority of spot means. Such spatial diversity between code nodes and subscriber terminals may, for example, facilitate frequency re-use of between service beams and feeder beams. Similarly, non-autonomous gateways  215  may be located to account for these and/or other considerations. 
     It is worth noting that, in the non-routed ground segment network  220 , twelve gateways (e.g., including both non-autonomous gateways  215  and autonomous gateways  815 ) are illustrated. If all were implemented as autonomous gateways  815 , the topology may require twelve gateway modules, routers, switches, and other hardware components. Further, various licensing and/or support services may have to be purchased for each of the autonomous gateways  815 . In some cases, licensing requirements may dictate a minimum purchase of ten thousand licenses for each gateway module, which may require an initial investment into 120-though licenses from the first day of operation. 
     Using aggregated functionality in one or more core nodes  265 , however, may minimize some of these issues. For example, the non-routed ground segment network  220  includes four core nodes  265 , each having a gateway module, and only three of the twelve gateways are autonomous gateways  815 . As such, only seven gateway modules may be operating on the non-routed ground segment network  220 . As such, only seven instances of each core networking component may be needed, only seven licenses may be needed, etc. This may allow for a softer ramp-up and other features. 
     It will be appreciated that there are many types of functionality that may be supported and/or enabled by facilitating persistent layer-2 connectivity throughout the non-routed ground segment network  220 . One set of functionality includes the provision of layer-2 extension services, through which one or more services may be applied to traffic across the non-routed ground segment network  220 . for example, by associating the serviced with a particular virtual tagging tuple  375 . As discussed above with reference to  FIG. 3 , virtual tagging tuples  375  may be used effectively to designate certain types of traffic in a way that persists across the non-routed ground segment network  220 . 
       FIG. 10  shows an embodiment of a portion of a communications system  1000  configured to facilitate layer-2 extension services, according to various embodiments. The communications system  1000  may be a portion of the communications system  900  of  FIG. 9 . As illustrated, a service provider  1010  interfaces with (e.g., establishes layer-2 connectivity with) a non-autonomous gateway  215  in a first geographic region  905   a . The service provider  1010  is assigned, or otherwise associated with, at least one virtual tagging tuple  375  (e.g., or at least one element of a virtual tagging tuple  375 ). 
     It will be appreciated from the preceding description that, by virtue of plugging into a single non-autonomous gateway  215 , embodiments of the non-routed ground segment network  220  can provide layer-2 connectivity between the service provider  1010  and any other node of the non-routed ground segment network  220 . Further, by being associated with at least a portion of a virtual tagging tuple  375 , the service provider  1010  can extend it service offerings to customers  1020  serviced by any node of the non-routed ground segment network  220  without having to build out a layer-2 infrastructure in other locations. For example, by plugging into the non-autonomous gateway  215  in the first geographic region  905   a , the service provider  1010  may be able to service customers  1020  in a substantially remote third geographic region  905   c / As such, customers  1020  may experience a service offering from the service provider  1010  substantially as if the customers were connected with the service provider  1010  via a local subnet. 
     While the service provider  1010  is shown interfacing with the non-routed ground segment network  220  at a non-autonomous gateway  215 , the service provider  1010  may alternatively interface with the non-routed ground segment network  220  at any other node where the layer-2 connectivity is accessible. For example, if a service provider  1010  already has an infrastructure built out close to a core node  265  in Arizona, the service provider  1010  can connect to that core node  265  to service customers  1020  via a non-autonomous gateway  215  in New York, even with no layer-2 infrastructure in New York. 
     For example, say an enterprise customer purchases the identifier “205” for use as the first element of a virtual tagging tuple  375 . In one embodiment, all enterprise traffic is designated at layer 2 by a tuple of the form “(205,XXX)”, where “XXX” indicates a location. For example, data tagged anywhere in the non-routed ground segment network  220  as “(205,100)” is associated with the enterprise customer and a non-autonomous gateway  215  at location “100” (e.g., Kansas), while data tagged anywhere in the non-routed ground segment network  220  as “(205,128)” is associated with the enterprise customer and a non-autonomous gateway  215  at location “128” (e.g., New Mexico). 
     In another embodiment, a DSL service provider  101  in Colorado desires to provide DSL services to customers  1020  in New York, where it has no layer-2 infrastructure. The DSL service provider  1010  is assigned a particular tuple designation. The DSL service provider  1010  then plugs into the non-routed ground segment network  220  at a node in Denver. All DSL traffic from that provider, all over the non-routed ground segment network  220 , is tagged with the assigned virtual tuple designation. As such, DSL customers  1020  in New York may substantially immediately be provided with DSL services that appear to the customers to be “local.” 
     In still another embodiment, all traffic for an Internet service provider  1010  is designated at layer 2 by a tuple of the form “(205,XXX,YYY),” where “XXX” indicates a location and “YYY” designates a service offering. For example, data tagged anywhere in the non-routed ground segment network  220  as “(205,100,5D2)” is associated with the Internet service provider  1010 , a non-autonomous gateway  215  at location “100” (e.g., Kansas), and a certain type of traffic shaping designated by “5D2”; while data tagged anywhere in the non-routed ground segment network  220  as “(205c100,083)” is associated with the Internet service provider  1010 , the non-autonomous gateway  215  at location “100”, and a VPLS network. Of course, any other type of particular service offering may be designated (e.g., (e.g., multicasting, VPN, MPLS, VLAN, enterprise cashing, etc.). In other embodiments, the virtual tagging tuples  375  may have other numbers of elements, other types of designations may be used, single elements may designate multiple locations or services, etc. 
       FIG. 11  shows a flow diagram of a method  1100  for providing layer-2 extension services across a non-routed ground segment network, according to various embodiments. The method  1100  begins at clock  1105  by providing a Layer-2 interface between a node of a non-routed ground segment network and a service provider. At clock  1110 , a layer-2 virtual tagging tuple is assigned to the service provider. Service provider traffic is received at any node of the non-routed ground segment network at clock  1115 . At clock  1120 , the service provider traffic is tagged with the appropriate virtual tagging tuple. The tagged service provider data is then switched, at clock  1125 , through the non-routed ground segment network according to the virtual tagging tuple. 
       FIG. 12  is a simplified block diagram illustrating the physical components of a computer system  1200  that may be used in accordance with an embodiment of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. 
     In various embodiments, computer system  1200  may be used to implement any of the computing systems descry bed above. As shown in  FIG. 12 , computer system  1200  comprises hardware elements that may be electrically coupled via a bus  1224 . The hardware elements may include one or more central processing units (CPUs)  1202 , one or more input devices  1204  (e.g., a mouse, a keyboard, etc.), and one or more output devices  1206  (e.g., a display device, a printer, etc.). For example, the input devices  1204  are used to receive user inputs for procurement related search queries. Computer system  1200  may also include one or more storage devices  1208 . By way of example, storage devices  1208  may include devices such as disk drives, optical storage devices, and solid-state storage devices such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like. In an embodiment, various databases are stored in the storage devices  1208 . For example. the central processing unit  1202  is configured to retrieve data from a database and process the data for displaying on a GUI. 
     Computer system  1200  may additionally include a computer-readable storage media reader  1212 , a communications subsystem  1214  (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory  1218 , which may include RAM and ROM devices as described above. In some embodiments, computer system  1200  may also include a processing acceleration unit  1216 , which can include a digital signal processor (DSP), a special-purpose processor, and/or the like. 
     Computer-readable storage media reader  1212  can further be connected to a computer-readable storage medium  1210 , together (and, optionally, in combination with storage devices  1208 ) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. Communications system  1214  may permit data to be exchanged with a network and/or any other computer. 
     Computer system  1200  may also comprise software elements, shown as being currently located within working memory  1218 , including an operating system  1220  and/or other code  1222 , such as an application program (which may be a client application, Web browser, mid-tier application, RDBMS, etc.). In a particular embodiment, working memory  1218  may include executable code and associated data structures for one or more design-time or runtime components/services. It should be appreciated that alternative embodiments of computer system  1200  may have numerous variations from the described above. For example, customized hardware might also be used and/or particular elements might be implements in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed. In various embodiments, the behavior of the view functions described throughout the present application is implemented as software elements of the computer system  1200 . 
     In one set of embodiments, the techniques described herein may be implemented as program code executable by a computer system (such as a computer system  1200 ) and may be stored on machine-readable media. Machine-readable media may include any appropriate media known or used in the art, including storage media and communication media, such as (but not limited to) volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as machine-readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or the memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer. 
     While the principles of the disclosure have been described above in connection with specific apparatuses and methods, it is to be clearly understood that this description is made only by way of example and not as limitation on the scope of the disclosure. Further, while the invention has been described with respect to exemplary embodiments, one skilled in the art will recognize that numerous modifications are possible. For example, the methods and processes described herein may be implemented using hardware components, software components, and/or any combination thereof. Further, while various methods and processes described herein may be described with respect to particular structural and/or functional components for ease of description, methods of the invention are not limited to any particular structural and/or functional architecture but instead can be implemented on any suitable hardware, firmware and/or software configuration. Similarly, while various functionality is ascribed to certain system components, unless the context dictates otherwise, this functionality can be distributed among various other system components in accordance with different embodiments of the invention. 
     Moreover, while the procedures comprised in the methods and processes described herein are described in a particular order for ease of description, unless the context dictates otherwise, various procedures may be reordered, added, and/or omitted in accordance with various embodiments of the invention. Moreover, the procedures described with respect to one method or process may be incorporated within other described methods or processes; likewise, system components described according to a particular structural architecture and/or with respect to one system may be organized in alternative structural architectures and/or incorporated within other described systems. Hence, while various embodiments are described with—or without—certain features for ease of description and to illustrate exemplary features, the various components and/or features described herein with respect to a particular embodiment can be substituted, added and/or subtracted from among other described embodiments, unless the context dictates otherwise. Consequently, although the invention has been described with respect to exemplary embodiments, it will be appreciated that the invention is intended to cover all modifications and equivalents within the scope of the following claims.