[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
Network Working Group                                   Jyh-Cheng Chen
INTERNET-DRAFT                           National Tsing Hua University
Internet Engineering Task Force                        Anthony McAuley
draft-itsumo-dsnp-03.txt                  Telcordia Technologies, Inc.
Date: February 15, 2006                             Venkatesh Sarangan
Expires: August 19, 2006                     Oklahoma State University
                                                         Shinichi Baba
                                                   Toshiba Corporation
                                                        Yoshihiro Ohba
                                         Toshiba America Research Inc.



               Dynamic Service Negotiation Protocol (DSNP)

Status of this memo

   By submitting this Internet-Draft,  each author represents that any
   applicable patent or  other IPR claims of which he  or she is aware
   have been or will be disclosed,  and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are  working documents of  the Internet Engineering
   Task Force  (IETF), its areas,  and its working groups.   Note that
   other   groups   may   also   distribute   working   documents   as
   Internet-Drafts.

   Internet-Drafts  are draft  documents valid  for a  maximum  of six
   months  and  may  be  updated,  replaced,  or  obsoleted  by  other
   documents at any time.   It is inappropriate to use Internet-Drafts
   as  reference material  or  to cite  them  other than  as "work  in
   progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 19, 2006.

Copyright Notice



J.-C. Chen, et al.        Expires  August 2006                [Page 1]


Internet Draft                   DSNP                    February 2006


   Copyright (C) The Internet Society (2006).

Abstract

   This memo presents the specification of Dynamic Service Negotiation
   Protocol (DSNP).  DSNP is a  protocol to negotiate the SLS (Service
   Level  Specification) in  IP layer.   It  can be  used for  service
   negotiation from host  to network, network to host,  and network to
   network.   The  automated  negotiation  makes  service  negotiation
   efficient in terms of time, cost, and correctness, etc. The dynamic
   negotiation not only allows users to adapt their needs dynamically,
   but  also  let providers  better  utilize  the  network.  The  DSNP
   messages and packet formats are  detailed. DSNP can be used in both
   wireline  and  wireless  networks.   It is,  however,  particularly
   useful  in mobile  environment.  To  demonstrate the  usefulness of
   DSNP,   a  reference  wireless   QoS  architecture   is  presented.
   Exemplary applications are illustrated.

Table of Contents

   1.    Introduction
   2.    Protocol Overview
   3.    DSNP Messages
   4.    Basic Operation
   4.1   Reference Architecture
   4.2   Reference QoS Architecture
   4.3   Distribution of QoS Profile and Traffic Conditioning
   5.    Example Applications
   5.1   Initial QoS Negotiation
   5.2   Client Moves within the Same Domain
   5.3   Client Renegotiates SLS within the Same Domain
   5.4   Client Moves into a New Domain
   6.    DSNP Message Format
   7.    Acknowledgments
   8.    References
   9.    Authors' Addresses

1. Introduction

   Today,  many different  wireless systems  exist, ranging  from PANs
   (Personal Area  Networks), wireless  LANs (Local Area  Networks) to
   outdoor cellular  systems. They  are typically not  compatible with
   each  other,  making  it  difficult  to roam  from  one  system  to
   another.  PANs, Wireless  LANs, and  cellular wireless  systems are
   also being developed and  are evolving independently (e.g., from 3G
   to 4G,  802.11 to 802.11a/802.11b, HIPERLAN to  HIPERLAN II, etc.).
   Although   ITU  IMT-2000   [IMT97]   has  been   trying  to   unify



J.-C. Chen, et al.        Expires  August 2006                [Page 2]


Internet Draft                   DSNP                    February 2006

   third-generation  (3G) wireless  systems, incompatible  systems are
   expected  to co-exist in  the future.   No wireless  technology has
   emerged as a common and long-term universal solution.

   IP (Internet Protocol), which  is already a universal network-layer
   protocol  for wireline  packet  networks, is  becoming a  promising
   universal network-layer protocol over  all wireless systems.  An IP
   device,  with multiple  radio interfaces  or software  radio, could
   roam between different wireless systems if they all support IP as a
   common network  layer.  Unlike today's radio  systems that continue
   to  depend  heavily  on  proprietary technologies,  IP  provides  a
   globally   successful   open   infrastructure  for   services   and
   applications.  Such  an all-IP wireless and  wireline network could
   also  make  wireless  networks  more  robust,  scalable,  and  cost
   effective.

   A key challenge in realizing the all-IP wireless networks is how to
   guarantee  Quality  of Service  (QoS).   To  guarantee  QoS on  the
   Internet,  Int-Serv  (Integrated  Services) [INT94]  and  Diff-Serv
   (Differentiated Services)  [DIFF98], which differ  in the technique
   for   resource  provisioning   and  the   granularity   of  service
   differentiation, have been proposed.  Both approaches, however, are
   limited to  stationary hosts  and cannot be  applied to  the mobile
   environment directly.

   Today the  service level agreement (SLA) is  usually agreed, either
   verbally or in  writing, by both the user  and the service provider
   when a user signs up for a service.  The service provider stores it
   in some  repository and  uses it to  condition the  traffic sending
   to/from the user. To change the SLA, normally a user has to contact
   and  negotiate with the  authority of  the service  provider, which
   then  manually changes  it.  Usually  service provider  allows this
   kind of re-negotiation  or changes only in a  large time scale, for
   instance, once per year.

   It  is expected  that a  user will  use a  different  terminal with
   different capability in different situation. For example, PC may be
   used at  home or  inside an office.   While driving,  small handset
   might be more suitable.  PDA or laptop will be used when traveling.
   They are  different not  only in size,  but also in  processing and
   communication  capabilities. Different  applications  will also  be
   used  in  different terminals.   They  generally require  different
   bandwidth for network transmission.

   As stated  above, mobility and the diversity  in transmission media
   (Bluetooth,  802.11,  cellular,  etc.)   and  user  terminals  (PC,
   laptop, PDA, etc.) create a very dynamic environment.  It is hardly
   for a service provider to plan uniform resource in all networks and



J.-C. Chen, et al.        Expires  August 2006                [Page 3]


Internet Draft                   DSNP                    February 2006

   to envision fixed bandwidth  requirement from all users.  Users are
   also hardly  to project what they  really need due  to mobility and
   the difference in terminal they  may carry.  In addition, users may
   roam to  other service providers and  still wish to  enjoy the same
   QoS as they had in the home provider. It is desirable that there is
   a way  to negotiate the service dynamically.   This dynamic service
   negotiation should be automated and should be able to do in a small
   time scale  in opposite  to today's manual  negotiation in  a large
   time scale.  A  user should be able to negotiate  with the home and
   visiting  service  providers  dynamically. Similarly,  the  service
   provider can also  negotiate with a user depending  on the resource
   available.  A service provider may advertise unused resource if the
   resource is  underutilized.  On the other hand,  a service provider
   can  negotiate with  users  to  lower their  service  grade if  the
   network is  over-provisioned. While the  user is roaming,  the home
   and visiting providers  should also be able to  negotiate with each
   other  to decide  the service  which can  be offered  to  the user.
   There should be  a standard protocol which can  be used for service
   negotiation for multi-vendors and multi-service providers.

2. Protocol Overview

   DSNP  (Dynamic  Service  Negotiation  Protocol) is  a  protocol  to
   dynamically  negotiate   the  SLS  (Service   Level  Specification)
   [DIFF01] in  IP layer.   DSNP can be  used for  service negotiation
   from host to network, network to host, and network to network.  The
   automated negotiation makes  service negotiation efficient in terms
   of time, cost, and correctness, etc.

   DSNP can  be used in both  wireline and wireless  networks.  It is,
   however, particularly useful in mobile environment.  For example, a
   mobile user may roam to a  new service provider which does not have
   any  contract  with either  the  mobile  user  or its  old  service
   provider.  The inter-domain negotiation might be necessary in order
   to get network service.  Even though the old and new providers have
   certain level  of service agreement,  the new service  provider may
   still  need  to negotiate  with  the  old  service provider.   When
   roaming inside  the same domain, the following  are some motivation
   to support dynamic intra-domain negotiation:

   (1) A  user may  carry a  different terminal  at different  time to
       access the network.  The capabilities of these terminals may be
       different,  thus  the  network  resource  requirements  may  be
       different too.

   (2) A user  may roam to  networks with different physical  and link
       layers, for  instance, from Bluetooth  to IEEE 802.11  to IS-95
       (or  other outdoor cellular  systems).  The  available resource



J.-C. Chen, et al.        Expires  August 2006                [Page 4]


Internet Draft                   DSNP                    February 2006

       typically are different in different type of networks.

   (3) Due to  mobility, the provisioning of network  resource may not
       be accurate for actual demand.  For example, a special event in
       a city may gather many unexpected network users.

   Dynamic service  negotiation not only  allows users to  adapt their
   needs dynamically, but also let the service provider better utilize
   the network.

   Service negotiation  may involve  human.  If so,  some applications
   may  be  needed.   The  user  or  the  service  provider  may  also
   pre-define and  store their policy  so the negotiation can  be done
   without human interactions.  In either case, DSNP is a protocol for
   hosts and networks to negotiate SLS in IP layer.

   DSNP can be used in  any architecture frameworks. It is independent
   of   network  architecture,   and  how   resource   reservation  or
   provisioning  is done.   DSNP, however,  is particularly  useful in
   Diff-Serv  [DIFF98].   Diff-Serv  is   built  on  the   concept  of
   classifying packets  and keeping per-customer state  at the network
   edge  and letting  the core  deal with  aggregates of  traffic.  In
   operation, routers use DS (Diff-Serv) byte to differentiate traffic
   flows  belonging to  different service  classes.  The  edge routers
   perform conditioning  functions to  keep traffic "in  profile" with
   the TCA (Traffic Conditioning Agreement).

   In order to  condition the traffic properly, the  edge router needs
   to know  the QoS profile of a  user.  The changes in  SLS should be
   known by  the necessary edge routers (ERs).  In mobile environment,
   there should be an efficient way to distribute mobile's QoS profile
   to  possible  ERs.  It  is  also desirable  to  reduce  QoS-related
   signalling  messages  for every  handoff  so  fast  handoff can  be
   achieved.

   Next  section  presents  the  DSNP messages.   To  demonstrate  the
   usefulness of  DSNP, Section  4 presents a  reference architecture,
   then shows  a way to distribute  QoS profile once  a negotiation is
   done so mobile users can  perform fast handoff while also guarantee
   the same level of QoS.  Section 5 shows some exemplary applications
   of DSNP. The DSNP message format is presented in Section 6.

3. DSNP Messages

3.1 Terminology

   3.1.1 DSNP Client




J.-C. Chen, et al.        Expires  August 2006                [Page 5]


Internet Draft                   DSNP                    February 2006

      A DSNP client is the one that initiates the SLS negotiation.

   3.1.2 DSNP Server

      A DSNP server is the one that responds to the SLS negotiation.

   For  example, when  a  host  wants to  negotiate  with the  service
   provider for a  SLS, the host acts as the  DSNP client. The service
   provider acts  as the DSNP  server. When a service  provider starts
   the SLS negotiation  with a host, the service  provider acts as the
   DSNP client  and the host acts  as the DSNP server.  When a service
   provider negotiates a SLS with another service provider, the former
   acts as the DSNP client and the latter acts as the DSNP server.

3.2 DSNP Message Types

   This  section  explains  the  various  messages used  in  DSNP.  An
   intra-domain negotiation  scenario is assumed.  A host acts  as the
   DSNP client and a service provider's QoS authority acts as the DSNP
   server.

   o SLS_LIST_REQUEST:  This message is sent  by a DSNP  client to the
         DSNP  server, to  request for  a  list of  SLSs offered  by
         the  DSNP server. A DSNP client may send this message when it
         has just booted up  and  does  not have  any  idea about  the
         services  provided by  the network.

   o SLS_LIST_RESPONSE: This  message is  sent by  the DSNP  server in
        response to the  SLS_LIST_REQUEST message.  This message lists
        all the  SLSs that are provided  by the DSNP  server. The cost
        and  the time  of availability  for each  service may  also be
        included in the list.

   o SLS_NEGO_REQUEST: This message is  usually sent by an DSNP client
        to  the DSNP  server, to  request for  a particular  SLS.  The
        requested  SLS could  either  be customized  or  one of  those
        listed in  the SLS_LIST_RESPONSE message.  The  time for which
        the SLS is requested may also be included in the message. This
        message  is used  for both  requesting a  new SLS  as  well as
        updating an existing one.

        The DSNP server can also  send this message to the hosts under
        some circumstances.  For example, if  network resources become
        scarce, the  DSNP serversends this  message to the  hosts that
        have  a SLS  with the  DSNP server  requesting them  to update
        their existing SLS to suit the current network conditions. The
        DSNP  server could  offer cost  incentives to  the  hosts that
        accept  the suggested  SLS. Similarly,  when there  are unused



J.-C. Chen, et al.        Expires  August 2006                [Page 6]


Internet Draft                   DSNP                    February 2006

        resources  available, the DSNP  server could  offer them  at a
        lower price to the DSNP clients.  It could do an advertisement
        by  sending out SLS_NEGO_REQUEST  messages with  the available
        SLSs  and  the  cost.  Also,  if  the  DSNP  server  wants  to
        forcefully  terminate a  SLS of  an  DSNP client  due to  some
        reason, it sends a SLS_NEGO_REQUEST message to the DSNP client
        with appropriate fields set to ZERO.

   o  SLS_NEGO_RESPONSE:  This message  is  sent  in  response to  the
        SLS_NEGO_REQUEST. This message indicates whether the requested
        SLS  was  accepted or  not.   If  the  requested SLS  was  not
        accepted,  then   the  reason   for  not  accepting   is  also
        provided. For example, if the  DSNP server does not accept the
        SLS of an DSNP client due  to lack of resources, it sends back
        a SLS_NEGO_RESPONSE indicating a reject along with the maximum
        SLS that could be supported.

   o SLS_STAT_REQUEST:  This message is sent  by a DSNP  client to the
        DSNP Server  asking for  a feedback on  the statistics  of the
        actual  usage of  each SLS.   The  DSNP client  could ask  for
        statistics  like  packet   loss,  throughput,  average  delay,
        jitter, and total number  of octets sent from/forwarded to the
        DSNP client.

  o  SLS_STAT_RESPONSE: This  message is  sent by  the DSNP  server in
        response  to  a  SLS_STAT_REQUEST  message.  The  DSNP  server
        collects  the  necessary  information  and  sends  it  to  the
        requested DSNP client.

   The  above   message  types   are  explained  in   an  intra-domain
   negotiation scenario.  The same messages  could also be used  in an
   inter-domain  negotiation.  In  an  inter-domain  negotiation,  one
   network  requests for  some service  (and  hence acts  as the  DSNP
   client)  and the other  provides the  requested service  (and hence
   acts the DSNP server). The  nature of interaction hence remains the
   same as in an intra-domain negotiation.

4. Basic Operation

4.1 Reference Architecture

   To  demonstrate   the  usefulness  of  DSNP,  we   use  the  ITSUMO
   architecture  as a  reference architecture.  DSNP, however,  can be
   used in any network architecture.

   ITSUMO [ITSUMO00] is a research  project that focuses on the design
   of  next  generation  IP  networks.   It  envisions  an  end-to-end
   wireless/wireline   IP  platform   for  supporting   real-time  and



J.-C. Chen, et al.        Expires  August 2006                [Page 7]


Internet Draft                   DSNP                    February 2006

   non-real-time multimedia  services in the  future.  Its goal  is to
   use  IP  and next  generation  wireless  technologies  to design  a
   wireless platform  that allows mobile users to  access all services
   on a next generation Internet.

   Figure 1 depicts the end-to-end  packet platform of ITSUMO's all IP
   wireless/wireline network,  which comprises all  IP wireless access
   networks and a packet switched IP backbone network. The IP backbone
   network  is  an end-to-end  wireline  IP  infrastructure that  will
   comprise  regional   providers'  wireline  IP   networks  that  are
   connected through the  Internet. Besides mobile stations/terminals,
   a  wireless access network  also comprises  a radio  access network
   (RAN),  and an  edge router  and controller  (ERC)  [ITSUMO99].  In
   order to support the needs  of its users, a wireless access network
   interacts  with the  network  control entities  that  are shown  as
   Domain Control  Agent (DCA) in Figure  1.  What follows  is a brief
   description of these elements and their functions.

   4.1.1 Mobile Station (MS)

      It is the user mobile terminal that allows users to communicate,
      and  also provides  means  of interactions  and control  between
      users and the network.

   4.1.2 Radio Access Network (RAN)

      The  radio  access network  (RAN)  represents  the wireless  and
      back-haul infrastructure that  provides MSs with wireless access
      to the  wireline infrastructure.  A RAN usually  comprises a set
      of  base  stations and  base  station  controllers. In  IMT-2000
      [IMT97],  RANs  use  programmable  software  radios  to  provide
      flexibility across frequency bands at the MS and across the RAN.
      ITSUMO  strives to  remain independent  from the  underlying RAN
      technology  and to  minimize the  restriction  (or requirements)
      that it places on (or expects from) a RAN.

   4.1.3 Edge Router & Controller (ERC)

      An ERC is a routing  and control system that connects a wireless
      access  network to  a  regional wireline  IP network.   Although
      Figure  1 depicts one  RAN per  ERC, in  practice, each  ERC may
      support several RANs. An  ERC comprises two functional entities,
      an edge router (ER) and an  edge control agent (ECA).  The ER is
      an  IP  router, while  the  ECA  is  an intelligent  agent  that
      interacts  with the domain  control agent  (DCA) to  control the
      RANs as well as support necessary network-wide control tasks. In
      the IP parlance,  each ERC is the default gateway  of all IP MSs
      that are supported by RANs that are connected to it.



J.-C. Chen, et al.        Expires  August 2006                [Page 8]


Internet Draft                   DSNP                    February 2006


   4.1.4 Domain Control Agent (DCA)

      The domain control agent (DCA) provides connection management as
      well as means for  interaction between users and network control
      system     and     interaction     among     network     control
      entities.  Furthermore,  the  DCA  also supports:  (1)  Mobility
      management,  (2) Authentication,  Authorization,  and Accounting
      (AAA),  and  (3) QoS  management  (MAAAQ)  functions for  mobile
      users.  These functional entities usually reside on the wireline
      backbone,  and are  part of  the overall  control system  of the
      end-to-end  platform.   As  Figure  1  indicates  the  home  and
      visiting  DCA entities  may either  interact directly  or  via a
      third  party Inter-Domain  Control  Agent (IDCA)  on the  global
      Internet.   In the  latter case,  the  IDCA entity  serves as  a
      trusted broker between the home and visiting network DCAs.



  <-- Visiting Network -->                    <---- Home Network ---->

                           +---------------+
                           | Inter-Domain  |
                           | Control Agent |
                           +---------------+
                                   |
                                   |
    +---------------+              |              +---------------+
    |    Domain     |              |              |    Domain     |
    | Control Agent |              |              | Control Agent |
    +---------------+              |              +---------------+
           |                       |                       |
        ___|___                 ___|___                 ___|___
       /       \               /       \               /       \
      /         \             /         \             /         \
     /Regional IP\___________/  Internet \___________/Regional IP\
     \  Network  /           \           /           \  Network  /
      \         /             \         /             \         /
    ---\_______/---            \_______/            ---\_______/---
    |             |                                 |             |
  +-----+        +-----+                         +-----+       +-----+
  | ERC |        | ERC |                         | ERC |       | ERC |
  +-----+        +-----+                         +-----+       +-----+
      |             |                               |            |
      |             |                               |            |
      |             |                               |            |
    __|__         __|__                           __|__        __|__
   /     \       /     \                         /     \      /     \



J.-C. Chen, et al.        Expires  August 2006                [Page 9]


Internet Draft                   DSNP                    February 2006

  / Radio \     / Radio \                       / Radio \    / Radio \
 / Access  \   / Access  \                     / Access  \  / Access  \
 \ Network /   \ Network /                     \ Network /  \ Network /
  \       /     \       /                       \       /    \       /
   \_____/       \_____/                         \_____/      \_____/
      |             |                               |            |
      v             v                               v            v
    +----+        +----+                          +----+       +----+
    | MS |        | MS |                          | MS |       | MS |
    +----+        +----+                          +----+       +----+


           FIGURE 1: ITSUMO long term network architecture

4.2 Reference QoS Architecture

   This section  presents a reference QoS architecture  which is based
   on the ITSUMO overall  architecture.  Again, DSNP is independent of
   QoS architecture.




 <----------- DOMAIN 1 -----------> <---------- DOMAIN 2 ------------->

    +--------------+                            +---------------+
    |  QoS Global  |                            |  QoS Global   |
    | Server (QGS) |                            | Server (QGS)  |
    +--------------+                            +---------------+
           |                                             |
        ___|___                _______                ___|___
       /       \              /       \              /       \
      /         \            /         \            /         \
     /Regional IP\__________/ Global IP \__________/Regional IP\
     \  Network  /          \  Network  /          \  Network  /
      \         /---------\  \         /  ----------\         /
     --\_______/---        \  \_______/   |          \_______/-----
     |            |         \             |          |            |
   +-----+     +-----+     +-----+     +-----+     +-----+     +-----+
   | QLN |     | QLN |     | QLN |     | QLN |     | QLN |     | QLN |
   +-----+     +-----+     +-----+     +-----+     +-----+     +-----+
    __|__       __|__       __|__       __|__       __|__       __|__
   /     \     /     \     /     \     /     \     /     \     /     \
  / Radio \   / Radio \   / Radio \   / Radio \   / Radio \   / Radio \
 / Access  \ / Access  \ / Access  \ / Access  \ / Access  \ / Access  \
 \ Network / \ Network / \ Network / \ Network / \ Network / \ Network /
  \       /   \       /   \       /   \       /   \       /   \       /
   \_____/     \_____/     \_____/     \_____/     \_____/     \_____/



J.-C. Chen, et al.        Expires  August 2006                [Page 10]


Internet Draft                   DSNP                    February 2006

      |           |           |           |           |           |
      v           v           v           v           v           v
    +----+
    | MS | -->
    +----+

                 FIGURE 2: Reference QoS architecture



   As that in  the ITSUMO overall architecture, there  is at least one
   logical   global   server  and   several   local   nodes  in   each
   administrative domain.  The server is referred to as the QoS Global
   Server (or QGS), and local nodes are referred to as QoS local nodes
   (or QLN).  The  architecture is depicted in Figure  2.  In addition
   to   other   necessary   components   in   the   system   such   as
   DHCP[DHCP97]/DRCP[DRCP00] server, AAA,  etc., there are three major
   QoS components:

   4.2.1 MS (Mobile Station)

      MS  is the  device that  allows users  to communicate,  and also
      provides means  of interaction  between users and  the networks.
      Traffic is generated/received by MS  and may be queued in the MS
      while waiting for transmission/reception.

   4.2.2 QGS (QoS Global Server)

      As  shown  in  Figure  2,  there  is one  logical  QGS  in  each
      administrative domain.   The QGS  has the global  information of
      the resource available in  the whole domain.  Essentially, it is
      a bandwidth broker with extension for wireless networks.  The MS
      interacts with  the QGS when  the MS requests certain  degree of
      QoS in  the domain.  The QGS  is the entity  for QoS negotiation
      and signaling  between MS and  the network control  system, i.e.
      it is in control plan, as that of MGC (Media Gateway Controller)
      in  MEGACO  [MEGACO00].   The  QGS  decides  what  services  are
      available for  each MS and  sends the decision to  related QLNs.
      Thus, the QGS  is an intelligent entity for  decision making. It
      is similar  to PDP (Policy  Decision Point) in  Policy Framework
      [POLICY00].

   4.2.3 QLN (QoS Local Node)

      QLN  is the  edge  router residing  in  the boundary  of the  DS
      domain.  Figure  2 depicts that QLN  could be part  of ERC (Edge
      Router & Controller), or could  reside in a component inside RAN
      (radio access network) such as BS (base station).  QLN is like a



J.-C. Chen, et al.        Expires  August 2006                [Page 11]


Internet Draft                   DSNP                    February 2006

      wireless bandwidth broker which retains the local information of
      the resource in the local domain.  However QLN does not interact
      with MS  directly for QoS negotiation and  signaling.  In stead,
      this local information is provided to the QGS. QLN then performs
      traffic  conditioning  according  to  the instruction  from  the
      QGS. Therefore, it functions like PEP (Policy Enforcement Point)
      in Policy Framework [POLICY00].  In contrast to QGS, QLN handles
      the actual traffic thus it  is in transport plane, similar to MG
      (Media Gateway) in MEGACO [MEGACO00].

   Please note,  the QGSs in  domain 1 and  domain 2 may  contact with
   each other  directly, or through a  public QGS which  may attach to
   the "Global IP Network" in Figure 2.

   Since   QGS   retains  the   global   information   of  the   whole
   administrative domain, dynamic  service negotiation can be achieved
   easily and  efficiently. The  MS only needs  to negotiate  with the
   QGS,  which  makes the  decision  based  on  the up-to-date  global
   information. Once  it is  done, the QGS  will instruct  the related
   QLNs how to condition the MS's traffic.  Therefore, the MS can move
   freely inside  the domain. How  does the QGS allocate  resource and
   reach the  decision can be done  in many different  ways which have
   been proposed  in literature. By separating  control and transport,
   the architecture is  also flexible, easy to add  new services, easy
   to   integrate  with   other  network   components,  and   easy  to
   interoperate with legacy networks.

   One can  also distribute the intelligence and  functionality of QGS
   to  all  QLNs,  which  makes  a different  QoS  architecture.   The
   discussion of QoS  architecture is outside the scope  of this memo.
   We simply use the QoS  architecture defined above to illustrate the
   applications of DSNP.

4.3 Distribution of QoS profile and Traffic Conditioning

   In wired network, it is easy to locate a user, therefore it is easy
   to locate the  edge router that will need  to condition the traffic
   for a specific user. In  wireless networks, however, users can roam
   anywhere. Thus potentially  all edge routers will need  to know the
   QoS profile of a users.  One straightforward solution is to let all
   edge  routers  in the  domain  maintain  the  QoS profiles  of  all
   users. Each time  when service negotiation is done,  the new SLS is
   broadcast  to all  edge routers.   It is,  however,  inefficient to
   maintain  the same copy  of data  in all  edge routers.   It causes
   unnecessary broadcast  too. If  the number of  edge routers  in the
   domain  is huge,  the  data are  replicated  unnecessarily in  many
   places. The database in each edge  router will be huge too if there
   are  many users  in the  domain. In  addition, once  a MS  moves or



J.-C. Chen, et al.        Expires  August 2006                [Page 12]


Internet Draft                   DSNP                    February 2006

   changes  its SLS, the  same transaction  for updating  the database
   must  be performed  for all  edge routers.   Many edge  routers may
   never have traffic coming from or going to the MS.

   It is  desirable to maintain the  QoS profiles of all  users in the
   domain only  in a  central repository. Edge  routers only  keep the
   necessary data without maintaining the QoS profiles of all users in
   the domain. Referring to  the QoS architecture presented in Section
   4.2, the QGS of the domain  retains the database of all users. Each
   time when  the service negotiation is  done, the QGS  sends the new
   SLS of the  user to potential QLNs only. The  potential QLNs may be
   the neighboring QLNs of current  serving QLN. Each time when the MS
   moves, the  QGS can select the  new set of potential  QLNs, as that
   the  QGS  maintains the  global  information  and  is the  decision
   maker. Therefore, the  QoS profile of the MS  can be distributed to
   the new  QLN before the MS  moves. Since everything is  done by the
   network, the MS does not need to perform QoS-related signaling once
   the  initial negotiation  is done.   It reduces  the amount  of QoS
   signaling  messages,  conserves  MS's  energy,  and  achieves  fast
   handoff.

5. Example Applications

5.1 Initial QoS Negotiation

   When a MS is powered up,  first it may need to perform registration
   and configuration with  DHCP/DRCP to get an IP  address. Before the
   MS sends  actual traffic, it  initiates the QoS signaling  with the
   QGS if there is no service agreement or the MS wants to renegotiate
   it.   The QGS  may need  to consult  with AAA  or other  servers if
   necessary.  Based on the interaction with other servers, the global
   information in  QGS, service agreement, and  other information such
   as mobility pattern, etc., the  QGS will either admit or reject the
   QoS request. If the request is accepted, the SLS for the MS will be
   multicast to the  potential QLNs. As discussed in  Section 4.3, the
   potential  set of  QLNs may  include  current serving  QLN and  its
   neighboring QLNs.

   Figure 3  shows an example in  that the MS  uses DHCP to get  an IP
   address for the  subnet in the initial set-up. It  then makes a QoS
   request for the  list of available SLS. Based  on the response, the
   MS negotiates with QGS for the  SLS it wants. The QGS consults with
   AAA server, then makes the  decision. Assuming that the QGS decides
   to offers certain kind of service  to the MS. It sends the decision
   to  the  related  QLNs  so  they can  condition  the  MS's  traffic
   accordingly. COPS  [COPS00] or  SNMP [SNMP99] can  be used  for the
   communication   between   QGS  and   QLNs.   After  receiving   the
   SLS_NEGO_RESPONSE, the MS can send its actual traffic.



J.-C. Chen, et al.        Expires  August 2006                [Page 13]


Internet Draft                   DSNP                    February 2006


                     DHCP                       AAA
    MS              Server        QGS          Server        QLNi

     |                |            |             |            |
     | DHCP DISCOVER  |            |             |            |
     |--------------->|            |             |            |
     | DHCP OFFER     |            |             |            |
     |<---------------|            |             |            |
     | DHCP REQUEST   |            |             |            |
     |--------------->|            |             |            |
     | DHCP ACK       |            |             |            |
     |<---------------|            |             |            |
     |                |            |             |            |
     |                             |             |            |
     |     SLS_LIST_REQUEST        |             |            |
     |---------------------------->|             |            |
     |                             |             |            |
     |     SLS_LIST_RESPONSE       |             |            |
     |<----------------------------|             |            |
     |                             |             |            |
     |     SLS_NEGO_REQUEST        |             |            |
     |---------------------------->|             |            |
     |                             | AAA REQUEST |            |
     |                             |------------>|            |
     |                             | AAA RESPOND |            |
     |                             |<------------|            |
     |                             |             |            |
     |                             |                          |
     |                             |         UPDATE           |
     |                             |------------------------->|
     |                             |           ACK            |
     |                             |<-------------------------|
     |                             |                          |
     |      SLS_NEGO_RESPONSE      |                          |
     |<----------------------------|                          |
     |                             |                          |
     |                                                        |
     |                                                        |
     |                    actual traffic                      |
     |<------------------------------------------------------>|
     |                                                        |

              * QLNi indicates the potential set of QLNs

              FIGURE 3: Example flow for initial set-up

5.2 Client Moves within the Same Domain



J.-C. Chen, et al.        Expires  August 2006                [Page 14]


Internet Draft                   DSNP                    February 2006


   When the MS is roaming inside the same administrative domain, i.e.,
   the domain serving by the same QGS,  the MS only needs to get a new
   IP address  if changing subnet.  It  does not need to  have any QoS
   signaling since the  decision made by the QGS has  been sent to all
   potential QLNs. As  discussed in Section 4.3, the  set of potential
   QLNs may be  changed dynamically while the MS  is moving.  Thus the
   MS  can   transmit/receive  traffic  without   initiating  new  QoS
   signaling while it is moving within the same administrative domain.
   Figure 4 is  an example flow for moving within  the same domain but
   the subnet is changed.

                            DHCP
    MS                     Server            QLNi               QGS

     |     DHCP DISCOVER     |                |                  |
     |---------------------->|                |                  |
     |     DHCP OFFER        |                |                  |
     |<----------------------|                |                  |
     |     DHCP REQUEST      |                |                  |
     |---------------------->|                |                  |
     |     DHCP ACK          |                |                  |
     |<----------------------|                |                  |
     |                       |                |                  |
     |                                        |                  |
     |            actual traffic              |                  |
     |<-------------------------------------->|                  |
     |                                        |                  |

       FIGURE 4: Example flow for moving within the same domain

5.3 Client Renegotiates SLS within the Same Domain

   Once the MS is  up and the QoS negotiation is done,  the MS is free
   to  move within  the same  domain  without any  QoS signaling.   As
   discussed before,  however, the MS may  want to change  the SLS and
   renegotiate with the network for  the service level. Figure 5 plots
   an example flow for this. It is similar to Figure 3 except that the
   MS has the IP address and the list of SLS already.

                                                AAA
    MS                            QGS          Server        QLNi

     |                             |             |            |
     |     SLS_NEGO_REQUEST        |             |            |
     |---------------------------->|             |            |
     |                             | AAA REQUEST |            |
     |                             |------------>|            |



J.-C. Chen, et al.        Expires  August 2006                [Page 15]


Internet Draft                   DSNP                    February 2006

     |                             | AAA RESPOND |            |
     |                             |<------------|            |
     |                             |             |            |
     |                             |                          |
     |                             |         UPDATE           |
     |                             |------------------------->|
     |                             |           ACK            |
     |                             |<-------------------------|
     |                             |                          |
     |      SLS_NEGO_RESPONSE      |                          |
     |<----------------------------|                          |
     |                             |                          |
     |                                                        |
     |                                                        |
     |                    actual traffic                      |
     |<------------------------------------------------------>|
     |                                                        |

 FIGURE 5: Example flow for renegotiating SLS within the same domain

5.4 Client Moves into a New Domain

   When the MS moves to  a new administrative domain, it must initiate
   the QoS  signaling with the new  QGS. The new QGS  may consult with
   the  new AAA  server, old  AAA server,  and the  old QGS  to decide
   whether it should admit or  reject the QoS request.  After that, it
   is similar to  what described above.  Figure 6  presents an example
   flow when the MS roams to a new domain.

          New DHCP    New       New     Previous  Previous    New
   MS      Server     QGS       AAA       QGS       AAA       QLNi

   |         |         |         |         |         |         |
   | DHCP    |         |         |         |         |         |
   | DISCOVER|         |         |         |         |         |
   |-------->|         |         |         |         |         |
   | DHCP    |         |         |         |         |         |
   | OFFER   |         |         |         |         |         |
   |<--------|         |         |         |         |         |
   | DHCP    |         |         |         |         |         |
   | REQUEST |         |         |         |         |         |
   |-------->|         |         |         |         |         |
   | DHCP    |         |         |         |         |         |
   | ACK     |         |         |         |         |         |
   |<--------|         |         |         |         |         |
   |                   |         |         |         |         |
   | SLS_NEGO_REQUEST  |         |         |         |         |
   |------------------>|         |         |         |         |



J.-C. Chen, et al.        Expires  August 2006                [Page 16]


Internet Draft                   DSNP                    February 2006

   |                   | AAA     |         |         |         |
   |                   | REQUEST |         |         |         |
   |                   |-------->|                   |         |
   |                   |         |    AAA REQUEST    |         |
   |                   |         |------------------>|         |
   |                   |         |    AAA RESPOND    |         |
   |                   |         |<------------------|         |
   |                   | AAA     |                   |         |
   |                   | RESPOND |                   |         |
   |                   |<--------|                   |         |
   |                   |                   |         |         |
   |                   | SLS_NEGO REQUEST  |         |         |
   |                   |------------------>|         |         |
   |                   | SLS_NEGO_RESPONSE |         |         |
   |                   |<------------------|         |         |
   |                   |                   |         |         |
   |                   |                                       |
   |                   |               UPDATE                  |
   |                   |-------------------------------------->|
   |                   |                 ACK                   |
   |                   |<--------------------------------------|
   | SLS_NEGO_RESPONSE |                                       |
   |<------------------|                                       |
   |                   |                                       |
   |                                                           |
   |                        actual traffic                     |
   |<--------------------------------------------------------->|
   |                                                           |

          FIGURE 6: Example flow for roaming to a new domain

6. DSNP Message Format

   All DSNP messages are sent  in UDP/IP packets to special DSNP ports
   and are  network byte ordered. The  size of the fields  is shown in
   braces.

6.1 SLS_LIST_REQUEST


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           op(2)               |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |          UID(variable)                        |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |



J.-C. Chen, et al.        Expires  August 2006                [Page 17]


Internet Draft                   DSNP                    February 2006

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        The various fields are :

        FIELD                   OCTETS                  DESCRIPTION
        -----                   ------                  -----------
         op                       2                     Message Opcode
        AttrMap                   2                     Attribute Map
         UID                    variable                Universal identifier
                                                        for the host.
        UIDlen                    1                     Length of the UID
                                                        field

   6.1.1 Opcode

      The opcode field has two octets. The first octet indicates which
      of the six messages described  in section 3 is being transmitted
      or received. The possible values for the first octet are:

        Octet Value             Message Type
        -----------             ------------
        0 0 0 0 0 0 0 0         SLS_LIST_REQUEST
        0 0 0 0 0 0 0 1         SLS_LIST_RESPONSE
        0 0 0 0 0 0 1 0         SLS_NEGO_REQUEST
        0 0 0 0 0 0 1 1         SLS_NEGO_RESPONSE
        0 0 0 0 0 1 0 0         SLS_STAT_REQUEST
        0 0 0 0 0 1 0 1         SLS_STAT_RESPONSE

     Each type  of DSNP message  has associated sub-types.  The second
     octet indicates  the sub-type of the DSNP  message. However, this
     message SLS_LIST_REQUEST has no sub-types. Hence the second octet
     will be assigned zero. The use  of the second octet will be clear
     in the DSNP messages.

   6.1.2 AttrMap

     The AttrMap field has two octets.  This field is a bit map of the
     attributes the DSNP client  is interested in negotiating with the
     DSNP  server.  In  this version  of DSNP,  only the  bits  in the
     second octet are used in the bitmap.  The first octet is reserved
     for future use.

    Bit Position                Associated Attribute
    -------------               --------------------
        1                               Scope
        2                               Flow specification
        3                               Traffic description



J.-C. Chen, et al.        Expires  August 2006                [Page 18]


Internet Draft                   DSNP                    February 2006

        4                               Traffic guarantees
        5                               Service schedule
        6                               Unused
        7                               Unused
        8                               Unused

     For  example, if  the DSNP  client sends  bitmap 00001110  in the
     SLS_LIST_REQUEST message, it means that it is requesting only the
     flow  specification, traffic  description and  traffic guarantees
     (and not the  scope or the service schedule)  of the various SLSs
     provided by the  DSNP server.  The field AttrMap  is thus used to
     indicate the set of attributes that are negotiated between a DSNP
     client and the DSNP server. The second octet in opcode identifies
     which attribute of the set is being negotiated.

   6.1.3 UID

      This filed is the universal identifier for the DSNP client.  For
      example, this could be the IPv4 home address of the DSNP client,
      or the Network Access Identifier (NAI) [NAI99].

6.2 SLS_LIST_RESPONSE

   The semantic  content of SLS has associated  attributes. The second
   octet  in the  opcode indicates  which of  the these  attributes is
   being  dealt by  the message.   So far,  five attributes  have been
   identified. They are :

                - Scope of the SLS
                - Flow specification
                - Traffic description and conformance testing
                - Performance guarantees
                - Service schedule

   The second  octet indicates the  sub-type within each of  the above
   six messages. The possible values for the second octet are:

        Octet Value             Sub-Type
        ------------            --------
       0 0 0 0 0 0 0 0           Initial message
       0 0 0 0 0 0 0 1           Scope
       0 0 0 0 0 0 1 0           Flow specification
       0 0 0 0 0 0 1 1           Traffic description
       0 0 0 0 0 1 0 0           Traffic guarantees
       0 0 0 0 0 1 0 1           Service schedule


   There are five sub-types within the SLS_LIST_RESPONSE message.



J.-C. Chen, et al.        Expires  August 2006                [Page 19]


Internet Draft                   DSNP                    February 2006


   6.2.1 SLS_LIST_RESPONSE: Initial message

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           op(2)               |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |          UID(variable)                        |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This  message  is  sent  in  response  to  the  SLS_LIST_REQUEST
      message.   All fields are  in the  same as  in SLS_LIST_RESPONSE
      except  that  three  new  fields  SlsAvail(1),  SlsIndex(1)  and
      SlsId(2) are included.

      6.2.1.1  SlsAvail

         In response to the  SLS_LIST_REQUEST message, the DSNP server
         could send a  list of SLSs available to  the DSNP client. The
         field SlsAvail  indicates the total  number of SLSs  that are
         being sent.

      6.2.1.2  SlsIndex

         SlsIndex  indicates the  number of  the current  SLS  that is
         being sent.

     6.2.1.3  SlsId

         SlsId is the identifier for the SLS that is being sent.

     In this  message, the second  octet of the  field "op" is  set to
     zero, indicating that, none of the SLS attributes are transmitted
     in  that  packet.   Subsequent  to  the  above  SLS_LIST_RESPONSE
     message,  the  DSNP  server  sends  additional  SLS_LIST_RESPONSE
     messages  that  describe  the  attributes  of  the  various  SLSs
     offered.  The DSNP server  sends back  only those  attributes the
     DSNP  client  requested for  using  the  "AttrMap"  field of  the
     SLS_LIST_REQUEST message.  For each attribute that is begin sent,
     the second octet in the opcode is set appropriately.

   6.2.2 SLS_LIST_RESPONSE: Sending the scope




J.-C. Chen, et al.        Expires  August 2006                [Page 20]


Internet Draft                   DSNP                    February 2006

      The scope  of a  SLS indicates the  topology of  the reservation
      with reference to the end-points of the traffic flow.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        NumIngRtr(2)           |         NumEgrRtr(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                  Ingress_list (variable)                      |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                    Egress_list (variable)                     |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      All fields  are common to the  initial SLS_RESPONSE_MESSAGE sent
      but  for the  inclusion of  the following  fields: NumIngRtr(2),
      NumEgrRtr(2),             Ingress_list(variable)             and
      Egress_list(variable). The  second octet in the  opcode field is
      set to 00000001 to indicate the attribute scope is being sent in
      this message.

      6.2.2.1  NumIngRtr

         This field indicates the number of Ingress routers associated
         with the scope.

      6.2.2.2  NumEgrRtr

         This field indicates the  number of Egress routers associated
         with the scope.

      6.2.2.3  Ingress_list

         This field is the address  list of the ingress routers in the
         scope.




J.-C. Chen, et al.        Expires  August 2006                [Page 21]


Internet Draft                   DSNP                    February 2006

      6.2.2.4  Egress_list

         This filed is  the address list of the  egress routers in the
         scope.

   6.2.3 SLS_LIST_RESPONSE: Sending the flow

      Flow  identification  aims in  creating  an association  between
      packets and SLSs. The Term  "flow" refers to a stream of packets
      that are related.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Length (1)   | FlowType(1)   |  NumFlows(1)  |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Src IP address (4)                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Dest IP address (4)                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Proto(1)    |  DS Byte (1)  |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        source port number (4)                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Destination port number (4)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                        Rest_flows(variable)                   |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The second  octet in the opcode  is set to  00000010 to indicate
      that  flow  information about  the  SLS  is  being sent  in  the
      packet.  The following  fields are  present in  this  message in
      addition to the fields already  introduced:

      6.2.3.1 Length

         This field indicates the length of the message in bytes.




J.-C. Chen, et al.        Expires  August 2006                [Page 22]


Internet Draft                   DSNP                    February 2006

      6.2.3.2 FlowType

         This field  indicates whether the  flow specification contains
         only  one flow  -  Simple  flow or  multiple  flows -  Complex
         flow. The complex  flow is the logical OR of  the set of flows
         specified.

           Field        FlowType
           -----        --------
           00000000     Simple flow
           00000001     Complex flow

     6.2.3.3 Numflows

        This  field  indicates the  number  of  flows  present in  the
        specification.  In  the case of  simple flow, this  field will
        have a value 1, indicating  only one flow is specified. In the
        case of a complex flow, this  field will have a value equal to
        the number of flows.

     6.2.3.4 Src Ip address

        This field indicates the source IP address associated with the
        flow.  This could be a wild card entry or a IP address.

     6.2.3.5 Dest Ip address

        This field  gives the  destination IP address  associated with
        the flow.  This could be a wild card entry or a IP address.

     6.2.3.6 Proto

        This filed  gives the protocol  associated with the  flow. For
        example, this could be either TCP or UDP.

     6.2.3.7 DS Byte

        This filed gives the DS byte marking associated with the flow.
        Please  note   that  this   field  indicates  only   the  DSNP
        client-marking    value.    This     is    only    for    flow
        identification.  The  core routers  do  not  take any  routing
        decision based on this byte.

     6.2.3.8 Source port number

        This field  gives the source  port number associated  with the
        flow. This could be a wild card entry or a valid port number.




J.-C. Chen, et al.        Expires  August 2006                [Page 23]


Internet Draft                   DSNP                    February 2006

     6.2.3.9 Destination Port number

        This filed  gives the destination port  number associated with
        the flow.   This could be  a wild card  entry or a  valid port
        number.

     6.2.3.10 Rest_flows

        This  portion of  the  packet contains  information about  the
        additional  flows in  case  a complex  flow  is defined.  This
        includes  fields  from 6.2.3.4  to  6.2.3.9  for  each of  the
        remaining flows.


   6.2.4 SLS_LIST_RESPONSE:  Sending   the  traffic  description  and
        conformance parameters

      The traffic description aims to provide an effective description
      of the traffic relevant to the reservation.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             SR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            BSS  (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             PR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             BSP (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             EAR (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              M (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              m (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        The opcode field is set appropriately to indicate that traffic
        description  parameters are being  sent. The  following fields



J.-C. Chen, et al.        Expires  August 2006                [Page 24]


Internet Draft                   DSNP                    February 2006

        are present, in addition to the fields already before:

        6.2.4.1 SR

           This field indicates the Sustainable Rate in bit/s.

        6.2.4.2 BSS

           This field gives the Bucket size in bytes for SR.

        6.2.4.3 PR

           This field gives the peak rate of the traffic in bit/s.

        6.2.4.4 BSP

           This field gives the bucket size in bytes for PR.

        6.2.4.5 EAR

           This field gives the  Expected Average Rate for the traffic
           in bit/s.

        6.2.4.6  M

           This field gives the maximum allowed packet size in bytes.

        6.2.4.7 m

           This field gives the minimum policed unit.


   6.2.5 SLS_LIST_RESPONSE: Sending the performance guarantees

      The performance guarantee attributes describe the QoS parameters
      enjoyed by the flow specified by the flow id, with the specified
      scope  and  conforming  to  the  specified  traffic  conformance
      attributes.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



J.-C. Chen, et al.        Expires  August 2006                [Page 25]


Internet Draft                   DSNP                    February 2006

        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |G|  unused     |          QntDelayPercentile(3)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           QntJitterPercentile (3)             | QntMaxLoss(1) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntMaxDelay (2)        |       QntMaxJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntAveDelay (2)        |       QntAveJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  QltDelay (1) |  QltJitter(1) | QltLoss (1)   |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The second byte  in the opcode is set  appropriately to indicate
      that performance guarantee  attributes are being exchanged.  The
      following  fields  are  present   in  addition  to  the  already
      explained fields :

      6.2.5.1 G

         This field  is only  one bit wide  and indicates  whether the
         performance  guarantee is  qualitative  or quantitative.  '0'
         indicates qualitative and '1' indicates quantitative.

      6.2.5.2 QntDelayPercentile

         This filed  indicates the quantitative  delay percentile. The
         first octet  in this field  indicates the percentile  and the
         next two octets indicate the delay value in ms.

      6.2.5.3 QntJitterPercentile

         This filed indicates  the quantitative jitter percentile. The
         first octet  in this field  indicates the percentile  and the
         next two octets indicate the jitter value in ms.

      6.2.5.4 QntMaxLoss

         This field  gives the quantitative maximum loss  ratio of the
         packets.

      6.2.5.5 QntMaxDelay

         This field gives the quantitative maximum delay in ms.

      6.2.5.7 QntMaxJitter

         This field gives the quantitative maximum jitter in ms.



J.-C. Chen, et al.        Expires  August 2006                [Page 26]


Internet Draft                   DSNP                    February 2006


      6.2.5.8 QntAveDelay

         This field gives the quantitative average delay in ms.

      6.2.5.9 QntAveJitter

         This field gives the quantitative average jitter in ms.

      6.2.5.10 QltDelay

         This field  gives the qualitative delay.  The possible values
         are high, medium, low, very low.

           Field           Qualitative Delay Value
           -----          -----------------------
           00000000             High
           00000001             medium
           00000010             low
           00000011             very low

      6.2.5.11 QltJitter

         This field gives the  qualitative jitter. The possible values
         are high, medium, low, very low.

           Field           Qualitative Jitter Value
           -----          ------------------------
           00000000             High
           00000001             medium
           00000010             low
           00000011             very low

      6.2.5.11 QltLoss

         This  field gives  the qualitative  loss ratio.  The possible
         values are high, medium, low, very low.

         Field           Qualitative Loss ratio
         -----            ------------------------
         00000000               High
         00000001               medium
         00000010               low
         00000011               very low







J.-C. Chen, et al.        Expires  August 2006                [Page 27]


Internet Draft                   DSNP                    February 2006

   6.2.6 SLS_LIST_RESPONSE: Sending the service schedule

      The servie schedule attributes provide information regarding the
      start and duration of the service.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SlsAvail(1)  |  SlsIndex(1)  |       SlsId(2)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SchType(1)   |    StrDay(1)  |       StartTime(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  EndDay(1)    |        EndTime(2)             |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The second byte  in the opcode is set  appropriately to indicate
      that the  service schedule  attributes are being  exchanged. The
      following  fields  are  present   in  addition  to  the  already
      explained :

       6.2.6.1 SchType

          This field indicates the  type of the schedule. The schedule
          could   be  Immediate  and   dynamic  (like   the  telephone
          connections), or periodic  or advance reservation with start
          date-time and end date-time specified.

            Field             Schedule Type
            -----              --------------

            00000001            Immediate
            00000010            Periodic
            00000011            Advance reservation


       6.2.6.2 StrDay

          This field  indicates the starting  day of the  service. The
          values are offset from the current day. For example, a value
          of 0 would  indicate the current day and a  value of 1 would
          indicate the next day.




J.-C. Chen, et al.        Expires  August 2006                [Page 28]


Internet Draft                   DSNP                    February 2006

       6.2.6.3 StartTime

          This field  indicates the start  time of the service  on the
          day specified in the StrDay field.

       6.2.6.4 EndDay

          This  field indicates  the ending  day of  the  service. The
          values are offset from the current day.

       6.2.6.5 EndTime

          This field indicates  the ending time of the  service on the
          day specified in the EndDay field.



6.3 SLS_NEGO_REQUEST

   This message is used by the DSNP client to negotiate the QoS with a
   DSNP server.  As in  the SLS_LIST_RESPONSE message, the DSNP client
   starts  by sending an  initial SLS_NEGO_REQUEST  message indicating
   the SLS  attributes it wants to negotiate.   Then subsequently, the
   DSNP client sends more messages with the actual SLS attributes.


   6.3.1 SLS_NEGO_REQUEST: Initial message


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                    options(variable)                          |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet  in the opcode is set  to "00000010" to indicate
      that it is  a SLS_NEGO_REQUEST message. The second  octet is set
      to "00000000"  to indicate that  this is the initial  message in
      the negotiation. The AttrMap  field is set suitably depending on
      the attributes the DSNP client wants to negotiate.



J.-C. Chen, et al.        Expires  August 2006                [Page 29]


Internet Draft                   DSNP                    February 2006


   6.3.2 SLS_NEGO_REQUEST: To negotiate the scope

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |        AttrMap(2)             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        NumIngRtr(2)           |         NumEgrRtr(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                  Ingress_list (variable)                      |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                    Egress_list (variable)                     |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      The first octet in the opcode is set to 0000010 to indicate that
      it is a SLS_NEGO_REQUEST and  the second octet is set to 0000001
      to  indicate that scope  is being  negotiated.  The  DSNP client
      sets appropriate values to other fields and sends the message to
      the DSNP server.

   6.3.2 SLS_NEGO_REQUEST: To negotiate the flow

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Length (1)   | FlowType(1)   |  NumFlows(1)  |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Src IP address (4)                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Dest IP address (4)                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Proto(1)    |  DS Byte (1)  |                               |



J.-C. Chen, et al.        Expires  August 2006                [Page 30]


Internet Draft                   DSNP                    February 2006

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        source port number (4)                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Destination port number (4)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |          Information about rest of the flows (variable)       |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000010 to indicate that
      it is a SLS_NEGO_REQUEST and  the second octet is set to 0000010
      to indicate that flow is being negotiated.  The DSNP client sets
      appropriate values to other fields  and sends the message to the
      DSNP server.


   6.3.3 SLS_NEGO_REQUEST: To negotiate the traffic description and
   conformance parameters

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |             UID(variable)                     |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             SR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            BSS  (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             PR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             BSP (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             EAR (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              M (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              m (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000010 to indicate that
      it is a SLS_NEGO_REQUEST and  the second octet is set to 0000011
      to  indicate  that  traffic  conformance  parameters  are  being
      negotiated.  The DSNP  client sets  appropriate values  to other



J.-C. Chen, et al.        Expires  August 2006                [Page 31]


Internet Draft                   DSNP                    February 2006

      fields and sends the message to the DSNP server.

   6.3.4 SLS_NEGO_REQUEST: To negotiate the performance guarantees


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |G|  unused     |          QntDelayPercentile(3)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           QntJitterPercentile (3)             | QntMaxLoss(1) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntMaxDelay (2)        |       QntMaxJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntAveDelay (2)        |       QntAveJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  QltDelay (1) |  QltJitter(1) | QltLoss (1)   |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000010 to indicate that
      it is a SLS_NEGO_REQUEST and the second octet is set to 00000100
      to  indicate  that performance  guarantee  parameters are  being
      negotiated.  The DSNP  client sets  appropriate values  to other
      fields and sends the message to the DSNP server.


   6.3.5 SLS_NEGO_REQUEST: To negotiate the service schedule

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            op(2)              |           AttrMap(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    UIDlen(1)  |        UID(variable)                          |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SchType(1)   |    StrDay(1)  |       StartTime(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  EndDay(1)    |        EndTime(2)             |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




J.-C. Chen, et al.        Expires  August 2006                [Page 32]


Internet Draft                   DSNP                    February 2006

      The first octet in the opcode is set to 0000010 to indicate that
      it is a SLS_NEGO_REQUEST and the second octet is set to 00000101
      to indicate  that the service schedule is  being negotiated. The
      DSNP client  sets appropriate values  to other fields  and sends
      the message to the DSNP server.


6.4 SLS_NEGO_RESPONSE

   This  message is  sent by  the DSNP  server to  the DSNP  client in
   response  to  the  SLS_NEGO_REQUEST.   As in  the  SLS_NEGO_REQUEST
   message,   the   DSNP  server   starts   by   sending  an   initial
   SLS_NEGO_RESPONSE  message indicating whether  the request  made by
   the DSNP client is accepted or not. If the request is accepted, the
   subsequent messages that follow confirm the parameters chose by the
   DSNP  client.  If the  SLS_NEGO_REQUEST is  not accepted,  then the
   messages that  follow tell  the DSNP client  the SLS that  could be
   supported.


   6.4.1 SLS_NEGO_RESPONSE: Initial message

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | UIDlen(1)     |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    options(variable)                          |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to
      00000000  to   indicate  that   the  initial  response   to  the
      SLS_NEGO_REQUEST  is being  sent.  All the  fields  are same  as
      explained before but for the "A" field.

      6.4.1.1 A

         The A bit indicates whether  the DSNP client's SLS request is
         accepted or not.   If the A bit is set to  '1', it means that
         the request was  accepted. If the A bit is  not set, it means



J.-C. Chen, et al.        Expires  August 2006                [Page 33]


Internet Draft                   DSNP                    February 2006

         that the request was not accepted.

   6.4.2 SLS_NEGO_RESPONSE: Sending the scope attributes

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        NumIngRtr(2)           |         NumEgrRtr(2)          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                  Ingress_list (variable)                      |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                    Egress_list (variable)                     |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to
      00000001 to indicate that the scope parameters are being sent.

    6.4.3 SLS_NEGO_REQUEST: Sending the flow attributes

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | UIDlen(1)     |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Length (1)   | FlowType(1)   |  NumFlows(1)  |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Src IP address (4)                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Dest IP address (4)                     |



J.-C. Chen, et al.        Expires  August 2006                [Page 34]


Internet Draft                   DSNP                    February 2006

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Proto(1)    |  DS Byte (1)  |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        source port number (4)                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Destination port number (4)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |          Information about rest of the flows (variable)       |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to
      00000010 to indicate that the flow parameters are being sent.


    6.4.4  SLS_NEGO_REQUEST: Sending  the traffic  conformance  and
         description attributes

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   UIDlen(1)   |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             SR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            BSS  (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             PR (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             BSP (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                             EAR (4)                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              M (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                              m (4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to



J.-C. Chen, et al.        Expires  August 2006                [Page 35]


Internet Draft                   DSNP                    February 2006

      00000011   to  indicate   that  the   traffic   conformance  and
      description parameters are being sent.

   6.4.5 SLS_NEGO_REQUEST: Sending the performance guarantee attributes

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | UIDlen(1)     |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |G|  unused     |          QntDelayPercentile(3)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           QntJitterPercentile (3)             | QntMaxLoss(1) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntMaxDelay (2)        |       QntMaxJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntAveDelay (2)        |       QntAveJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  QltDelay (1) |  QltJitter(1) | QltLoss (1)   |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to
      00000100 to  indicate that the  performance guarantee attributes
      are being sent.


   6.4.6 SLS_NEGO_REQUEST: Sending the service schedule attributes

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         AttrMap(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |A|                   unused                                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  SchType(1)   |    StrDay(1)  |       StartTime(2)            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



J.-C. Chen, et al.        Expires  August 2006                [Page 36]


Internet Draft                   DSNP                    February 2006

        |  EndDay(1)    |        EndTime(2)             |               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The first octet in the opcode is set to 0000011 to indicate that
      it  is  a SLS_NEGO_RESPONSE  and  the  second  octet is  set  to
      00000101 to  indicate that  the service schedule  attributes are
      being sent.


6.5 SLS_STAT_REQUEST

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         unused                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | UIDlen(1)     |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first octet in the opcode  field is set to 00000100 to indicate
   that this is a SLS_STAT_REQUEST message. The second octet is set to
   zero.   Unlike  other  DSNP   messages  seen   so  far,   only  one
   SLS_STAT_REQUEST message is sent.

6.6 SLS_STAT_RESPONSE

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       op(2)                   |         unused                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  UIDlen(1)    |           UID(variable)                       |
        +-+-+-+-+-+-+-+-+                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    unused     |          QntDelayPercentile(3)                |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           QntJitterPercentile (3)             | QntMaxLoss(1) |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntMaxDelay (2)        |       QntMaxJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |        QntAveDelay (2)        |       QntAveJitter(2)         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         OctSent(4)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         OctRcvd (4)                           |



J.-C. Chen, et al.        Expires  August 2006                [Page 37]


Internet Draft                   DSNP                    February 2006

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first octet in the opcode  field is set to 00000101 to indicate
   that this is  a SLS_STAT_RESPONSE message. The second  octet is set
   to zero. Like  SLS_STAT_REQUEST message, only one SLS_STAT_RESPONSE
   is  sent.  The  following  fields are  unique to  SLS_STAT_RESPONSE
   message:

   6.6.1 OctSent

      This field  indicates the total  number of octets sent  from the
      DSNP client.

   6.6.2 OctRcvd

      This field indicates the total number of octets forwarded to the
      DSNP client.

7. Acknowledgments

   The authors wish to  acknowledge the contributions of other members
   of  the ITSUMO (Internet  Technologies Supporting  Universal Mobile
   Operation)  team from  Telcordia Technologies  and  Toshiba America
   Research Incorporated.

   (TM):  ITSUMO  (Internet  Technology  Supporting  Universal  Mobile
   Operation)  is a  trademark of  Telcordia. It  is a  joint research
   project of Telcordia Technologies and Toshiba America Research Inc.
   (TARI).  It envisions an  end-to-end wireless/wireline  IP platform
   for supporting  real-time and non-real-time  multimedia services in
   the future.   Its goal is to  use IP and  third generation wireless
   technologies to design a wireless platform that allows mobile users
   to  access multimedia services  on a  next generation  Internet. In
   Japanese, ITSUMO means all the time, anytime.

8. References

   [COPS00] D. Durham, et al.,  "The COPS (Common Open Policy Service)
       Protocol", IETF RFC 2748, Jan. 2000.

   [DHCP97] R.  Droms, "Dynamic Host Configuration Protocol", IETF RFC
       2131, Mar. 1997.

   [DIFF01] D. Grossman, "New Terminology for Diffserv", IETF Internet
       Draft,    <draft-ietf-diffserv-new-terms-04.txt>,    work    in
       progress, Mar. 2001.

   [DIFF98] S.  Blake, D. Black, M.  Carlson, E. Davies,  Z. Wang, and



J.-C. Chen, et al.        Expires  August 2006                [Page 38]


Internet Draft                   DSNP                    February 2006

       W. Weiss,  "An Architecture for  Differentiated Services", IETF
       RFC 2475, Dec. 1998.

   [DRCP00]  A.  McAuley,  S.   Das,  S.  Madhani,  S.   Baba, and  Y.
       Shobatake,  "Dynamic  Registration  and Configuration  Protocol
       (DRCP)", IETF  Internet Draft, <draft-itsumo-drcp-01.txt>, work
       in progress, Jul. 2000.

   [IMT97]     ITU-R    Rec.     M.687-2,     "International    Mobile
       Telecommunications-2000 (IMT-2000)", 1997.

   [INT94] R.  Braden, D. Clark, and S.  Shenker, "Integrated Services
       in  the Internet  Architecture:  an Overview",  IETF RFC  1633,
       Jun. 1994.

   [ITSUMO00] ITSUMO Group, "Benchmarking  of ITSUMO's All IP Wireless
       Architecture", mwif2000.028, Jan. 28, 2000.

   [ITSUMO99] ITSUMO  Group, "Evolution of  Wireless Telephony Towards
       Voice over 3G-IP", 3GPP2-P00-19990824-010, Aug. 23, 1999.

   [MEGACO00] F.  Cuervo, et al., "Megaco Protocol  Version 1.0", IETF
       RFC 3015, Nov. 2000.

   [NAI99] B.  Aboba and M. Beadles, "The  Network Access Identifier",
       IETF RFC 2486, Jan. 1999.

   [POLICY00]  R.  Yavatkar, et  al.,  "A  Framework for  Policy-based
       Admission Control", IETF RFC 2753, Jan. 2000.

   [SNMP99]  J.  Case, et  al.,  "Introduction  to  Version 3  of  the
       Internet-standard Network Management Framework", IETF RFC 2570,
       Apr. 1999.

9. Authors' Addresses

   Jyh-Cheng Chen
   Department of Computer Science
   National Tsing Hua University
   Hsinchu 300, Taiwan
   Phone: +886-3-574-2961
   Email: jcchen@cs.nthu.edu.tw

   Anthony J. McAuley
   Telcordia Technologies
   One Telcordia Drive, RRC-1A225
   Piscataway, NJ 08854-4157
   Phone: +1-732-699-2431



J.-C. Chen, et al.        Expires  August 2006                [Page 39]


Internet Draft                   DSNP                    February 2006

   Email: mcauley@research.telcordia.com

   Venkatesh Sarangan
   Department of Computer Science
   Oklahoma State University
   219 MSCS
   Stillwater, OK 74078
   Phone: +1-405-744-5672
   Email: saranga@cs.okstate.edu

   Shinichi Baba
   PC & Network Company
   Toshiba Corporation
   Shibaura 1-1-1, Minato-Ku
   Tokyo 105-8001, Japan
   Phone: +81-3-3457-2583
   Email: shinichi1.baba@toshiba.co.jp

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   One Telcordia Drive
   Piscataway, NJ NJ 08854-4151
   Email: yohba@tari.toshiba.com


Full Copyright Statement

   "Copyright  (C)  The Internet  Society  (2004).   This document  is
   subject to  the rights, licenses and restrictions  contained in BCP
   78, and except  as set forth therein, the  authors retain all their
   rights."

   "This document and the information contained herein are provided on
   an  "AS IS"  basis  and THE  CONTRIBUTOR,  THE ORGANIZATION  HE/SHE
   REPRESENTS OR  IS SPONSORED BY  (IF ANY), THE INTERNET  SOCIETY AND
   THE  INTERNET  ENGINEERING  TASK  FORCE  DISCLAIM  ALL  WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT  NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF  THE INFORMATION HEREIN WILL NOT  INFRINGE ANY RIGHTS OR
   ANY  IMPLIED  WARRANTIES  OF   MERCHANTABILITY  OR  FITNESS  FOR  A
   PARTICULAR PURPOSE."











J.-C. Chen, et al.        Expires  August 2006                [Page 40]