[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force      Integrated Services Working Group
Internet Draft                                       Balabanian-Nortel
draft-balabanian-intserv-mpeg4-dmif-00.txt
Sept. 19, 1998
Expires: March 23, 1999


          The Use of MPEG-4/DMIF and RSVP with Integrated Services

STATUS OF THIS MEMO

   This document is an Internet-Draft. 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 made obsolete 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''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

                                 ABSTRACT


         This draft proposal explains how the ISO/IEC MPEG DMIF
                 (Delivery Multimedia Integration Framework) can be used to
                 carry MPEG-4 streams according to required media specific QoSs
                 using RSVP with Integrated Services.

         Comments are solicited and should be addressed to the working
         group's mailing list at int-serv@isi.edu and/or the authors.

1 Introduction

   MPEG-4 is a recent standard from  ISO/IEC for the coding of natural
   and synthetic audio-visual data in the form of audiovisual objects
   that are arranged into an audiovisual scene by means of a scene
   description [1][2][3][4]. This draft proposal specifies how  MPEG-4
   QoS requirements for flows are mapped into RSVP with IETF Integrated-
   Services in the instance of ISO/IEC MPEG multimedia delivery
   integration framework (DMIF). This would allow the use of IP networks
   as transports for MPEG-4 streams requiring some level of QoS.

   This draft proposal provides a solution for discussion in IETF
   IntServ and ISO/IEC MPEG technical communities in order to identify
   issues in using of MPEG-4/DMIF with RSVP and incorporate the results.


Balabanian                                                      [Page 1]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

   This would lead to the finalization of the specification on how DMIF
   can be used to carry MPEG-4 streams according to media specific QoSs
   using RSVP with Integrated Services.

   The MPEG-4 standards are versioned each beyond V1 contain
   backward compatible extensions. MPEG-4 V1 is targeted to become ISO
   International Standard on December 1998 and each subsequent version
   will be displaced approximately by a year. MPEG-4 V2 is targeted for
   February 2000. DMIF is part 6 of the MPEG-4 standard.

1.1 The DMIF Model

DMIF as an integration framework uses a uniform procedure at the DAI
interface to access the MPEG-4 content irrespective whether the content
is broadcast, stored on a local file or obtained through interaction
with a remote end-system. The model is shown in Figure 1 below.

        ! +---+ +-----------+  +-----------+  +-----------+
        ! |   | |Local DMIF |  |Remote DMIF|  |Remote App.|
+-----+ ! | D | |for Brd'cst|  |(locally   |  |(locally   |      Brd'cst
|     | ! | M | |           |  | emulated) |  | emulated) |<-----source
|Local| ! | I | +-----------+  +-----------+  +-----------+
|     | ! | F | +-----------+  +-----------+  +-----------+
|App  | ! |   | |Local DMIF |  |Remote DMIF|  |Remote App.|      File
|     | ! | F | |for Local  |  |(locally   |  |(locally   |<-----source
|     | ! | i | |  Files    |  | emulated) |  | emulated) |
|     | ! | l | +-----------+  +-----------+  +-----------+
|     | ! | t | +-----------+ ! +---+  /      ----     \
|     | ! | e | |Local DMIF | ! |Sig| |   ---     ----  |
+-----+ ! | r | |for Remote | ! |map|<->(   Network   ) |Outside the
        ! |   | |  Service  | ! |   | |   ----   -----  |scope of DMIF
        ! +---+ +-----------+ ! +---+ |      -----      |
       DAI                   DNI      |       ^         |
                                       \_____ |________/
                                              |
                                              |  +---+!+------+!+------+
                                              |  |Sig|!|Remote|!|Remote|
                                              +->|map|!| DMIF |!| App. |
                                                 |   |!|(real)|!|(real)|
                                                 +---+!+------+!+------+
                                                     DNI      DAI


Figure 1: The DMIF model covers broadcast, local file storage
          and remote service with a uniform procedure for
          application transparency







Balabanian                                                      [Page 2]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

The specific instance of interest in this draft proposal is the
interaction with a remote end-system. For this case DMIF uses internal
(informative) DMIF-Network Interface(DNI)to map the controls obtained
from the application through DAI into the various signaling appropriate
to the various networks. The default end-to-end DMIF signaling (DS)
protocol which corresponds to DNI is specified in DMIF V1 [4].

1.5.2 Establishing channels using DAI

Of interest in this draft proposal is the process by which a channel
is established. Figures 2 and 3 below show the flow of signals across
the DAI and the RSVP APIs, between a DMIF Receiver and its Sender.


a) Precondition for the procedure in Figure 2:

The MPEG-4 service has been initiated and the DMIF signaling channel
"DS_" between the originating and the target DMIF [4] has been
successfully established, after capability exchange. The receiver
application is in possession of the Elementary Stream Descriptors [1]
from which it selects the streams and obtains the media based QoS.
































Balabanian                                                      [Page 3]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

b) Channel establishment procedure

                           RSVP            RSVP
                           API             API
                   DMIF     |      IP       |     DMIF
             DAI  (Sndr) DNI|   Network     |DNI (Rcvr) DAI
              I-----------I +---------------+ I----------I
              I           I |               | I          I
DA_ChannelAdd I  3        I | DS_ChannelAdd | I 2     1  I DA_ChannelAdd
      <------------0<-----------------------------0<------((ES-Id,dir,
((ES-Id,dir)) I           I |((CAT,dir,     | I          I      qos))
              I           I |   ,qos,ES-Id))| I          I
              I           I |               | I          I
              I           I |               | I          I
   ((rsp))    I           I |               | I          I
      4 ----->I           I |               | I          I
              I Maps      I |               | I          I
              I Channels  I |               | I          I
              I into      I |               | I          I
              I specific  I |               | I          I
              I RTP flows I |               | I          I
              I           I DN_TransMuxSetup| I          I
              I    5  ---------------------------->      I
              I          ((resdcrptr,st-qos)) I          I
              I           I ((resdcrptr,rsp)) I          I
              I       <--------------------------- 6     I
              I           I |               | I          I
              I           I | Sender_TSpec  | I          I
              I     7   int1----------------->I          I
              I           I | ADSpec        | I          I
              I           I------------------>I          I
              I           I |    0-0        | I          I
              I           I |   /    \      | I          I
              I           I |  /      \     | I          I
              I           I |-0        \    | I          I
              I           I |           0-- | I          I
              I           I |  FlowSpec     | I          I
              I      8    I<----------------- int2       I
              I reduce    I |               | I          I
   readjust<--- RTP  to   I |               | I          I
   AL-PDU     I new MTU   I |               | I          I
   to new     I           I |               | I          I
   MTU        I           I |               | I          I
              I           I |               | I          I
              I           I |    ((rsp))    | I          I ((rsp))
              I       --------------------------->0-------------->
              I           I |       9       | I    10    I
              I-----------I +---------------+ I----------I

 Figure 2: Establishment of downstream channels in MPEG-4 using DAI
           Signaling(For brevity only the relevant parameters are shown)


Balabanian                                                      [Page 4]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

Step 1:
The receiver application passes a DA_ChannelAdd() requesting channels
for Elementary Streams ES-Id1 through Es-Idn. Each ES-Id is associated
with direction and QoS.

Step 2:

DMIF generates Channel Association Tag CAT corresponding to each
ES-Id and sends the requests to the sender DMIF.

Step 3:
At the sender DMIF DA_ChannelAdd is passed to the application.

Step 4
The sender application may respond positively to each ES-Id request.

Step 5:
DMIF groups the channels into RTP flows [6][12] based on priority, QoS
parameter values and traffic load requested for each channel. The
pooling policy is outside the scope of DMIF.

After the proper grouping of channels into flows. The stream-QoS
(st-qos) is derived (for either a single or aggregate flows, see
section 2.3) in order to be able to meet the QoS requirements for the
aggregate channels.

UDP/IP ports are assigned to the streams at the sender DMIF and
a UDP/IP resourceDescriptors (resdcrptr) are sent along with the
stream-QoS to the receiver.

Step 6:
the receiver DMIF completes the local UDP/IP ports for the requested
streams in the UDP/IP resourceDescriptors in response to the
DN_TransMuxSetup.

Step 7:
The UDP/IP resourceDescriptors and the stream-QoS descriptors are
used to start RSVP PATH (int1) with Sender_Tspec and ADSpec. This
is received at the receiver DMIF and RESV message (int2) is generated
with the FlowSpec. The process of int1 and int2 is repeated regularly to
maintain the soft states in the IP network.

Step 8:
After receiving the first RESV message a DA_ChannelInf() (new proposed)
message is used to update the MTU size for the AL-PDUs of the
stream [6]. This allows the conformance of the stream to the Class of
Integrated Service requested. This message is repeated at every change
of the MTU value received in int2.

Step 9:
The response to the DS_ChannelAdd is sent after receiving the first
RESV message.

Balabanian                                                      [Page 5]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

Step 10:
At the receiver DMIF the response to the DA_ChannelAdd is sent
indicate successful establishment of the channels with the
requested QoSs.

c) Decoder backchannel establishment procedure

To be added.

d) channel deleted procedures

To be added.

2 Media QoS mapping into RSVP with Integrate Services

2.1  Media Based QoS and Traffic Load

The following table provides the media QoS specified by the
content provider irrespective of the network used for
the transport of the media. No QoS values will be available
in DMIF V2 The only parameters being specified in V1 are
for characterizing the traffic load of the srtream (the
last 3 rows in the table below).

+=====================+=====================================+
|       Media         |      Meaning of the                 |
|   QoS_QualifierTag  |      ES Media QoS                   |
+=====================+=====================================+
| MAX_DELAY           |Maximum delay per AU (microseconds)  |
| (DMIF V2)           |measured over 1 sec.                 |
+---------------------+-------------------------------------+
| AVG_DELAY           |Average delay per AU allowed         |
| (DMIF V2)           |(microseconds) measured over 1 min   |
+---------------------+-------------------------------------+
| Dejitter Buffer     | Bytes reserved for the removal of   |
| (DMIF V2)           | transport jitter from the steam     |
+---------------------+-------------------------------------+
| LOSS_PROB           |Probability of loss of any single AU |
| (DMIF V2)           |(Fraction (0.00 - 1.00) over 1 sec.  |
+===========================================================+
| MAX_AU_SIZE         |Maximum size of an AU (Bytes)        |
| (DMIF V1)           |                                     |
+---------------------+-------------------------------------+
| MAX_AU_RATE         |Maximum arrival rate of an AUs       |
| (DMIF V1)           |(AU-PDU/second)                      |
+---------------------+-------------------------------------+
| AVG_RTP_SIZE        |Average size of AUs (Bytes)          |
| (DMIF V1)           |                                     |
+---------------------+-------------------------------------+




Balabanian                                                      [Page 6]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

2.2  Other media stream qualifiers

In addition to the traffic load in DMIF V1 the stream priority
is specified:

Priority: Indicates a 32 level value for the importance of the
stream related to other streams in the session.

2.3 Derivation of the Media QoS for the RTP-PDU stream

The Sync Layer in MPEG-4 fragments the Access Units into
SL-PDUs and adds synchronization information [1].

The AL-PDUs in turn can be mapped to RTP-PDUs as follows [6]:
           RTP-PDU 1:1 SL-PDU
           RTP-PDU 1:N SL-PDU





































Balabanian                                                      [Page 7]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

2.3.1 The case RTP-PDU 1:1 SL-PDU

The table below shows the stream QoS for the case when a single ES is
mapped into the RTP PDU. Only the traffic load parameters(the last 3
rows in the table below) are specified in DMIF V1 targeted to be an
ISO/IEC International Standard in December 1998.


+=====================+=====================================+
|   RTP Stream        |      Derivation from the            |
|   QoS_QualifierTag  |    ES Media transport-QoS           |
+=====================+=====================================+
| MAX_DELAY of RTP PDU|Maximum delay per AU (microseconds)  |
| (DMIF V2)           |measured over 1 sec.                 |
+---------------------+-------------------------------------+
| AVG_DELAY of RTP PDU|Average delay per AU allowed         |
| (DMIF V2)           |(microseconds) measured over 1 min   |
+---------------------+-------------------------------------+
| Dejitter Buffer     | Adjusted for the overhead of the    |
| for the RTP stream  | RTP PDU                             |
| (DMIF V2)           |                                     |
+---------------------+-------------------------------------+
| LOSS_PROB of RTP PDU|Probability of loss of any single AU |
| (DMIF V2)           |(Fraction (0.00 - 1.00) over 1 sec.  |
+===========================================================+
| MAX_RTP_SIZE        |Maximum size of an AU (Bytes)        |
| (DMIF V1)           |Plus AL-PDU and RTP overhead         |
+---------------------+-------------------------------------+
| MAX_RTP_RATE        |Maximum arrival rate of AUs          |
| (DMIF V1)           |(RTP-PDU/second)                     |
+---------------------+-------------------------------------+
| AVG_RTP_SIZE        |Average size of AUs (Bytes)          |
| (DMIF V1)           |Plus AL-PDU and RTP overhead         |
+---------------------+-------------------------------------+



















Balabanian                                                      [Page 8]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

2.3.2 The case RTP-PDU 1:N SL-PDU

The table below shows the stream QoS for the case when multiple ES are
aggregated into the RTP PDU. Only the traffic load parameters (the last
3 rows in the table below) are specified in DMIF V1 targeted to be an
ISO/IEC International Standard in December 1998.

+=====================+=====================================+
|   RTP Stream        |      Derivation from the            |
|   QoS_QualifierTag  |         ES Media QoS                |
+=====================+=====================================+
| MAX_DELAY of RTP PDU|Least Maximum delay per AU from      |
| (DMIF V2)           |among the N AL-PDUs(microseconds)    |
|                     |measured over 1 sec.                 |
+---------------------+-------------------------------------+
| AVG_DELAY of RTP PDU|Average delay per AU allowed         |
| (DMIF V2)           |(microseconds) measured over 1 min.  |
+---------------------+-------------------------------------+
| Dejitter Buffer     | Total of dejitter buffers adjusted  |
| for the RTP stream  | for the overhead of the RTP PDU     |
| (DMIF V2)           |                                     |
+---------------------+-------------------------------------+
| LOSS_PROB of RTP PDU|Least Probability of loss of any     |
| (DMIF V2)           |single AU from the N AL-PDUs         |
|                     |(Fraction (0.00 - 1.00) over 1 sec.  |
+===========================================================+
| MAX_RTP_SIZE        |Sum of the MAX_AU_SIZEs of from      |
| (DMIF V1)           |each of the N AL-PDUs Plus AL-PDU    |
|                     |and RTP overhead                     |
+---------------------+-------------------------------------+
| MAX_RTP_RATE        |Highest MAX_AU_RATE of AUs from each |
| (DMIF V1)           |of the N AL-PDUs (RTP-PDU/second)    |
+---------------------+-------------------------------------+
| AVG_RTP_SIZE        |Sum of Average size of AUs from      |
| (DMIF V1)           |each of the N AL-PDUs  Plus          |
|                     |AL-PDU and RTP overhead (Bytes)      |
+---------------------+-------------------------------------+

Note all the MPEG-4 streams chosen for aggregation over an RTP
stream belong to the same stream priority level identified by
the Sync Layer.

2.4 Choice of Integrated Service QoS service

Each elementary Stream is assigned one of the 32 levels of stream
priority [1].

"streamPriority - indicates a relative measure for the priority
of this Elementary Stream. An Elementary Stream with a higher
streamPriority is more important than one with a lower
streamPriority. The absolute values of streamPriority are not
normatively defined."[1]

Balabanian                                                      [Page 9]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

"streamPriority: Provides the priority of the channel. Lower
values mean lower priority." [4]

These priorities relate to the streams within one MPEG-4 session.
On top of these priorities one can superimpose the network
priority classes. These relate each individual stream to other
streams on the network. It is conceivable and even logical that
some mapping algorithms may map higher stream priority values
to a higher network priority classs. This policy matter is outside the
scope of DMIF.

The integrated service classes are described below:

Best Effort (the IP network default)

   DMIF may monitor the channel's performance and request controlled-
   load service from the network only when best-effort service is not
   providing acceptable performance. This provides flexibility and
   offers cost savings in environments where levels of service above
   best-effort incur a charge.

   The DMIF layer may choose based on a policy to monitor the
   performance parameters as defined in [12] in order to take corrective
   action and notify the user of the necessity for a corrective action.

Controlled-Load Service[8]

   Tightly approximates the behavior visible to applications receiving
   best-effort service *under unloaded conditions* from the same series
   of network elements.

   The controlled-load service is best suited to those applications
   which can usefully characterize their traffic requirements, this
   includes the "continuous media" data, such as digitized audio or
   video.

   This service is not isochronous and does not provide any explicit
   information about transmission delay.  MPEG-4 with end-to-end timing
   mechanism can use it similar to the best-effort service.

Guaranteed Quality of Service[9]

   Assures level of bandwidth that, when used by a policed flow, produces
   a delay-bounded service with no queuing loss for all conforming
   datagrams.








Balabanian                                                     [Page 10]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

The choice of any one of the above classes could be made as follows:

1-  If MAX_DELAY for the RTP PDU is specified then the attempt is
    made to use a Guaranteed Quality Service.
2-  If LOSS_PROB of RTP PDU is specified then the Controlled-Load
    Service is attempted.
3-  If MAX_DELAY is not specified and LOSS_PROB is not specified
    then use the Best Effort

Only experience will dictate the best formula for mapping and could be
a differentiating factor between commercial mapping algorithm softwares.

2.5 Building the Sender_TSpec

The Sender_TSpec specifies the load which is used to ensure adequate
resources are present at network elements in case of Controlled-Load
and Guaranteed Services.

The Sender_TSpec parameters and their derivation from the RTP Media
QoS follows:

-- The token bucket has a bucket depth, b

b could be approximated as follows:
b >= T*MAX_RTP_RATE(MAX_RTP_SIZE - AVG_RTP_SIZE)

Where T is the time period.

[Author's note: How is the value of T obtained?]
[Author's note: DMIF is considering the use of T*(MAX_RTP_BITRATE-
AVG_RTP_BITRATE)/8]

-- Bucket rate, r

r could be approximated as follows:
r = MAX_RTP_RATE*AVG_RTP_SIZE

[Author's note: A better measure is required for this such as
AVG_RTP-BITRATE. This matter is under consideration in DMIF)]

-- The peak rate, p

The peak rate is the maximum rate at which the source  may inject
bursts of traffic into the network.  p MUST be greater than or equal to
the token bucket rate, r.  If the peak rate is unknown or unspecified,
then p MUST be set to infinity.

p could be approximated as follows:
p = MAX_RTP_RATE*MAX_RTP_SIZE

[Author's note: A better measure is required for this such as
MAX_RTP-BITRATE. This matter is under consideration in DMIF]

Balabanian                                                     [Page 11]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

-- The minimum policed unit, m

Document [4] does not specify MIN_AU_SIZE. If a parameter is designated
it can be used to derive the MIN_RTP_SIZE as follows:

Case of RTP-PDU 1:1 AL-PDU
MIN_RTP_SIZE = MIN_AU_SIZE       Plus AL-PDU and RTP  overhead

Case of RTP-PDU 1:N AL-PDU
MIN_RTP_SIZE = Sum of the MIN_AU_SIZEs from each of the N AL-PDUs
               Plus AL-PDU and RTP  overhead

m = MIN_RTP_SIZE IP datagram size

[Author's note: How critical is the specification of a minimum datagram
size? Will it result in discarding the datagram if a larger m is
used in calculating the violation of the rT+b bound, see 2.6.1?]

-- The maximum datagram size, M

M = MAX_RTP_SIZE IP datagram size

2.6 Forming the Receiver FlowSpec

Two cases are covered below, one for the controlled load service
and the other for the guaranteed service.

2.6.1 FLOWSPEC object when requesting Controlled-Load service

In this case the flow object contains the TSpec to which the
network shall respond in providing the QoS.

In MPEG-4/DMIF the sender makes available to a receiver a set of
Elementary Stream descriptors from which the  receiver chooses
based on its capability to decode the stream when received.

Since this is done before the PATH message is received, the Sender
TSpec in the PATH therefore already reflects the receiver's choice.
As a result the corresponding parameter values may be copied into
the FLOWSPEC except for the M  parameter which is replaced by
the PATH-MTU from the ADSpec in the PATH message.

The TSpec contains the following parameters.

-- The token bucket has a bucket depth, b

This value is kept the same as the one received in the
SENDER_TSPEC passed across the RSVP API





Balabanian                                                     [Page 12]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

-- Bucket rate, r

This value is kept the same as the one received in the
SENDER_TSPEC passed across the RSVP API

-- The peak rate, p

This parameter may always be ignored by a Controlled-Load service

-- The minimum policed unit, m

This value is kept the same as the one received in the Sender TSpec

-- The maximum datagram size, M

The maximum packet size parameter [M] should be set to the value of
the smallest path MTU, which the receiver learns from information in
arriving RSVP ADSPEC objects (from different senders in case of
incasting not presently covered in  [1]& [4]). Alternatively, if
the receiving application has built-in knowledge of the maximum packet
size in use within the RSVP session, and this value is smaller than
the smallest path MTU, [M] may be set to this value.  Note that
requesting a value of [M] larger than the service modules along the
data path can support will cause the reservation to fail.[7]

The TSpec's token bucket parameters require that traffic must obey
the rule that over all time periods, the amount of data sent does
not exceed rT+b, where r and b are the token bucket parameters and
T is the length of the time period.  For the purposes of this
accounting, links must count packets that are smaller than the
minimal policing unit m to be of size m.  Packets that arrive at
an element and cause a violation of the the rT+b bound are considered
nonconformant.

A measure that is required in MPEG-4/DMIF for the acceptance of the path
in a controlled service is a value representing LOSS_PROB. These are not
presently covered in [8]. They therefore need to be monitored [12] along
with the MAX_DELAY and the AVG_DELAY as well as the Jitter using a
mechanism such as RTCP Reports.

2.6.2 FLOWSPEC Object when Requesting Guaranteed Service

In this case the FLOWSPEC object contains the Rspec in addition to
the TSpec to which the network shall respond in providing the QoS.

In MPEG-4/DMIF the sender makes available to a receiver a set of
Elementary Stream descriptors from which the  receiver chooses
based on its capability for decoding the stream when received.

Since this is done before the PATH message is received, the Sender
TSpec in the PATH therefore already reflects the receiver's
choice. As a result the corresponding parameter values may be copied

Balabanian                                                     [Page 13]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

into the FLOWSPEC except for the M  parameter which is replaced by
the PATH-MTU from the ADSpec in the PATH message.

The TSpec contains the following parameters.

-- The token bucket has a bucket depth, b

This value is kept the same as the one received in the
SENDER_TSPEC passed across the RSVP API

-- Bucket rate, r

This value is kept the same as the one received in the
SENDER_TSPEC passed across the RSVP API

-- The peak rate, p

This parameter is used to optimize the buffer resources
in the network.

-- The minimum policed unit, m

This value is kept the same as the one received in the Sender TSpec

-- The maximum datagram size, M

The maximum packet size parameter [M] should be set to the value of
the smallest path MTU, which the receiver learns from information in
arriving RSVP ADSPEC objects (from different senders in case of
incasting not presently covered in the [1]& [4]). Alternatively, if
the receiving application has built-in knowledge of the maximum packet
size in use within the RSVP session, and this value is smaller than
the smallest path MTU, [M] may be set to this value.  Note that
requesting a value of [M] larger than the service modules along the
data path can support will cause the reservation to fail.[7]

The network is not permitted to fragment datagrams as part of
guaranteed service.  Datagrams larger than the MTU of a link are
policed as nonconformant which means that they will be policed
according to the Policing rules.

The network applies the rule that over all time periods, the amount
of data sent cannot exceed M+min[pT, rT+b-M], where r and b are the
token bucket parameters, M is the maximum datagram size, and T is the
length of the time period and p is the peak rate (note that when p is
infinite this reduces to the standard token bucket requirement).  For
the purposes of this accounting, datagrams which are smaller than the
minimum policing unit are counted to be as size m.  Datagrams which
arrive at an element and cause a violation of the the M+min[pT, rT+b-M]
bound are considered nonconformant.



Balabanian                                                     [Page 14]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

Nonconforming datagrams are treated as best-effort datagrams or dropped.
All flow controls that are normally applied to best effort datagrams are
applied to that datagram too.

Datagrams bigger than the MTU of a network element are considered
nonconformant and classified as best effort (and will then either be
fragmented or dropped according to the element's handling of best
effort traffic).

The RSpec contains the following values.

-- Rate value, R

The R value is calculated to meet the value of the AVG_DELAY of
the RTP PDU from the stream-QoS (for a single flow or aggregate of
flows) using the formula in section 2.6.2.1.

-- Slack value, S

In order to derive the Slack in the RSpec the MAX_DELAY of the
RTP PDU is used from the stream-QoS. (for a single flow or aggregate of
flows).

Guaranteed service does not control the minimal or average delay of
datagrams, merely the maximal queuing delay.  Furthermore, to
compute the maximum delay a datagram will experience, the latency of
the path MUST be determined and added to the guaranteed queuing
delay.  (However, a conservative bound of the latency can be computed
by observing the delay (Minimum path latency in the ADSpec) experienced
by any one packet).[9]

The MAX_DELAY is reduced by the latency of the path and the resulting
value is termed the required Delay Dreq.

2.6.2.1 Calculating the delays and the slack

The steps below show the end-to-end queuing derivation and
subsequently the derivation of the Slack.

The maximum end-to-end queuing delay (as characterized by Ctot and
Dtot) and bandwidth (characterized by R) provided along a path will
be stable.  That is, they will not change as long as the end-to-end
path does not change.[9]

Consider an application that is intolerant of any lost or late
datagrams.  It uses the advertised values Ctot and Dtot and the TSpec
of the flow, to compute the resulting delay bound from a service
request with rate R.

The end-to-end delay bound is
[(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and
(M+Ctot)/R+Dtot for r<=p<=R     [9]

Balabanian                                                     [Page 15]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

While sending applications are encouraged to set the peak rate parameter,
it is always acceptable to ignore the peak rate for the purposes of
computing end-to-end delays. The result is simply an overestimate of the
delay. The end-to-end delay without the peak rate is b/R+Ctot/R+Dtot.[9]

As an example [9] for the use of the slack term, consider the case where
the required end-to-end delay MAX_DELAY is larger than the maximum delay
of the fluid flow system. The latter is obtained by setting R=r in
the fluid delay formula (for stability, R>=r must be true), and is
given by

                        b/r + Ctot/r + Dtot.

In this case the slack term is

                  S = MAX_DELAY - (b/r + Ctot/r + Dtot).

If S<0 then the path is refused by the receiver. Otherwise the value
is included in the S field of the RSpec.

Also if the Minimum path latency from the Sender ADSpec is more than
AVG_DELAY the receiver shall refuse the path. However DMIF needs to
monitor the performance for AVG_DELAY and take the proper measure
when the value is larger than required by the Application.

A measure that is required in MPEG-4/DMIF for the acceptance of
the path in a controlled service is some value representing
LOSS_PROB. These are not presently covered in [8]. They therefore
need to be monitored along with the Jitter using a mechanism
such as RTCP [12].

Guaranteed service is invoked by specifying the traffic (TSpec) and
the desired service (RSpec) to the network.  A service request for
an existing flow that has a new TSpec and/or RSpec is treated as a
new invocation, in the sense that admission control is reapplied to
the flow.  Flows that reduce their TSpec and/or their RSpec (i.e.,
their new TSpec/RSpec is strictly smaller than the old TSpec/RSpec
according to the ordering rules described in [9]) are not denied
service.

2.7 Reacting to the FlowSpec in the network and at the Sender [7]

When a receiver originates a reservation request, it can also
request a confirmation message to indicate that its request was
(probably) installed in the network. In order to reduce the traffic
however the confirmation may be requested in every n RESV messages,
where the value of n is network dependent.

The RSVP processes in the network pass the FlowSpec reservation
request to admission control and policy control.  If either test
fails, the reservation is rejected and the RSVP process returns
an error message to the receiver. If both succeed, the desired

Balabanian                                                     [Page 16]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

QoS is defined by  FlowSpec passed to the sender[11].

MPEG-4/DMIF version 1 [1][4] do not use multicast. Therefore it is
assumed in this draft proposal that the value of the TSpec remains
unchanged from that sent by the receiver and no multicast or
heterogeneous source branch points are used in MPEG-4/DMIF version 1.
However this is a subject under consideration in DMIF Version 2 or
later.

In the case of MPEG-4/DMIF Version 1 [1][4], the values in the TSpec
received from the Receiver is the same as the Sender_Tspec in all
aspects except for the M value. This is set to the smallest acceptable
MTU of the data path from that sender to the session receiver. This
MTU should be used by the sending application to size its packets.

Any packets larger than this MTU may be delivered as best-effort rather
than being covered by the session's resource reservation.

The network creates an RSVP soft state  which must be periodically
refreshed by PATH and RESV messages. The state is deleted if no
matching refresh messages arrive before the expiration of a "cleanup
timeout" interval.  State may also be deleted by an explicit
"teardown" message. At the expiration of each "refresh timeout"
period and after a state change, RSVP scans its state to build and
forward PATH and RESV refresh messages to succeeding hops.

RSVP "teardown" messages remove path or reservation state
immediately.  Although it is not necessary to explicitly tear down
an old reservation, it is recommended that all end hosts send a
teardown request as soon as an application finishes[11]. There are
two types of RSVP teardown message, PathTear and ResvTear. A
PathTear travels towards the receiver and ResvTear travels toward
the sender. A teardown request may be initiated either by an
application in an end system (sender or receiver), or a network
element as the result of state timeout or service preemption.

There are two RSVP error messages, PathErr and ResvErr:

PathErr messages are very simple; they report errors in processing
Path messages and are simply sent upstream to the sender that
created the error. There are only a few possible causes of path
errors.

ResvErr (reservation error) messages report errors in
processing Resv messages, or they may report the spontaneous
disruption of a reservation, e.g., by administrative
preemption.     There are a number of ways for a syntactically valid
reservation request to fail at some node along the path.





Balabanian                                                     [Page 17]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

2.8 Open Issues

1) In DMIF [4], no primitive exists to indicate the desired MTU size
   of the AL_PDU. This is important for operation with RSVP in order
   to be conformant to the M sent back in the FlowSpec of the RESV
   message. The Sync Layer must use this information to fragment the
   AU before they are sent across the DA_Data of the DAI. the proposal
   is to include DA_ChannelInf().

2) During the lifetime of the flow it is conceivable because of changes
   in conditions within the network the MTU message gets changed. In
   this case the RESV message will indicate a new value for M. In the
   specific case if the M is lower than the present value it shall
   require that the Sync Layer be informed. For this reason an
   DA_CahnnelInf() message may be required to be added to DMIF [4].

3) The Media QoS needs to include a MIN-AU-SIZE parameter which shall
   be used to generate the MIN-RTP-SIZE parameter for the RTP stream.

   This will be used to derive m which is the minimum policed datagram
   size. However in case it is missing a policy may use a fraction of
   the AVG_RTP_SIZE to derive m.

4) Require to verify and improve on the mapping of the media based QoS
   into Integrated Service parameters including suggestions on alternate
   media based QoS parameters.


A Authors' Addresses

  Vahe Balabanian
  Nortel
  P.O.Box 3511, St. C
  Ottawa, Ontario
  Canada K1Y 4H7

  Tel: 613-763-4721
  Email: balabani@nortel.ca


B Bibliography

   [1] ISO/IEC 14496-1 FCD "MPEG-4 Systems" May 1998, obtained from
       the MPEG Home Page http://drogo.cselt.it/mpeg/

   [2] ISO/IEC 14496-2 FCD "MPEG-4 Visual" May 1998, obtained from
       the MPEG Home Page http://drogo.cselt.it/mpeg/

   [3] ISO/IEC 14496-3 FCD "MPEG-4 Audio" May 1998, obtained from
       the MPEG Home Page http://drogo.cselt.it/mpeg/



Balabanian                                                     [Page 18]


Internet Draft          MPEG-4 DMIF IntServ RSVP         Sept. 19, 1998

   [4] ISO/IEC 14496-6 CD "DMIF" May 1998, obtained from
       the MPEG Home Page http://drogo.cselt.it/mpeg/

   [5] Schulzrinne, Casner, Frederick, Jacobson "RTP: A Transport
       Protocol for Real Time Applications"  draft-ietf-avt-new-00,
       Internet Engineering Task Force, Dec. 1998.

   [6] Carsten, Balabanian, Basso, Civanlar, hoffman, Speer,
       Schulzrinne, 'RTP payload format for MPEG-4 Elementary
       Streams'  ietf-avt-rtp-mpeg4-dmdraft-ietf-avt-new-00,
       Internet Engineering Task Force, March 19987.

   [7] J. Wroclawski "The Use of RSVP with IETF Integrated
       Services" RFC 2210, September 1998

   [8] Wroclawski, J., "Specification of the Controlled Load
       Quality of Service", RFC 2211, September 1998.

   [9] Shenker, S., Partridge, C., and R Guerin, "Specification
       of Guaranteed Quality of Service", RFC 2212, September
       1998.

   [10]Shenker, S., and J. Wroclawski, "General Characterization
       Parameters for Integrated Service Network Elements", RFC 2215,
       September 1998.

   [11]Braden, B., Ed., et. al., "Resource Reservation Protocol
       (RSVP) - Version 1 Functional Specification", RFC 2205,
       September 1998.

   [12]Balabanian, " The Role of DMIF in Support of RTP MPEG-4
       Payloads", draft-balabanian-rtp-mpeg4-dmif-01, August 1998.


Internet Engineering Task Force      Integrated Services Working Group
Internet Draft                                       Balabanian-Nortel
draft-balabanian-intserv-mpeg4-dmif-00.txt
Sept. 19, 1998
Expires: March 23, 1999














        Balabanian                                                     [Page 19]