Subject: New ID on RSVP APP-ID Profiles

From: "James M. Polk" <[email-masked]>
Date: Mon, 12 Jul 2010 14:00:26 -0500

TSVWG

(as an individual)

Subha and I have written a new ID based on the RSVP application-ID 
template specified within RFC 2872, to define what field values are 
appropriate to describe several real-time applications (i.e., voice 
and video).  There are 5 voice and video applications described 
within RFC 4594, and a 6th was introduced by RFC 5865.

We simply, in 8 whole pages, define what field values are necessary, 
and what values are to be in each field within the Add-ID template 
for each of these 6 real-time applications. More applications are 
always possible, but we've limited it to these 6 for now.

http://www.ietf.org/internet-drafts/draft-polk-tsvwg-rsvp-app-id-vv-profiles-00.txt

The goal of this document is to more effectively communicate what a 
reservation is for, by application type, to allow routers - and 
possibly session border controllers (SBCs) to discover what type of 
application a particular flow is, and apply appropriate treatment to 
that flow - at least in the form of marking the flow with the locally 
appropriate Diffserv codepoint (DSCP).

This document competes with the DCLASS Object defined within RFC 
2996, which only specifies a DSCP value to use, and does not give 
flexibility to each domain - on an end-to-end basis - the ability to 
configure different DSCPs within their domain (i.e., "voice will be 
'101110' only"). We see this as a limitation of what could be.

This new effort is tied to the new effort
http://www.ietf.org/internet-drafts/draft-polk-mmusic-service-class-for-sdp-00.txt 
(another whole 8 pages) within MMUSIC (in the RAI Area) to signal in 
the Session Description Protocol (SDP) (which SIP transports) which 
traffic class a session is to be.

Comments are appreciated

James & Subha