{\page
 \name={QBone Architecture} 
 \author={Ben Teitelbaum} 
 \keywords={QBone Architecture}
 \description={QBone Architecture}
 {\qboneBody 
  {\h1 QBone Architecture}
  {\h2 Overview}

  The goal of the QBone architecture is to specify requirements for
  participation in an interdomain testbed where new IP services may be
  deployed and tested.  The emphasis of the architecture is on the
  requirements of "peering" QBone domains.

  The architecture has two main components: a {\a \href=#measurement
  measurement architecture} and a set of {\a \href=#services service
  specifications}.

  {\a \name=measurement}
  {\h3 Measurement Architecture}

  The QBone Measurement Architecture recommends the collections of a
  standard set of QoS metrics at interdomain peering points to assist
  in the auditing of service-level agreements and debugging of new
  services.  The specific needs of QBone services determine the
  metrics that are included.  Currently, the architecture requires the
  active collection of {\al ipdv IP delay variation}, {\al owloss
  one-way loss}, and traceroutes.  Also required is the passive
  collection of interface losses, loads, and link capacities.  All
  metrics are to be collected for both {\al EF Expedited Forwarding
  (EF)} and best-effort diff-serv code points.

  The measurement architecture also specifies a uniform mechanism for
  disseminating collected measurement data.  Currently, this is via
  HTTP and a standardized grammar for contructing queries.

  The measurement architecture is under review by the {\al arch-dt}.
\; Other dissemination mechanisms are under consideration.

  {\a \name=services}
  {\h3 Services}

  In the {\al qboneArch current draft} of the architecture, only one
  service is specified: {\al qps QBone Premium Service (QPS)}.  A {\al
  arch-dt design team} is working to revise the architecture to
  include the {\al QBSS QBone Scavenger Service (QBSS)} as a second
  QBone service.

  Though both are based on {\al diff-serv diff-serv}, QPS and QBSS are
  fundamentally different services with dramatically different
  requirements.  QPS aims to provide strong "virtual wire" like
  assurances end-to-end, requires strict policing at all trust
  boundaries, carefully provisioned priority queues on all interfaces,
  call admission control, and eventually some means of accounting to
  recoup the cost of provisioning an elevated service.

  QBSS, on the other hand, takes a nearly-opposite approach.  Users and
  upstream leaf networks voluntarilly mark some traffic for potentially
  downgraded treatment at downstream congestion points.

  Due to the {\a \href=premium/index.shtml#deployment great difficulty
  of deploying QPS}, the {\al qosWG} has shifted it's emphasis away
  from elevated services like QPS and towards light-weight,
  non-elevated services like {\al qbss QBSS} and {\al ABE} that may be
  deployed incrementally and cheaply.
  {\h3 Signaling}
  The {\al signaling-dt} is working on an inter-BB signaling protocol
  that might be incorporated in the architecture.
  {\h2 Current Work}

  The {\al qbArch Draft QBone Architecture} has admittedly grown stale
  since August, 1999. A {\al arch-dt design team} is
  working to revise the architecture to fix a number of known problems
  and orient the architecture to embrace new non-elevated services.

  }
}