PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Fri Jun 1 09:24:15 EDT 2001


Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS)
may or may not have the end-to-end significance. For example, an IP network
may implement different QOS schemes in different domains (e.g., RVSP in one
domain, DiffServ in another domain).

However, the application layer QOS is end-to-end that remains the same. For
example, an H.323 or SIP call that can traverse several IP domains where
each domain may implement its own network layer QOS schemes while the
H.323/SIP call carry the signaling messages and QOS parameters end-to-end
independent of the underlying network layer QOS mechanisms.

Yes, the application layer is end-to-end.  But does it traverse the exact
same route as RTP transport layer?  I don't think so, in that this is not
IP.  IP routes each packet individually with the right to change routes
independently for each stream, and each packet in a stream.  This is the
basis for load balancing, overload control, and link failure survivability.

With this in mind, the application layer can negotiate an end-to-end QOS
with the ends.  It cannot control the intermediate routing nodes.  A method
is needed to accomplish the end-to-end QOS control via the RTP IP stream.

Bob

--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd,      Boca Raton, Fl 33487
Tel: +1 561 923-1756            Fax: +1 561 923-1403
Email: Robert.Callaghan at ICN.Siemens.com
-----------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list