Difference between revisions of "Implementing A Very Simple Protocol"

From ARL Wiki
Jump to navigationJump to search
Line 11: Line 11:
 
= Example =
 
= Example =
  
[[ Image:a-vsvcp-network.png | right | A VSVCP Network ]]
+
[[ Image:A-VSVCP-Network.png | thumb | right | A VSVCP Network ]]
  
 
Two processes (endpoints) in a VSVCP network communicate over a virtual circuit.
 
Two processes (endpoints) in a VSVCP network communicate over a virtual circuit.
Line 32: Line 32:
 
<br clear=all>
 
<br clear=all>
  
[[ Image:vsvcp-header.png | right | VSVCP Header ]]
+
[[ Image:VSVCP-Header.png | thumb | right | VSVCP Header ]]
  
 
A VSVCP header (right) contains eight bytes that make up four fields:
 
A VSVCP header (right) contains eight bytes that make up four fields:
Line 49: Line 49:
 
i.e., each host has atmost one sender.
 
i.e., each host has atmost one sender.
 
Thus, for simplicity, we assume that VCI ''x'' is used to communicate with host H''x''.
 
Thus, for simplicity, we assume that VCI ''x'' is used to communicate with host H''x''.
 +
In the example, H1 sends to H4 using VCI 4, and H4 responds to H1 using VCI 1;
 +
H2 sends to H5 using VCI 5, and H5 responds to H2 using VCI 2; and
 +
H3 sends to H6 using VCI 6, and H6 responds to H3 using VCI 3.
 +
But a process can also send to a GPE process running at router R''x'' using VCI 32768+''x'';
 +
e.g., VCI 32769 is used for communication with R1.
  
  
Line 59: Line 64:
 
= Extensions =
 
= Extensions =
  
<hr>
+
= Notes to the Writer =
  
 
Very Simple Virtual Circuit Protocol
 
Very Simple Virtual Circuit Protocol
 
= Notes to the Writer =
 
  
 
Goals
 
Goals

Revision as of 17:27, 9 July 2009

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

File:A-VSVCP-Network.png
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.


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. In the example, H1 sends to H4 using VCI 4, and H4 responds to H1 using VCI 1; H2 sends to H5 using VCI 5, and H5 responds to H2 using VCI 2; and H3 sends to H6 using VCI 6, and H6 responds to H3 using VCI 3. But a process can also send to a GPE process running at router Rx using VCI 32768+x; e.g., VCI 32769 is used for communication with R1.


Overview

Background

Required Changes

Extensions

Notes to the Writer

Very Simple Virtual Circuit Protocol

Goals

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

Sections

  • xxx

Figures

  • Application header format
  • xxx

Links

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