Internet2 QBone:
Building a Testbed for
Differentiated Services
Benjamin Teitelbaum, Internet2 (UCAID)
Susan Hares, Merit Network
Larry Dunn, Cisco Systems
Robert Neilson, British Columbia Institute of Technology
Vishy Narayan, Raytheon, NASA Ames Research Center
Francis Reichmeyer, IPHighway
Outline
 DiffServ
 Internet2
 QBone Initiative
 QBone Architecture
 Deployment plan
 Conclusions
DiffServ
 Exploits edge/core distinction for scalability
 Applications contract for specific QoS profiles
-
-
Policing at network periphery
A few simple, differentiated per-hop forwarding behaviors
(PHBs)
Indicated with a DSCP in packet IP header field (DS field)
Applied to PHB traffic aggregates
 Domains contract for aggregate QoS traffic profiles
- Policing between domains boundaries
- Supports simple, bilateral business agreements
DiffServ(cont’d)
Bandwidth Brokers
A resource controller
 Makes decision for all hosts
 Can be a host, a router, or a software process on an exit
router.
 Perform admission control
 Manage network resources
 Configure leaf and edge devices

DiffServ (cont’d)
Options for Achieving End-to-End Resource Allocation
 Layer 2 Treatment in the Campus, Static Interdomain
Bandwidth Allocation
-
Not quite DiffServ
Gives packets differentiated treatment via layer 2 marking.
No explicit DS field marking is done
No dynamic signaling is required
 Host DS Field Marking, No Signaling
-
A minimalist DiffServ approach
A host makes packets with a particular DSCP
The resource provisioning within and between notworks is
static
-
Layer 3 devices (routers) might be configured in a bariety of
static ways
Individual flows are not recognized anywhere in the network,
not even at the edges
 Host DS Field Marking , No Signaling, Some Flow
Recognition Near Edge
-
An extension of the previous method
Some flow recognition occurs near the edge
 Local Signaling, Static Interdomain Provisioning
-
A host or application might dynamically signal for resources
Only the local DiffServ domain knows about the dynamic
resource requests
A BB and policy server might apply administrative policy and
dynamically keep track of intra-domain commitments
A BB reconfigures layer 3 devices
 Single-Ended Signaling, with Inter-BB Communication
-
An extension of previous method
A host or application might express needs to an intradomain
BB
BBs in different DiffServ domains communicate with each
other
 Double-End Signaling Inter-BB Communication
-
RSVP is used to signal resource requirements in AS-1
RSVP messages are tunneled through AS-T
AS-3 uses the RSVP messages to allow more precise
destnation resource allocation
Internet2
Primary Technical Objective
 Engineer scalable, interoperable, and administrable
interdomain QoS to enable new advanced IP networked
applications
-
distance learing
remote instrument access and control
adcanced scientific visualization
networked collaboratories
Requirements for Internet2 QoS
-
-
-
need to meet the absolute end-to-end performance
requirements of a broad range of advanced applications
Any viable approach must scale, allowing core routers
to support thousands of QoS-enabled flows at high
forwarding rates
Any viable approach must interoperate, making it
possible to get well-defined interdomain QoS
assurances by concatenating the QoS capabilities of
several independently configured and administered
network clouds.
Internet2 QBone Initiative
 Build interdomain testbed infrasturcture


Experiment and improve understanding of DiffServ
Incrementally improve testbed
 Support intradomain & interdomain deployment
 Lead and follow IETF standards work
- Some parts of DiffServ architecture cooked; others far
from it
QBone Architecture
 IETF “Diff” (EF PHB) + QBone “Serv” (QPS)
 QBone Premium Service
-
-
Approximates the “Premium” service proposed by
Jacobson
Exploits the EF per-hop forwarding behavior


PeakRate R and Service MTU M implying a token bucket
meter
Near-zero loss: there should be almost no packet loss; in
particular, there must be no packet loss duo to congestion


Low latency: the queuing delay within a QPS reservation will
be minimal;however, no assumptions regarding minimal
latency routing are made
Low jitter : delay variation due to queuing effects should be
no greater than the explicit bound jitter.
 Contains several value-adds:
- integrated measurement infrastructure/dissemination
infrastructure
- experimentation with pre-standards interdomain
bandwidth brokering and signaling
Measurement Achitecture
 Specifies measurement metrics and the ways of
collecting and disseminating those data
 Measurement Metrics:required, suggested, and future
-
Required metrics: each domain must implement
One-way packet loss
One-way delay variation
Routing infoumation
Link utilization
- Suggested metrics: implementabe today as well as those that
are clearly desirable but are not yet well defined
EF and BE interface discards
One-way packet delay
Burst throughput







-
Future metrics: appear to be desirable, but for which efficient
way to measure them are not yet known
Routing metrics and application-specific metrics

 Measurement points
- All measurements are to be taken at or as close to
interdomain boundary routers as possible
- Each edge router of a Qbone domain must be
instrumented to serve as a Qbone measurement node
- When possible, active measurement probes should have
direct interfaces to boundary routre
- Passive measurement probes must observe the traffic on
interdomain links without perturbing it in any respect
- SnMP-style polling agents that extract MIBs to support
Qbone utilization metrics may be located anywhere
 Measurement Paths
-
-
Metrics that apply to a single interface are required to be
collected at each measurement point
Metrics that apply to interdomain paths are required to be
collected between each measurement point and all
measurement points of a neighboring Qbone domain
 Required Active Measurements
- EF and BE path losses
- Packet delay variation
- Traceroutes along EF and BE paths
 Required Passive Measurement
-
EF load, BE load
 Required provisioning metrics
- Link bandwidth
-
EF commitment
EF reservation load
Measurement (cont’d)
Dissemination:
 Provides a web site: http, for disseminating and presenting for
- MRTG-style plots
- Raw measurement data
 Specifies a uniform URL namespace for
- MRTG-style plots
- Raw measurement data
- http://
<root_URL>/<source_domain>/<dest_domain>/<first_hop>/
<data>/<type>.<aggregation>.{html | gif | txt }
 standardizes canonical names for
- metrics
- domains
 standardizes reporting formats for
- image report
- page report
- file report
-
Standard metric aggregations:

Mostly 5-minute aggregations
Security Considerations
 Intradomain Reservations
 Interdomain BB End-to-End Reservations
 Interdomain Issues for Ingress Routers
 Interaction of Non-DiffServ with DiffServ Domain
Deployment Plans and
Bandwidth Broker Trials
 Initial Deployment
-
Implement host DS field marking
No signaling
Some flow recognition near the edge
-
Bandwidth Broker Deployment

Phase 0: Local Admission
Operate within single DiffServ domain
Configure routers
Shape egress flows
Police ingress flows
Provide PHBs for QPS and BE services





 Phase 1: Informed Admission
 Operate between domains : implements the reservation
of end-to-end resources based on the static provisioning
of resources to support SLSes at DiffServ domain
boundaries
 Query the availability of resources in downstream
domains
 Make more intelligent admission control decisions
 Communicate in a peer-wise fashion
-
End-to-end signaling model
Immediate-response signaling model
 Phase 2: Dynamic Admission

Allowing the amount of available service to be adjusted
dynamically in response to resource requests
Conclusions
 Initiative, the QBone seeks to advance the state of
DiffServ technology and to support the emerging field
of DiffServ research.
 The QBone aims to start a process that will open the
horizon for new advanced networked applications to
flourish.
 The first wide-area test of the evolving differentiated
services architecture
 The first experimental deployment of an interdomain
DiffServ signaling protocol