Implementing A Very Simple Protocol

This page explains what would be involved in implementing a new protocol using an SPP by describing the SPP implementation of the very simple virtual circuit protocol (VSVCP). VSVCP is not a practical protocol and is incomplete. But a study of its implementation will be sufficient to understand the process of supporting a new protocol using an SPP; i.e., support a new metanet. We will also relate parts of the discussion to the IPv4 metanet implementation to give a broader perspective on implementation issues.

Example

A VSVCP Network

Two processes (endpoints) in a VSVCP network communicate over a virtual circuit. Each virtual circuit is identified by a Virtual Circuit Identifier (VCI) which is globally unique. Each VSVCP packet contains an eight-byte header that contains a VCI which is used by VSVCP routers to forward packets. (We ignore how endpoints acquire VCIs, and we assume that each VSVCP router is magically loaded with an appropriate forwarding table.)

A VSVCP forwarding table maps a VCI to a meta-interface. Note that a VSVCP header is immutable; i.e., it does not change during transit from the sender to the receiver (unlike an ATM cell header). As shown in the figure (right), a packet going from H1 to H6 has a VCI of 6 throughout its journey to H6. At R1, the forwarding table maps VCI 6 to meta-interface (MI) 4. At R2, the forwarding table maps VCI 6 to meta-interface (MI) XXX. Thus, there is a continuous forwarding path from H1 to H6.

VSVCP Header

A VSVCP header (right) contains eight bytes that make up four fields:

• 2-byte Virtual Circuit Identifier (VCI)
• 2-byte data length (DL)
• 2-byte header checksum (HC)
• 2-byte reserved field

The VCI field is used by routers for forwarding. The DL field indicates the number of bytes in the data portion of the packet; i.e., it excludes the eight bytes in the header. The HC is an Internet checksum (ones complement sum of 16-bit integers) over the header.

For this example, we assume that communication patterns between hosts are injective; i.e., each host has atmost one sender. Thus, for simplicity, we assume that VCI x is used to communicate with host Hx.

Extensions

---

Very Simple Virtual Circuit Protocol

Notes to the Writer

Goals

• Describe basic user procedure
• Begin to describe underlying architecture and components
• Talk about substrate concept

Sections

• xxx

Figures

• Application header format
• xxx

Links

• Overview Of The SPP Architecture
• The GEC 4 Demo

Versions

• 0
  • Protocol header chosen to work with iperf
  • Words (4 bytes) in header
    • Pkt ID (iperf UDP compatible)
    • Timestamp tv_sec
    • Timestamp tv_usec
    • VCI
    • Flow label (used in v1)
  • VCI is globally unique
  • 0.0
    • Minimalistic example
    • 1 router (R1), 2 hosts (H1, H2)
  • 0.1
    • Add monitoring daemon
  • 0.2
    • Like GEC 4, Part 1 but routes based on VCI
    • 2 routers (R1, R2), 6 hosts (H1-H6)
• 1
  • VCI can change during transit as part of pkt processing
  • Add Flow Label field

Configuring R1.0.0

• Use 2 physical interfaces from GEC4
• Use 2 hosts H1 and H2
• Replace R2 in GEC4 with H2
• FP
  • copt = 2
  • bw = 205 Mb/s
  • fltrs = xxx
  • qs = xxx
  • buffs = xxx
  • stats = fltrs
  • sram = xxx
• MIs
  • m1 (to H1)
    • bw = 100 Mb/s
    • ipaddr = 10.1.1.1
    • port = 20000
    • i.e., socket s1 = (10.1.1.1, 20000)
  • m2 (to H2)
    • bw = 100 Mb/s
    • ipaddr = 10.1.16.1
    • port = 20000
    • i.e., socket s2 = (10.1.16.1, 20000)
• Queues
  • q48 (LD): threshold = 100 pkts, bw = 1 Mb/s, mi = 0
  • q49 (EX): threshold = 100 pkts, bw = 1 Mb/s, mi = 0
  • q1: threshold = 1000 pkts, bw = m0.bw = 100 Mb/s, mi = 1
  • q2: threshold = 1000 pkts, bw = m1.bw = 100 mb/s, mi = 2
  • q0: not used
• VCIs
  • (R1, H1, H2) = (0, 1, 2) ==> Path (x,y) uses VCI 3*x+y
    • (H1, H2) uses VCI 5 = 3*1 + 2
    • Use 6 of 9 VCIs
  • Communication matrix
    • ( R1 (-, 1, 2), H1 (3, -, 5), H2 (6, 7, -) )
    • Unused VCIs: 0, 4, 8
• Filters (key = rxmi, vci)
  • f1 (R1 to H1): (rxmi, vci) = (0, 1), s = (10.1.1.1, 20000), qid = 1, sindx = 1 # substrate only
  • f2 (R1 to H2): (rxmi, vci) = (0, 2), s = (10.1.16.2, 20000), qid = 2, sindx = 2 # substrate only
  • f3 (H1 to R1): (rxmi, vci) = (1, 3), s = (10.1.16.1, 5555), qid = 0, sindx = 3
  • f4 (H1 to H2): (rxmi, vci) = (1, 5), s = (10.1.16.2, 20000), qid = 2, sindx = 4
  • f5 (H2 to R1): (rxmi, vci) = (2, 6), s = (10.1.16.1, 5555), qid = 0, sindx = 5
  • f6 (H2 to H1): (rxmi, vci) = (2, 7), s = (10.1.1.1, 20000), qid = 1, sindx = 6

User-space pkt

• Tunnel socket appears in UDP header
• VCI is first word of UDP payload
• Payload also has timestamp (for RTT and space-time diagram)

Substrate Implementation Concepts

• Physical interfaces
• Physical MIs
• Queues
• Filters
• Code option demultiplexor
• Parse, Lookup, Header Format

Slowpath Implementation

• Filters for local delivery
• User-space process to handle LD and EX traffic
  • Has VCI-MI Socket map; i.e., M : VCI --> MI Socket
  • Forwards pkt to socket M(pkt.VCI)
• Artifacts
  • Tunnel-aware sender and receiver
  • User-space process to handle monitoring data
  • spp-config-sp-vsvc-XXX.sh (slowpath) configuration scripts

Fastpath Implementation

• Requires mods to Parse and Header Format
• Uses generic Lookup
• Additional artifacts
  • spp-config-fp-vsvc-XXX.sh (fastpath) configuration scripts
  • Monitoring

Interesting Demo

• xxx