鵝
歷
☌
←
→
⇡
16 Nov 2015

SDX: A Software Defined Internet Exchange

IETF Slide

http://www.ietf.org/proceedings/86/slides/slides-86-sdnrg-6

sigcomm 14 paper

http://gtnoise.net/papers/2014/gupta-sigcomm2014.pdf

3.1 Virtual SDX Switch Abstraction

traditional exchange point
each participating AS typically connects a BGP-speaking border router to a shared layer-two network (a data plane for forwarding packets) and a BGP route server (a control plane for exchanging routing information).
SDX
each AS can run SDN applications that specify flexible policies for dropping, modifying, and forwarding the traffic. The SDX must then combine the policies of multiple ASes into a single coherent policy for the physical switch(es).

each AS has the illusion of its own virtual SDN switch connecting its border router to each of its peer ASes, as shown in Figure:

3.2 Integration with Interdomain Routing

The ASes must define SDX policies in relation to the advertised routes in the global routing system. To do so, the SDX allows participating ASes to define forwarding policies relative to the current BGP routes. To learn BGP routes, the SDX controller integrates a route server. Participants interact with the SDX route server in the same way that they do with a conventional route server. The SDX route server collects the routes advertised by each participant BGP router and selects one best route for each prefix on behalf of each participant, and re-advertises the best BGP route on the appropriate BGP session(s). In contrast to today’s route servers, where each participant learns and uses one route per prefix, the SDX route server allows each participant to forward traffic to all feasible routes for a prefix, even if it learns only one.

4 Efficient Compilation

We consider data-plane efficiency (Section 4.2), to minimize the number of rules in the switches, and control-plane efficiency (Section 4.3), to minimize the computation time under realistic workloads.

5.1 Implementation

The policy compiler (based on Pyretic)
takes as input policies from individual participants that are written in Pyretic—which may include custom route advertisements from the participants—as well as BGP routes from the route server, and it produces forwarding rules that implement the policies.
The route server (based on ExaBGP)
processes BGP updates from participating ASes and provides them to the policy compiler and re-advertises BGP routes to participants based on the computed routes.

reference

ONS 2 page — SDX: A Software Defined Internet Exchange

http://gtnoise.net/papers/2013/feamster-ons2013.pdf

Architecture
two instantiations of the SDX architecture:
  1. a single-site deployment, where an SDN controller acts as a “smart route server” on behalf of the participating ASes at the exchange; and
  2. a multi-site deployment, where SDN controllers across multiple exchange points coordinate to enable more sophisticated wide-area policies.
Challenges
  1. developing appropriate isolation mechanisms, so that the route selection mechanisms of each AS do not interfere with one another.
  2. dealing with the realities of incremental deployment, which give rise to heterogeneity: specifically, any particular AS is likely to have conventional BGP peering relationships and peering relationships at SDXes.
  3. determining the programmatic interface than an SDX controller should expose to users of the exchange point, for various classes of users (i.e., ISPs, content providers), and how to resolve potential conflicts that may arise in route selection and control when multiple parties can control route selection at a single exchange point.