Network Working Group Jyh-Cheng Chen
INTERNET-DRAFT Anthony McAuley
Internet Engineering Task Force Venkatesh Sarangan
draft-itsumo-dsnp-00.txt Telcordia Technologies, Inc.
Date: July 2001
Expires: January 2002 Shinichi Baba
Yoshihiro Ohba
Toshiba America Research Inc.
Dynamic Service Negotiation Protocol (DSNP)
Status of this memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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
ITSUMO Group Expires January 2002 [Page 1]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 2]
Internet Draft DSNP July 2001
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
to envision fixed bandwidth requirement from all users. Users are
also hardly to project what they really need due to mobility and
the different terminals 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
ITSUMO Group Expires January 2002 [Page 3]
Internet Draft DSNP July 2001
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 the mobile user or its old service provider. The
inter-domain negotiation will 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 resource available
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.
ITSUMO Group Expires January 2002 [Page 4]
Internet Draft DSNP July 2001
Service negotiation may involve human. If so, some applications
may be needed. The user or the service provider may also
pre-define 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
A DSNP client is the one that initiates the SLS negotiation.
3.1.2 DSNP Server
A DSNP server is 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
ITSUMO Group Expires January 2002 [Page 5]
Internet Draft DSNP July 2001
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.
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
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
ITSUMO Group Expires January 2002 [Page 6]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 7]
Internet Draft DSNP July 2001
(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.
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
ITSUMO Group Expires January 2002 [Page 8]
Internet Draft DSNP July 2001
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 |
+-----+ +-----+ +-----+ +-----+
| | | |
| | | |
| | | |
__|__ __|__ __|__ __|__
/ \ / \ / \ / \
/ Radio \ / Radio \ / Radio \ / Radio \
/ Access \ / Access \ / Access \ / Access \
\ Network / \ Network / \ Network / \ Network /
\ / \ / \ / \ /
\_____/ \_____/ \_____/ \_____/
| | | |
v v v v
+----+ +----+ +----+ +----+
| MS | | MS | | MS | | MS |
+----+ +----+ +----+ +----+
ITSUMO Group Expires January 2002 [Page 9]
Internet Draft DSNP July 2001
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 /
\ / \ / \ / \ / \ / \ /
\_____/ \_____/ \_____/ \_____/ \_____/ \_____/
| | | | | |
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
ITSUMO Group Expires January 2002 [Page 10]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 11]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 12]
Internet Draft DSNP July 2001
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.
DHCP AAA
MS Server QGS Server QLNi
| | | | |
| DHCP DISCOVER | | | |
|--------------->| | | |
| DHCP OFFER | | | |
|<---------------| | | |
| DHCP REQUEST | | | |
|--------------->| | | |
| DHCP ACK | | | |
ITSUMO Group Expires January 2002 [Page 13]
Internet Draft DSNP July 2001
|<---------------| | | |
| | | | |
| | | |
| 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
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.
ITSUMO Group Expires January 2002 [Page 14]
Internet Draft DSNP July 2001
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 | |
| |------------>| |
| | AAA RESPOND | |
| |<------------| |
| | | |
| | |
| | UPDATE |
| |------------------------->|
| | ACK |
| |<-------------------------|
| | |
| SLS_NEGO_RESPONSE | |
|<----------------------------| |
| | |
ITSUMO Group Expires January 2002 [Page 15]
Internet Draft DSNP July 2001
| |
| |
| 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 | | | | |
|------------------>| | | | |
| | AAA | | | |
| | REQUEST | | | |
| |-------->| | |
| | | AAA REQUEST | |
| | |------------------>| |
| | | AAA RESPOND | |
| | |<------------------| |
| | AAA | | |
| | RESPOND | | |
| |<--------| | |
| | | | |
| | SLS_NEGO REQUEST | | |
ITSUMO Group Expires January 2002 [Page 16]
Internet Draft DSNP July 2001
| |------------------>| | |
| | 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) |
+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
ITSUMO Group Expires January 2002 [Page 17]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 18]
Internet Draft DSNP July 2001
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.
6.2.1 SLS_LIST_RESPONSE (initial):
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) |
+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 19]
Internet Draft DSNP July 2001
| 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
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) |
+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 20]
Internet Draft DSNP July 2001
| 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.
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
ITSUMO Group Expires January 2002 [Page 21]
Internet Draft DSNP July 2001
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Information about rest of the 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.
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
ITSUMO Group Expires January 2002 [Page 22]
Internet Draft DSNP July 2001
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.
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.
ITSUMO Group Expires January 2002 [Page 23]
Internet Draft DSNP July 2001
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
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 :
ITSUMO Group Expires January 2002 [Page 24]
Internet Draft DSNP July 2001
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) |
+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 25]
Internet Draft DSNP July 2001
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.
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
ITSUMO Group Expires January 2002 [Page 26]
Internet Draft DSNP July 2001
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
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) |
+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 27]
Internet Draft DSNP July 2001
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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 :
ITSUMO Group Expires January 2002 [Page 28]
Internet Draft DSNP July 2001
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 : the 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.
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) |
+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 29]
Internet Draft DSNP July 2001
| 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) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
ITSUMO Group Expires January 2002 [Page 30]
Internet Draft DSNP July 2001
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
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) |
+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 31]
Internet Draft DSNP July 2001
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
ITSUMO Group Expires January 2002 [Page 32]
Internet Draft DSNP July 2001
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 : the 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
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) |
+-+-+-+-+-+-+-+-+
| |
ITSUMO Group Expires January 2002 [Page 33]
Internet Draft DSNP July 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proto(1) | DS Byte (1) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port number (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination port number (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Information about rest of the flows (variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 34]
Internet Draft DSNP July 2001
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
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) |
+-+-+-+-+-+-+-+-+
ITSUMO Group Expires January 2002 [Page 35]
Internet Draft DSNP July 2001
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
ITSUMO Group Expires January 2002 [Page 36]
Internet Draft DSNP July 2001
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ITSUMO Group Expires January 2002 [Page 37]
Internet Draft DSNP July 2001
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
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
ITSUMO Group Expires January 2002 [Page 38]
Internet Draft DSNP July 2001
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
Telcordia Technologies
445 South Street, MCC-1J226B
Morristown, NJ 07960-6438
Phone: +1 973 829 4067
Email: jcchen@research.telcordia.com
Anthony J. McAuley
Telcordia Technologies
445 South Street, MCC-1C235B
Morristown, NJ 07960-6438
Phone: +1 973 829 4698
Email: mcauley@research.telcordia.com
Venkatesh Sarangan
Telcordia Technologies
445 South Street, MCC-1A164B
Morristown, NJ 07960-6438
Phone: +1 973 829 5811
Email: sarangan@research.telcordia.com
Shinichi Baba
Toshiba America Research Inc.
P.O. Box 136
ITSUMO Group Expires January 2002 [Page 39]
Internet Draft DSNP July 2001
Convent Station, NJ 07961-0136
Phone: +1 973 829 4759
Email: sbaba@tari.toshiba.com
Yoshihiro Ohba
Toshiba America Research Inc.
P.O. Box 136
Convent Station, NJ 07961-0136
Phone: +1 973 829 5174
Email: yohba@tari.toshiba.com
ITSUMO Group Expires January 2002 [Page 40]