The Experts below are selected from a list of 87 Experts worldwide ranked by ideXlab platform

Stephane Maag - One of the best experts on this subject based on the ideXlab platform.

  • Partial complete iBGP
    2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: eBGP (External BGP) and iBGP (Internal BGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. IBGP node has not the ability to reflect Routes. Therefore, each internal node should have iBGP sessions with all ASBRs (Autonomous System Border Routers). BGP Route reflection was widely employed as an alternative to full mesh solution to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, BGP scaling mechanism defined in Route reflection mechanism introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. We propose the PC-iBGP (Partial Complete iBGP) as an alternative to the Route reflection approach. PC- iBGP nodes have the ability of reflecting Routes. It eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds sufficient correctness conditions as well as its robustness against failures, asymmetric path problem, and MED (Multi Exit Discriminator) induced oscillations

  • BGP skeleton : an alternative to iBGP Route reflection
    2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: External BGP (eBGP) and Internal BGP (iBGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. BGP Full Mesh Solution (FMS) is based on that all the ASBRs (Autonomous System Border Routers) should be fully meshed and each internal node should have an iBGP session with all of them. This was because an iBGP node does not have the ability to reflect Routes. BGP Route reflection was widely employed as an alternative to full mesh to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, it introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. Skeleton is an alternative to Route reflection that overcomes these routing anomalies. Skeleton is a subgraph of the physical graph with the same set of nodes, its edges are the iBGP sessions between the nodes. All Skeleton nodes have the ability of reflecting Routes. Skeleton eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds the sufficient correctness conditions as well as its robustness against MED induced oscillations. We evaluate it on five real world topologies and find that the number of iBGP sessions has a linear relationship with the number of ASBRs, where in FMS this relationship is quadratic

  • ICC - Partial Complete iBGP
    2010 IEEE International Conference on Communications, 2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: eBGP (External BGP) and iBGP (Internal BGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. IBGP node has not the ability to reflect Routes. Therefore, each internal node should have iBGP sessions with all ASBRs (Autonomous System Border Routers). BGP Route reflection was widely employed as an alternative to full mesh solution to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, BGP scaling mechanism defined in Route reflection mechanism introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. We propose the PC-iBGP (Partial Complete iBGP) as an alternative to the Route reflection approach. PC- iBGP nodes have the ability of reflecting Routes. It eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds sufficient correctness conditions as well as its robustness against failures, asymmetric path problem, and MED (Multi Exit Discriminator) induced oscillations.

  • INFOCOM - BGP Skeleton - An Alternative to iBGP Route Reflection
    2010 Proceedings IEEE INFOCOM, 2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: External BGP (eBGP) and Internal BGP (iBGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. BGP Full Mesh Solution (FMS) is based on that all the ASBRs (Autonomous System Border Routers) should be fully meshed and each internal node should have an iBGP session with all of them. This was because an iBGP node does not have the ability to reflect Routes. BGP Route reflection was widely employed as an alternative to full mesh to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, it introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. Skeleton is an alternative to Route reflection that overcomes these routing anomalies. Skeleton is a subgraph of the physical graph with the same set of nodes, its edges are the iBGP sessions between the nodes. All Skeleton nodes have the ability of reflecting Routes. Skeleton eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds the sufficient correctness conditions as well as its robustness against MED induced oscillations. We evaluate it on five real world topologies and find that the number of iBGP sessions has a linear relationship with the number of ASBRs, where in FMS this relationship is quadratic.

Arvind Krishnamurthy - One of the best experts on this subject based on the ideXlab platform.

  • lifeguard practical repair of Persistent Route failures
    ACM Special Interest Group on Data Communication, 2012
    Co-Authors: Ethan Katzbassett, Colin Scott, David Choffnes, Italo Cunha, Vytautas Valancius, Nick Feamster, Harsha V Madhyastha, Thomas Anderson, Arvind Krishnamurthy
    Abstract:

    The Internet was designed to always find a Route if there is a policy-compliant path. However, in many cases, connectivity is disrupted despite the existence of an underlying valid path. The research community has focused on short-term outages that occur during Route convergence. There has been less progress on addressing avoidable long-lasting outages. Our measurements show that long-lasting events contribute significantly to overall unavailability. To address these problems, we develop LIFEGUARD, a system for automatic failure localization and remediation. LIFEGUARD uses active measurements and a historical path atlas to locate faults, even in the presence of asymmetric paths and failures. Given the ability to locate faults, we argue that the Internet protocols should allow edge ISPs to steer traffic to them around failures, without requiring the involvement of the network causing the failure. Although the Internet does not explicitly support this functionality today, we show how to approximate it using carefully crafted BGP messages. LIFEGUARD employs a set of techniques to reRoute around failures with low impact on working Routes. Deploying LIFEGUARD on the Internet, we find that it can effectively Route traffic around an AS without causing widespread disruption.

  • SIGCOMM - LIFEGUARD: practical repair of Persistent Route failures
    Proceedings of the ACM SIGCOMM 2012 conference on Applications technologies architectures and protocols for computer communication - SIGCOMM '12, 2012
    Co-Authors: Ethan Katz-bassett, Colin Scott, David Choffnes, Italo Cunha, Vytautas Valancius, Nick Feamster, Harsha V Madhyastha, Thomas Anderson, Arvind Krishnamurthy
    Abstract:

    The Internet was designed to always find a Route if there is a policy-compliant path. However, in many cases, connectivity is disrupted despite the existence of an underlying valid path. The research community has focused on short-term outages that occur during Route convergence. There has been less progress on addressing avoidable long-lasting outages. Our measurements show that long-lasting events contribute significantly to overall unavailability. To address these problems, we develop LIFEGUARD, a system for automatic failure localization and remediation. LIFEGUARD uses active measurements and a historical path atlas to locate faults, even in the presence of asymmetric paths and failures. Given the ability to locate faults, we argue that the Internet protocols should allow edge ISPs to steer traffic to them around failures, without requiring the involvement of the network causing the failure. Although the Internet does not explicitly support this functionality today, we show how to approximate it using carefully crafted BGP messages. LIFEGUARD employs a set of techniques to reRoute around failures with low impact on working Routes. Deploying LIFEGUARD on the Internet, we find that it can effectively Route traffic around an AS without causing widespread disruption.

  • On Route selection for interdomain traffic engineering
    IEEE Network, 2005
    Co-Authors: Yang Richard Yang, H. Wang, Haiyong Xie, Abraham Silberschatz, Arvind Krishnamurthy, Y. Liu
    Abstract:

    In this article we investigate a model of Route selection for interdomain traffic engineering where routing to multiple destinations can be coordinated. We identify potential routing instability and inefficiency problems, and derive a set of practical guidelines to guarantee stability without global coordination. Using a realistic Internet topology, we show that Route oscillations can happen even when a small number of ASes coordinate Route selection for just a small number of destinations if the coordination does not follow our guidelines. Wc further extend our model so that ASes can adopt any Route selection algorithms in a class of algorithms we call rational Route selection algorithms; and the local ranking of Routes of an AS can depend on ingress traffic patterns. We show that Persistent Route oscillations can happen in certain network settings even if the ASes strictly follow the constraints imposed by business considerations, and adopt any rational Route selection algorithms.

Bakr Sarakbi - One of the best experts on this subject based on the ideXlab platform.

  • Partial complete iBGP
    2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: eBGP (External BGP) and iBGP (Internal BGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. IBGP node has not the ability to reflect Routes. Therefore, each internal node should have iBGP sessions with all ASBRs (Autonomous System Border Routers). BGP Route reflection was widely employed as an alternative to full mesh solution to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, BGP scaling mechanism defined in Route reflection mechanism introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. We propose the PC-iBGP (Partial Complete iBGP) as an alternative to the Route reflection approach. PC- iBGP nodes have the ability of reflecting Routes. It eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds sufficient correctness conditions as well as its robustness against failures, asymmetric path problem, and MED (Multi Exit Discriminator) induced oscillations

  • BGP skeleton : an alternative to iBGP Route reflection
    2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: External BGP (eBGP) and Internal BGP (iBGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. BGP Full Mesh Solution (FMS) is based on that all the ASBRs (Autonomous System Border Routers) should be fully meshed and each internal node should have an iBGP session with all of them. This was because an iBGP node does not have the ability to reflect Routes. BGP Route reflection was widely employed as an alternative to full mesh to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, it introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. Skeleton is an alternative to Route reflection that overcomes these routing anomalies. Skeleton is a subgraph of the physical graph with the same set of nodes, its edges are the iBGP sessions between the nodes. All Skeleton nodes have the ability of reflecting Routes. Skeleton eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds the sufficient correctness conditions as well as its robustness against MED induced oscillations. We evaluate it on five real world topologies and find that the number of iBGP sessions has a linear relationship with the number of ASBRs, where in FMS this relationship is quadratic

  • ICC - Partial Complete iBGP
    2010 IEEE International Conference on Communications, 2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: eBGP (External BGP) and iBGP (Internal BGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. IBGP node has not the ability to reflect Routes. Therefore, each internal node should have iBGP sessions with all ASBRs (Autonomous System Border Routers). BGP Route reflection was widely employed as an alternative to full mesh solution to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, BGP scaling mechanism defined in Route reflection mechanism introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. We propose the PC-iBGP (Partial Complete iBGP) as an alternative to the Route reflection approach. PC- iBGP nodes have the ability of reflecting Routes. It eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds sufficient correctness conditions as well as its robustness against failures, asymmetric path problem, and MED (Multi Exit Discriminator) induced oscillations.

  • INFOCOM - BGP Skeleton - An Alternative to iBGP Route Reflection
    2010 Proceedings IEEE INFOCOM, 2010
    Co-Authors: Bakr Sarakbi, Stephane Maag
    Abstract:

    The Internet is a composition of ASes (Autonomous Systems), BGP (Border Gateway Protocol) is the routing protocol that is responsible of exchanging Routes between these ASes. It operates in two modes: External BGP (eBGP) and Internal BGP (iBGP). EBGP exchanges routing information between ASes, while iBGP propagates that information within the AS. BGP Full Mesh Solution (FMS) is based on that all the ASBRs (Autonomous System Border Routers) should be fully meshed and each internal node should have an iBGP session with all of them. This was because an iBGP node does not have the ability to reflect Routes. BGP Route reflection was widely employed as an alternative to full mesh to reduce the needed number of iBGP sessions and, in turn, increase the scalability inside the AS. Under particular configuration, it introduces Persistent Route oscillation, forwarding loops, and non-optimal egress nodes. Skeleton is an alternative to Route reflection that overcomes these routing anomalies. Skeleton is a subgraph of the physical graph with the same set of nodes, its edges are the iBGP sessions between the nodes. All Skeleton nodes have the ability of reflecting Routes. Skeleton eliminates the use of clusters and establishes iBGP sessions only between single hop neighbors. We prove that it holds the sufficient correctness conditions as well as its robustness against MED induced oscillations. We evaluate it on five real world topologies and find that the number of iBGP sessions has a linear relationship with the number of ASBRs, where in FMS this relationship is quadratic.

Ethan Katz-bassett - One of the best experts on this subject based on the ideXlab platform.

  • SIGCOMM - LIFEGUARD: practical repair of Persistent Route failures
    Proceedings of the ACM SIGCOMM 2012 conference on Applications technologies architectures and protocols for computer communication - SIGCOMM '12, 2012
    Co-Authors: Ethan Katz-bassett, Colin Scott, David Choffnes, Italo Cunha, Vytautas Valancius, Nick Feamster, Harsha V Madhyastha, Thomas Anderson, Arvind Krishnamurthy
    Abstract:

    The Internet was designed to always find a Route if there is a policy-compliant path. However, in many cases, connectivity is disrupted despite the existence of an underlying valid path. The research community has focused on short-term outages that occur during Route convergence. There has been less progress on addressing avoidable long-lasting outages. Our measurements show that long-lasting events contribute significantly to overall unavailability. To address these problems, we develop LIFEGUARD, a system for automatic failure localization and remediation. LIFEGUARD uses active measurements and a historical path atlas to locate faults, even in the presence of asymmetric paths and failures. Given the ability to locate faults, we argue that the Internet protocols should allow edge ISPs to steer traffic to them around failures, without requiring the involvement of the network causing the failure. Although the Internet does not explicitly support this functionality today, we show how to approximate it using carefully crafted BGP messages. LIFEGUARD employs a set of techniques to reRoute around failures with low impact on working Routes. Deploying LIFEGUARD on the Internet, we find that it can effectively Route traffic around an AS without causing widespread disruption.

Y. Liu - One of the best experts on this subject based on the ideXlab platform.

  • On Route selection for interdomain traffic engineering
    IEEE Network, 2005
    Co-Authors: Yang Richard Yang, H. Wang, Haiyong Xie, Abraham Silberschatz, Arvind Krishnamurthy, Y. Liu
    Abstract:

    In this article we investigate a model of Route selection for interdomain traffic engineering where routing to multiple destinations can be coordinated. We identify potential routing instability and inefficiency problems, and derive a set of practical guidelines to guarantee stability without global coordination. Using a realistic Internet topology, we show that Route oscillations can happen even when a small number of ASes coordinate Route selection for just a small number of destinations if the coordination does not follow our guidelines. Wc further extend our model so that ASes can adopt any Route selection algorithms in a class of algorithms we call rational Route selection algorithms; and the local ranking of Routes of an AS can depend on ingress traffic patterns. We show that Persistent Route oscillations can happen in certain network settings even if the ASes strictly follow the constraints imposed by business considerations, and adopt any rational Route selection algorithms.

  • ICNP - On the stability of rational, heterogeneous interdomain Route selection
    13TH IEEE International Conference on Network Protocols (ICNP'05), 1
    Co-Authors: H. Wang, Haiyong Xie, Yang Richard Yang, Y. Liu, Abraham Silberschatz
    Abstract:

    The recent discovery of instability caused by the interaction of local routing policies of multiple ASes has led to extensive research on the subject. However, previous studies analyze stability under a specific Route selection algorithm. In this paper, instead of studying a specific Route selection algorithm, we study a general class of Route selection algorithms which we call rational Route selection algorithms. We present a sufficient condition to guarantee routing convergence in a heterogeneous network where each AS runs any rational Route selection algorithm. Applying our general results, we study the potential instability of a network where the preference of an AS depends on not only its egress Routes to the destinations but also its inbound traffic patterns (i.e., the distribution of incoming traffic from its neighbors). We show that there exist networks which will have Persistent Route oscillations even when the ASes strictly follow the constraints imposed by business considerations, and adopt any rational Route selection algorithms.