HughesNet and MPLS. This white paper addresses how it is possible to seamlessly integrate MPLS and HughesNet.

Transcription

1 HughesNet and MLS This white paper addresses how it is possible to seamlessly integrate MLS and HughesNet. The first sections contain a basic introduction to MLS and the required scenarios in which the HughesNet services are expected to interface to MLS networks. The next section is a general analysis of how HughesNet services interact with MLS networks to meet the requirements. The remaining sections describe for each HughesNet transport which scenarios from the general analysis section are supported for that transport and any configuration required for the scenarios where it is supported. Terminology The following terms are required to discuss MLS interactions with HughesNet services generically: MLS Multi-rotocol Label Switching a technology that operates sub-layer3 where a label is added to each packet at the edge of the network such that the packet can be fast switched and given the appropriate service level by routers within the network without those routers needing to perform any I packet inspection. HughesNet Hub this is the point at which I traffic terminates on the NOC-side of a HughesNet network. The actual termination point varies depending on the type of HughesNet transport being discussed. The various devices that play this role in HughesNet are: i. I gateway (IGW) in the Ku-band satellite system ii. Access Gateway (AGW) in the SAWAY satellite system iii. HN9500 in some smaller network SAWAY deployments iv. HR gateway (HRGW) in networks using HughesNet wireline access HughesNet remote this is the point at which I traffic terminates for a given remote site in a HughesNet network. The actual termination point varies depending on the type of HughesNet transport being discussed. The various devices that play this role in HughesNet are: i. HN7700S in the legacy satellite system ii. HN9500 in SAWAY satellite system iii. HN7700S-R in HughesNet wire-line networks iv. Cisco 877(w) in HughesNet wire-line networks Interface Router this is a term used for a router that is to be configured to interface between the MLS Customer Edge and the I Transport Remote Termination or the I Transport Hub Termination, if necessary, for the purposes of mapping/marking Quality of Service indications on packets and/or interfacing different routing protocols (e.g., RI in one direction and BG in another). 1

2 MLS Customer Edge () Router this is a term used for a WAN termination router placed on the customer premise. The WAN side of this router provides connectivity to a rovider Edge in the Service rovider network. A need not be MLS-aware. MLS rovider Edge () Router this is a term used for a router in the Service rovider network that interfaces to routers and is the gateway into the MLS backbone network. routers can handle multiple virtual private networks and perform routing with other routers to fill routing tables for each virtual private network that it services. MLS rovider () Router this is a term used for a router in the Service rovider backbone MLS network that has no direct customer network interfaces. Due to how MLS networks operate, this router does not learn any customer routes, does not need to be aware of virtual private networks, and does not need to inspect I packets in order to move traffic along through the network. VRF VN Routing and Forwarding tables - one of several separate route tables within a larger router that supports multiple independent VNs. This allows the route tables to be separate for each customer. Thus, the route tables can contain information on overlapping private I address space without causing any routing issues. RI Routing Information rotocol - an interior gateway routing protocol that exchanges distance vector information BG Border Gateway rotocol an exterior gateway routing protocol that is used to exchange public routing information between autonomous systems BG-M - Border Gateway rotocol Multi-rotocol - an extension of BG that allows the protocol to exchange routes on independent virtual private domains which may have overlapping I addresses. IM-SDM rotocol Independent Multicast Sparse-Dense Mode a protocol used between routers to set up distribution trees based on which routers have ports where a host or another router is requesting multicast data for a specific multicast address. Sparse mode and sparse-dense modes are methods for how the multicast distribution tree is created and pruned back as a function of membership. IGM Internet Group Management rotocol a protocol used for hosts to indicate to a router that an entity on that subnet is interested in receiving multicast data for a specific multicast address. IG Interior Gateway rotocol a generic term for a routing protocol run within a network that connects routers in the same autonomous system Introduction There are multiple ways in which a HughesNet service would interact with MLS to either be an extension of an MLS network, a backup to an MLS network, or part of an MLS network. Since MLS is a sub-i layer method for handling Quality of Service, Routing, and multiple customers I address spaces, it is an alternate sub-i layer to those used in other transport networks such as those provided by HughesNet. Thus, traffic traversing the HughesNet 2

3 transports is not required to carry MLS tags, since they have existing sub-i layer and I layer mechanisms that are equivalent to those provided by MLS. MLS Brief Background Building 2 Building 2 MLS Network Building 1 Figure 1. Router Types in an MLS Network An MLS backbone network is a set of and routers that are interconnected, administered by the same Service rovider, carry MLS labels on traffic between them, and use the labels for the purposes of switching and providing differentiated service to traffic flows over the backbone. Traffic between and routers is label switched according to MLS and the and routers do not need to access the I/TC/UD headers of the traffic to make a classification or forwarding decision. Because routers are not edge routers, they do not require a routing protocol that contains customer I subnet information. They may run an internal routing protocol between themselves and s to determine reachability within the backbone. routers are the edge routers of the service provider network. They may need to look into the I packet for packets ingressing and egressing to s, but not for packets on interfaces to other 3

4 routers or routers. s contain multiple virtual routers or VRFs, one for each virtual private network that it directly serves. A router is said to serve a virtual private network if it is directly connected to a that is a member of that virtual private network. A does not contain virtual routers if it does not have a directly connected that is a member of that domain and does not exchange routing information regarding a virtual private network if it has no directly connected in that domain. routers receive routes on virtual private networks for which they have one or more directly connected s by participating with other routers serving those virtual private networks using BG-M. BG-M is an extension of BG that allows the protocol to exchange routes on independent virtual private domains which may have overlapping I addresses. It does this by reporting a Routing Domain (RD) tag with each route that identifies the virtual private network of the subnet being reported. s directly connect to a via a variety of network access protocols based upon the last mile technology used to connect the to the router at the edge of the MLS backbone. A router uses one or more of several potential methods to determine the virtual private network of a given (e.g., domain). The is either statically configured with or learns of routes behind the s which directly connect to it. The fills only the virtual router of the virtual private network of the with the routes reachable by the. If the dynamically learns of routes from the, it can use a variety of routing protocols to do so. In other words, even though the uses BG-M to exchange routes with other s, it does not need to use BG to exchange routes with s. The is at the customer premise. A may be a member of multiple virtual private networks, but for simplicity, this brief MLS introduction discusses the case of a belonging to a single virtual private network. The may or may not participate in a routing protocol with the router as described above. The may or may not participate in a routing protocol with the local site network for which it is providing access to the MLS network. If the performs a routing protocol with the local site, the routing protocol that it uses may or may not be same as the routing protocol it uses to the. Configurations of HughesNet and MLS Networks There are three configurations where MLS and HughesNet would work together to support customer requirements. Those configurations are: 1. HughesNet as an extension of an MLS network to remote sites without traditional MLS last mile connectivity (Figure 2) in this scenario, some number of sites associated with an enterprise cannot or do not receive MLS last mile connectivity. These sites are serviced by a HughesNet service. Traffic from one or more I Transport Remote Terminations is aggregated onto an MLS connection with connectivity to the other enterprise sites on the MLS network, including data centers. In this case, there may be a connection to the MLS network dedicated to a single customer or there may be an aggregated connection to the MLS network serving multiple customers, where the Hub supports multiple VRF. 4

5 Figure 2. HughesNet as an extension of an MLS network 2. HughesNet is used to provide additional bandwidth over traditional MLS last mile connectivity (Figure 3) - in this scenario, limitations on the MLS last mile connectivity bandwidth on some number of sites associated with an enterprise lead to a desire to increase the total bandwidth to the site. This could be particularly appealing for Multicast applications. re-defined applications are, thus, configured to use HughesNet service at those sites while other applications are sent via the MLS access. This can either be deployed across the entire network where all sites have both MLS and VSAT or it can be deployed for a subset of enterprise sites (as shown in Figure 3). 5

6 Data Center MLS Network I Hub HughesNet Network Figure 3. HughesNet as additional bandwidth to MLS 3. HughesNet as an integrated backup to an existing MLS network (Figure 4) in this scenario, HughesNet service is desired to ensure that any failure of the MLS access can be mitigated by using the HughesNet service path. This can be combined with item 2 above to allow for the use of both paths when available and the consolidation to one path for at least some traffic if the other path is currently unavailable. 6

7 Data Center MLS Network I Hub HughesNet Network Figure 4. HughesNet as Access Continuity In order to seamlessly support the above three configurations, Hughes has developed the following capabilities: 1. HughesNet service provides differentiated traffic handling of up to 4 Classes of Service. 2. HughesNet service reports at its demarcation points route reachability and cost to external routers. 3. HughesNet service carries Class of Service indicators (i.e., DSC) through the HughesNet network end to end. 4. HughesNet service can be configured to pass or not pass multicast traffic from its edge towards external routers. 5. HughesNet service is able to provide separation of multiple customers with potentially overlapping I address space at its I Transport Hub Terminations. 6. HughesNet service is configurable with classification rules that allow it to set Class of Service indicators (i.e., DSC) to external routers as a function of multi-field classification on source/destination I address, source/destination port, and protocol. Analysis 7

8 Given the requirements discussed earlier, there are two interfaces to an MLS network: All scenarios at the I Transport Hub Termination (e.g., edge router, I GW, or AGW, there is an interface to a that connects the satellite network to the MLS network MLS backup and load sharing scenarios at the remote, the I Transport Remote Termination device (VSAT, DSL/T1 Router) is backing up or load sharing with a that has connectivity into the MLS network. The next set of sections will attempt to generically analyze how HughesNet interfaces to an MLS network providing end-to-end service using the traditional VSAT network as the example. Subsequent sections will then discuss any specific deltas for each transport Ku-band VSAT, Wire-line, and Ka-band VSAT (Spaceway). Throughout it is assumed that the is performing MLS. However, all cases described do not change for cases where the is not performing MLS. QoS Two methods are used in MLS for setting Class of Service. E-LS uses a single label for the path and then uses the Experimental (EX) 3 bits to indicate up to 8 different service classes. L- LS uses a separate label for each priority (e.g., 4 priorities would lead to 4 different labels for a path). Direction MLS network into HughesNet Option 1 MLS provides DSC in this scenario, MLS has set and/or carried DSC codepoints that are considered valid. Regardless of whether that information has been copied from the I packet and is still in the I packet or whether the DSC coding is generated at the using the label (L-LS) or the EX bits (E-LS), the I packet arriving at the I Transport Termination at the HughesNet hub would be coded using DSC. The HughesNet hub would then map from the DSC codepoints to the Class of Service to be provided by HughesNet. Option 2 MLS does not provide DSC in this scenario, the information used to provide class of service in MLS is not carried by the I packets as DSC codings. Thus, the HughesNet hub would be configured with a set of and I Selection rules to map fields in the I header to the Class of Service to be provided by HughesNet. For end-to-end quality of service, the multi-field classification rules used at the HughesNet hub would need to be consistent with the set of classification rules at the entering the MLS network at the sending side. Direction HughesNet into MLS network Option 1 Customer remote network provides DSC in this scenario, the incoming DSC bits can be used. The HughesNet remote terminal is configured with classification rules to map the DSC coding to the Class of Service to be provided by HughesNet. HughesNet carries the DSC codepoints and they remain unmodified at the as sent by the I Transport Hub Termination. The would then map the DSC codepoints into either EX bits (E-LS) or labels (L-LS) to provide equivalent service relative levels over the MLS backbone. 8

9 Option 2 Customer remote network does not provide DSC; HughesNet sets DSC in this scenario, the incoming DSC bits are not set or cannot be used. The HughesNet remote terminal is configured with classification rules to map the fields in the incoming I/TC/UD headers to the Class of Service to be provided by HughesNet. HughesNet sets the DSC codepoints according to the class of service and they remain unmodified at the as sent by the I Transport Hub Termination. The would then map the DSC codepoints into either EX bits (E-LS) or labels (L-LS) to provide equivalent service relative levels over the MLS backbone. Option 3 Customer remote network does not provide DSC; HughesNet does not set DSC in this scenario, the incoming DSC bits are not set or cannot be used. The HughesNet remote terminal is configured with Selection rules and Unspoofed riorities to map the fields in the incoming I/TC/UD headers to the Class of Service to be provided by HughesNet. HughesNet is not configured to set the DSC codepoints according to the class of service. The would then need to map into either EX bits (E-LS) or labels (L-LS) based on a similar set of classification rules that were used at the remote to provide equivalent service relative levels over the MLS backbone. This option may be used in cases where DiffServ configuration is not setup at the. Routing For the purposes of this section, since one of several routing protocols may be used between a VRF for a given customer and a VRF for that customer, this document uses the term IG generically to describe an interior gateway routing protocol that may be used for that purpose. The selection of that algorithm does not impact the assessment. Also for the purposes of this section, the interior routing protocol run between s and routers and the backbone routing tables are not shown in the figures provided. 1. Static Routes In this case no routing protocol is run between the and the HughesNet hub (shown as I GW in the diagram). Static routes are used at the and the HughesNet hub. Switch I GW BG- To Other s IG IG M Customer 1 Virtual Route Route Route Figure 5. Static Routing for / HughesNet hub interface 1. RI to 9

10 In this case, the and the HughesNet hub (shown as I GW in the diagram) are configured to exchange RI. The may be configured to use a different routing protocol with the. The HughesNet hub and remotes may or may not be configured to use Dynamic Routing. 2. BG to Figure 6. RI for / HughesNet Hub Interface In this case, the and the IGW in the HughesNet hub are configured to exchange BG. The may be configured to use a different routing protocol with the. The HughesNet hub and remotes may or may not be configured to use Dynamic Routing. 3. Other routing protocols to Figure 7. BG for / HughesNet hub Interface Given that there are no current plans for the HughesNet hub to support routing protocols other than RI and BG, then another router is required for cases where the is not configured to support either RI or BG. Figure 8. Additional Router used to translate between and HughesNet hub routing protocols 10

11 Multicast For the purpose of this section IM-SDM is the protocol that is assumed to be used in the MLS network. Also for the purposes of this section, the IM-SDM protocol run between s and routers and the backbone multicast tables are not shown in the figures provided. 1. Static Multicast Configuration The implication is that the multicast traffic is always sent to the at the HughesNet Hub. Switch I GW To Routers for VRF IM- SDM IM- SDM IM- SDM Customer 1 Multicast Multica st Figure 9. Static Multicast Configuration at Hub Multica st 2. I Transport Hub Termination runs IGM Switch I GW To Routers for VRF IM- SDM IM- SDM IM- SDM IGM IGM Customer 1 Multicast Multica st Figure 10. Multicast with Dynamic rotocols at Hub Multica st Implications on the MLS network: 1. If the multicast is not dynamically joined by HughesNet, then there needs to be enough bandwidth to support all the multicasts coming into the HughesNet Hub at all times. Access Continuity 1. Static Routing this would be used when the remote site has no additional routers and/or static routing is to be configured for the routers at the remote location. VRR is used between the and the HughesNet remote terminal to determine the current primary 11

12 default route for the customer remote network. For the return traffic, either routing protocols are used between the Interface Router and both Hub and the HughesNet hub (with the I gateway using up/down status of the HughesNet remote to determine its routes) or a static route is used at the Interface Router to the HughesNet hub with a higher metric with the Hub reporting reachability with a routing protocol. 2. RI Figure 11. Access Continuity with Static Routing 3. Other routing protocol at remote site Figure 12. Access Continuity with RI Figure 13. Access Continuity with IG other than RI Implications on the MLS network: 1. If using static path labels, then labels need to be defined for sites that can be reached via the HughesNet hub such that when the routing protocols point to that path to reach 12

13 the site rather than the path to the at the remote site, there are labels set up for that data flow. Additional Unicast Bandwidth/Load Sharing Here a given site that has both a and HughesNet remote can utilize both transports, as long as both are active. In this case, there are two scenarios: 1. The HughesNet performs the olicy Based Routing. Figure 14. Load sharing with BR in HughesNet remote 2. The performs the olicy Based Routing Figure 15. Load sharing with BR in remote Implications on the MLS network: 1. If using static path labels, then labels need to be defined for both paths to the site to/from the HughesNet hub and to/from the at the remote site. 2. If all traffic originates from a customer data center, then a router (e.g., the customer data center ) needs to perform BR to ensure that the applications are sent along the correct path through the MLS network. If traffic can originate from multiple locations, then each customer that sends to/receives from a load sharing site needs the appropriate BR configuration. 13