Large-Scale Ethernets and Enterprise Networks - PowerPoint PPT Presentation

Loading...

PPT – Large-Scale Ethernets and Enterprise Networks PowerPoint presentation | free to download - id: 3bb052-YzE4Y



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Large-Scale Ethernets and Enterprise Networks

Description:

Large-Scale Ethernets and Enterprise Networks Major Themes: Scaling Ethernets to millions of nodes Building scalable, robust and plug-&-play networks – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 47
Provided by: wwwusersC
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Large-Scale Ethernets and Enterprise Networks


1
Large-Scale Ethernets and Enterprise Networks
  • Major Themes
  • Scaling Ethernets to millions of nodes
  • Building scalable, robust and plug--play
    networks
  • Building Beyond IP and Future-Proof Networks
  • Two Case Studies
  • SEATTLE, VIRO,
  • see also TRILL (IETF draft standard)
  • Please do the required readings!

CSci5221 Data Center Networking, and
Large-Scale Enterprise Networks Part II

2
Current Trends and Future Networks
  • Large number of mobile users and systems
  • Large number of smart appliances
  • High bandwidth core and edges
  • But also resource limited elements and networks
    (e.g., sensors, MANETs)
  • Heterogeneous technologies

Multimedia Streaming
Games
Online TV
Web/emails
Home users
Internet (or Future Networking Substrate)
Cell smart phones
Surveillance Security
Banking e-commerce
POTS
VoIP
3
Even within a Single Administrative Domain
  • Large ISPs and enterprise networks
  • Large data centers with thousands or tens of
    thousands machines
  • Metro Ethernet
  • More and more devices are Internet-capable and
    plugged in
  • Likely rich and more diverse network topology and
    connectivity

4
Challenges posed by These Trends
  • Scalability capability to connect tens of
    thousands, millions or more users and devices
  • routing table size, constrained by router
    memory, lookup speed
  • Mobility hosts are more mobile
  • need to separate location (addressing) and
    identity (naming)
  • Availability Reliability must be resilient to
    failures
  • need to be proactive instead of reactive
  • need to localize effect of failures
  • Manageability ease of deployment, plug--play
  • need to minimize manual configuration
  • self-configure, self-organize, while ensuring
    security and trust
  • .

5
Quick Overview of Ethernet
  • Dominant wired LAN technology
  • Covers the first IP-hop in most
    enterprises/campuses
  • First widely used LAN technology
  • Simpler, cheaper than token LANs, ATM, and IP
  • Kept up with speed race 10 Mbps and now to 40
    Gbps
  • Soon 100 Gbps would be widely available

Metcalfes Ethernet sketch
6
Ethernet Frame Structure
  • Addresses source and destination MAC addresses
  • Flat, globally unique, and permanent 48-bit value
  • Adaptor passes frame to network-level protocol
  • If destination address matches the adaptor
  • Or the destination address is the broadcast
    address
  • Otherwise, adapter discards frame
  • Type indicates the higher layer protocol
  • Usually IP

7
Interaction w/ the Upper Layer (IP)
  • Bootstrapping end hosts by automating host
    configuration (e.g., IP address assignment)
  • DHCP (Dynamic Host Configuration Protocol)
  • Broadcast DHCP discovery and request messages
  • Bootstrapping each conversation by enabling
    resolution from IP to MAC addr
  • ARP (Address Resolution Protocol)
  • Broadcast ARP requests
  • Both protocols work via Ethernet-layer
    broadcasting (i.e., shouting!)

8
Broadcast Domain and IP Subnet
  • Ethernet broadcast domain
  • A group of hosts and switches to which the same
    broadcast or flooded frame is delivered
  • Note broadcast domain ! collision domain
  • Broadcast domain IP subnet
  • Uses ARP to reach other hosts in the same subnet
  • Uses default gateway to reach hosts in different
    subnets
  • Too large a broadcast domain leads to
  • Excessive flooding and broadcasting overhead
  • Insufficient security/performance isolation

9
Ethernet Bridging Routing at L2
  • Routing determines paths to destinations through
    which traffic is forwarded
  • Routing takes place at any layer (including L2)
    where devices are reachable across multiple hops

10
Ethernet (Layer-2) Routing
  • Self-learning algorithm for dynamically building
    switch (forwarding) tables
  • Eavesdrop on source MACs of data packets
  • Associate source MACs with port (cached,
    soft-state)
  • Forwarding algorithm
  • Forwarding algorithm
  • If dst MAC found in switch table, send to the
    corresp. port
  • Otherwise, flood to all ports (except the one it
    comes from)
  • Dealing with loopy topologies
  • Running (periodically) spanning tree algorithm to
    convert it into a tree (rooted at an arbitrary
    node)
  • 802.11 Wireless LANs use somewhat similar methods
  • Use the same 48-bit MAC addresses more complex
    frame structures
  • End hosts need to explicitly associate with APs

11
Pros and Cons of Layer 2 Technologies
  • Pluses
  • Plug--Play, with minimal configuration
  • But VLAN requires manual configuration!
  • MAC address flat-name, host mobility
  • Minuses
  • Data plane flooding, not scalable to large
    networks
  • Sub-optimal routing (using a single spanning
    tree)
  • Cant deal with complex topology!
  • Not robust to failures!
  • if any edge or node on the spanning tree fails,
    need to re-compute spanning tree
  • slow convergence!

12
Pros and Cons of (Layer 3) IP
  • Pluses
  • Better data plane scalability
  • unicast packets is sent point-to-point!
  • More optimal routing
  • one spanning tree per destination
  • link weights can be used to reflect link bw,
    latency, load, etc.
  • Minuses
  • Two-level hierarchical names (manual) address
    management
  • prefix assignment per link router configuration
  • poorer support for mobility
  • difficulty/complexity in re-naming
  • Esp., changing addressing schemes (IPv4 -gt IPv6
    transition)
  • control plane flooding reactive approach to
    failures!
  • global effect of network failures
  • Cant take advantage of rich network topologies
    (path diversity)!

13
State of the Practice A Hybrid Architecture
  • Enterprise networks comprised of Ethernet-based
    IP subnets interconnected by routers

Ethernet Bridging - Flat addressing -
Self-learning - Flooding - Forwarding along a
tree
R
R
IP Routing (e.g., OSPF) - Hierarchical
addressing - Subnet configuration - Host
configuration - Forwarding along shortest paths
R
R
Broadcast Domain (LAN or VLAN)
R
14
All-Ethernet Enterprise Network?
  • All-Ethernet makes network mgmt easier
  • Flat addressing and self-learning
    enables plug-and-play networking
  • Permanent and location independent addresses also
    simplify
  • Host mobility
  • Access-control policies
  • Network troubleshooting

15
Data Center Networks !
  • Data centers
  • Backend of the Internet
  • Mid- (most enterprises) to mega-scale (Google,
    Yahoo, MS, etc.)
  • E.g., A regional DC of a major on-line service
    provider consists of 25K servers 1K
    switches/routers
  • To ensure business continuity, and to lower
    operational cost, DCs must
  • Adapt to varying workload ? Breathing
  • Avoid/Minimize service disruption (when
    maintenance, or failure) ? Agility
  • Maximize aggregate throughput ? Load balancing

16
But, Ethernet Bridging Does Not Scale
  • Flooding-based delivery
  • Frames to unknown destinations are flooded
  • Broadcasting for basic service
  • Bootstrapping relies on broadcasting
  • Vulnerable to resource exhaustion attacks
  • Inefficient forwarding paths
  • Loops are fatal due to broadcast storms uses the
    STP
  • Forwarding along a single tree leads
    to inefficiency and lower utilization

17
Layer 2 vs. Layer 3 Again
  • Neither bridging nor routing is satisfactory.
  • Cant we take only the best of each?

18
Floodless in SEATTLE (Scalable Ethernet
ArchiTecTure for Larger Enterprises)
  • Objectives
  • Avoiding flooding
  • Restraining broadcasting
  • Keeping forwarding tables small
  • Ensuring path efficiency
  • SEATTLE architecture
  • Hash-based location management
  • Shortest-path forwarding
  • Responding to network dynamics

19
Avoiding Flooding
  • Bridging uses flooding as a routing scheme
  • Unicast frames to unknown destinations are
    flooded
  • Does not scale to a large network
  • Objective 1 Unicast unicast traffic
  • Need a control-plane mechanism to discover and
    disseminate hosts location information

Send it everywhere! At least, theyll learn
where the source is.
Dont know where destination is.
20
Restraining Broadcasting
  • Liberal use of broadcasting for
    bootstrapping (DHCP and ARP)
  • Broadcasting is a vestige of shared-medium
    Ethernet
  • Very serious overhead in switched networks
  • Objective 2 Support unicast-based bootstrapping
  • Need a directory service
  • Sub-objective 2.1 Yet, support general
    broadcast
  • Nonetheless, handling broadcast should be more
    scalable

21
Keeping Forwarding Tables Small
  • Flooding and self-learning lead to unnecessarily
    large forwarding tables
  • Large tables are not only inefficient, but also
    dangerous
  • Objective 3 Install hosts location
    information only when and
    where it is needed
  • Need a reactive resolution scheme
  • Enterprise traffic patterns are better-suited to
    reactive resolution

22
Ensuring Optimal Forwarding Paths
  • Spanning tree avoids broadcast storms. But,
    forwarding along a single tree is inefficient.
  • Poor load balancing and longer paths
  • Multiple spanning trees are insufficient and
    expensive
  • Objective 4 Utilize shortest paths
  • Need a routing protocol
  • Sub-objective 4.1 Prevent broadcast storms
  • Need an alternative measure to prevent broadcast
    storms

23
Backwards Compatibility
  • Objective 5 Do not modify end-hosts
  • From end-hosts view, network must work the same
    way
  • End hosts should
  • Use the same protocol stacks and applications
  • Not be forced to run an additional protocol

24
SEATTLE in a Slide
  • Flat addressing of end-hosts
  • Switches use hosts MAC addresses for routing
  • Ensures zero-configuration and backwards-compatibi
    lity (Obj 5)
  • Automated host discovery at the edge
  • Switches detect the arrival/departure of hosts
  • Obviates flooding and ensures scalability (Obj
    1, 5)
  • Hash-based on-demand resolution
  • Hash deterministically maps a host to a switch
  • Switches resolve end-hosts location and address
    via hashing
  • Ensures scalability (Obj 1, 2, 3)
  • Shortest-path forwarding between switches
  • Switches run link-state routing to maintain only
    switch-level topology (i.e., do not disseminate
    end-host information)
  • Ensures data-plane efficiency (Obj 4)

25
How does it work?
Optimized forwarding directly from D to A
y
Deliver to x
x
C
Host discovery or registration
Traffic to x
A
Tunnel to egress node, A
Hash (F(x) B)
Tunnel to relay switch, B
Hash (F(x) B)
D
Entire enterprise (A large single IP subnet)
LS core
Notifying ltx, Agt to D
B
Store ltx, Agt at B
E
Switches
End-hosts
Control flow
Data flow
26
Terminology
shortest-path forwarding
Dst
Src
lt x, A gt
x
y
A
Ingress
Egress
D
lt x, A gt
Ingress applies a cache eviction policy to this
entry
Relay (for x)
B
lt x, A gt
27
Responding to Topology Changes
  • The quality of hashing matters!

28
Single Hop Look-up
y sends traffic to x
y
x
A
E
Every switch on a ring is logically one hop away
B
F(x)
D
C
29
Responding to Host Mobility
Old Dst
Src
lt x, A gt
x
y
when shortest-path forwarding is used
A
D
lt x, A gt
Relay (for x)
G
B
New Dst
lt x, G gt
lt x, A gt
30
Unicast-based Bootstrapping ARP
  • ARP
  • Ethernet Broadcast requests
  • SEATTLE Hash-based on-demand address resolution

31
Unicast-based Bootstrapping DHCP
  • DHCP
  • Ethernet Broadcast requests and replies
  • SEATTLE Utilize DHCP relay agent (RFC 2131)
  • Proxy resolution by ingress switches via
    unicasting

32
Control-Plane Scalability When Using Relays
  • Minimal overhead for disseminating host-location
    information
  • Each hosts location is advertised to only two
    switches
  • Small forwarding tables
  • The number of host information entries over all
    switches leads to O(H), not O(SH)
  • Simple and robust mobility support
  • When a host moves, updating only its relay
    suffices
  • No forwarding loop created since update is atomic

33
Data-Plane Efficiency w/o Compromise
  • Price for path optimization
  • Additional control messages for on-demand
    resolution
  • Larger forwarding tables
  • Control overhead for updating stale info of
    mobile hosts
  • The gain is much bigger than the cost
  • Because most hosts maintain a small, static
    communities of interest (COIs) Aiello et al.,
    PAM05
  • Classical analogy COI ? Working Set
    (WS) Caching is effective when a WS is small and
    static

34
SEATTLE Summary
  • SEATTLE is a plug-and-playable enterprise
    architecture ensuring both scalability and
    efficiency
  • Enabling design choices
  • Hash-based location management
  • Reactive location resolution and caching
  • Shortest-path forwarding
  • Lessons
  • Trading a little data-plane efficiency for huge
    control-plane scalability makes a qualitatively
    different system
  • Traffic patterns are our friends

35
VIRO Virtual Id Routing
  • Goal
  • How are the nodes (racks) inter-connected?
  • Typically a hierarchical inter-connection
    structure
  • Todays typical data center structure
  • Cisco recommended data center structure
  • starting from the bottom level
  • rack switches
  • 1-2 layers of (layer-2) aggregation switches
  • access routers
  • core routers
  • Is such an architecture good enough?

36
VIRO Virtual Id Routing
  • A Scalable, Robust, Plug--Play and
    Namespace-Independent Routing Arch. for Future
    Networks
  • (beyond simply large-scale Ethernets, )
  • Key Features
  • Separate identities (identifiers) from locations
    (locators)
  • introduce (hierarchical) virtual ids as
    locators
  • a topology-ware, self-organizing vid layer
  • Decouple routing/forwarding from
    addressing/naming
  • unify (traditional) layer 2 layer 3 data plane
    operations
  • routing/forwarding done using vids only (except
    first/last hop)
  • Support any namespaces (identifiers), whether
    flat or not!
  • native or application naming/address-independe
    nt
  • co-existence and inter-operability between diff.
    namespaces!
  • future-proof

37
VIRO Virtual Id Routing
  • More Key Features
  • Highly scalable, and fully take advantage of path
    diversity
  • DHT-like routing paradigm --- beyond
    shortest-path routing!
  • O(log N) routing table size
  • Ease to support multi-path routing dynamic
    load-balancing
  • And highly robust
  • eliminate (network-wide) control plane flooding!
  • localize failures, enable fast rerouting
    (pro-active!)
  • Other Important features
  • Allow for (logically centralized) network
    management
  • access and other policy control
  • also facilitate other security mechanisms
  • Can easily be adapted to support multiple
    topologies or virtualized network services

38
Virtual Id Layer and Vid Space
  • Topology-aware, structured virtual id (vid)
    space
  • Kademlia-like virtual binary tree
  • self-configurable and self-organizing

Other App Namespaces
IPv4/IPv6
Virtual ID Layer
Layer 2 Physical Network Topology
39
VIRO Three Core Components
  • Virtual id space construction and vid assignment
  • performed most at the bootstrap process (i.e.,
    network set up)
  • a vid space skeleton is created
  • once network is set up/vid space is constructed
  • a new node (a VIRO switch) joins assigned
    based on neighbors vids
  • end-host/device inherits a vid (prefix) from
    host switch (to which it is attached), plus a
    randomly assigned host id host may be agnostic
    of its vid
  • VIRO routing algorithm/protocol
  • DHT-style, but needs to build end-to-end
    connectivity/routes
  • a bottom-up, round-by-round process, no
    network-wide control flooding
  • O(log N) routing entries per node, N of VIRO
    switches
  • (Persistent) layer-2/3 address/name resolution
    and vid look-up
  • DHT directory services built on top of the same
    vid space
  • persistent identifier (e.g., MAC/IP address)
    hashed to a vid key, which is then used for
    (pid, vid) mapping registration, look-up, etc.
  • Data forwarding among VIRO switches using vid only

40
Vid Assignment Bootstrap Process
  • Initial vid assignment and vid space construction
    performed during the network bootstrap process
  • Depending on network operating environments, can
    be performed using either a centralized or
    distributed vid assignment algorithm, e.g.,
  • top-down graph-partition (centralized)
  • bottom-up clustering (distributed)

41
Vid Assignment Key Properties
  • Logical distance defined on the vid space
  • d(vidx, vidx) L lcp (vidy,vidy)
  • -- L max. tree height lcp longest common
    prefix
  • Key invariant properties (to ensure
    topology-aware)
  • closeness if two nodes are close in the vid
    space, then they are also close in the physical
    topology
  • esp., any two logical neighbors must be directly
    connected.
  • connectivity any two adjacent logical sub-trees
    must be physically connected.

L
42
VIRO Routing Key Features
  • Inspired by Kademlia DHT
  • but need to build end-to-end connectivity/routes!
  • Bottom-up, round-by-round process
  • first neighbor discovery
  • then build routing entries to reach nodes within
    each level of the vid space (virtual binary tree)
  • use publish-query mechanisms
  • Highly scalable O(L) routing entries per node
  • L ? O(log N), N number of nodes (VIRO switches)
  • more importantly, path diversity (e.g.,
    multi-path routing) can be naturally exploited
    for load-balancing, etc.
  • routing is no longer shortest path based !
  • No single point of failure, and localize effect
    of failures
  • unlike link state routing, node/link
    failure/recovery is not flooded network-wide
    impact scope is limited
  • also enable localized fast rerouting
  • Completely eliminate network-wide control
    flooding


43
VIRO Routing Some Definitions
  • For k 1, , L, and any node x
  • (level-k) sub-tree, denoted by Sk(x)
  • set of nodes within a logical distance of k from
    x
  • (level-k) bucket, denoted by Bk(x)
  • set of nodes exactly k logical distance from
    node x
  • (level-k) gateway, denoted Gk(x)
  • a node in Sk-1(x) which is connected to a node
    in Bk(x) is a gateway to reach Bk(x) for node x
    a direct neighbor of x that can reach this
    gateway node is a next-hop for this node

Example S1(A) A,F, B1(A)F, G1(A)A
S2(A) A,C,F, B2(A)C G2(A)A, S3(A)
A,B,C,D,E,F,G B3(A) B,D,E,G G3(A)
C,F
44
VIRO Routing Some Specifics
  • Bottom-up, round-by-round process
  • round 1 neighbor discovery
  • discover and find directly/locally connected
    neighbors
  • round k ( 2 ? k ? L)
  • build routing entry to reach level-k bucket Bk(x)
  • -- a list of one or more (gateway, next-hops)
  • use publish-query (rendezvous) mechanisms
  • Algorithm for building Bk(x) routing entry at
    node x
  • if a node(x) is directly connected to a node in
    Bk(x), then it is a gateway for Bk(x), and also
    publishes it within Sk-1(x).
  • nexthop to reach Bk(x) direct physical neighbor
    in Bk(x)
  • else node x queries within Sk-1(x) to discover
    gateway(s) to reach Bk(x)
  • nexthop to reach Bk(x) nexthop(gateway)
  • Correctness of the algorithm can be formally
    established.

45
VIRO Routing Example
  • Round 1
  • each node x discovers and learns about its
    directly/locally connected neighbors
  • build the level-1 routing entry to reach nodes in
    B1(x)
  • E.g. Node A discover two direct neighbors, C,
    F
  • build the level-1 routing entry to reach
    B1(A)F

Routing Table for node A
46
Other VIRO Features (not discussed in paper)
  • Multi-path routing dynamic load-balancing
  • Esp., can Valiant load-balancing can be adopted
  • use of forwarding directives
  • to ensure no forwarding loops!
  • Failure Management and Fast Re-routing
  • Namespace and network management
  • can/should be logically centralized
  • declarative paradigm?
  • Network security (?)
  • access control
  • network monitoring, defend against
    denial-of-service,
  • Virtual topologies/services network
    virtualization
About PowerShow.com