Subject: RE: [Sip] resource reservation

From: "Pianigiani, Jacopo (Jacopo)" <[email-masked]>
Date: Tue, 7 Jan 2003 18:14:32 +0100

Jonathan & Mukul,
as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. 6 (being written almost now) specs the following QoS alternatives mechanisms to pure RSVP reservation mechanism will be available:
a) Go Diameter interface on the GGSN (traffic gating & shaping + CAC) + conditioning of the Radio Access Bearer
b) Diffserv and E/L-LSP QoS transport across RAN (but not for reservation, just for PHB treatment)
c) as you correctly stated, end to end RSVP signalling (inheritance of Signalled SIP QoS parameters)

Jac

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, December 30, 2002 5:37 PM
To: Mukul Purohit
Cc: [email-masked]
Subject: Re: [Sip] resource reservation

Mukul Purohit wrote:
> hi,
> I have a basic question after going through RFC 3312, "Integration of 
> Resource Management and SIP".
> 
> Has the actual resource reservation mechanism been specified (mandated 
> or suggested) by IETF?

There is no mandatory resource reservation scheme. The primary one 
specified so far is RSVP. nsis is another one under development. Groups 
like packetcable have specified their own QoS protocols.

> Also, has it been specified by any other body like 3GPP which has chosen 
> SIP for signaling?

Yes, 3gpp has its own mechanisms that are specific to 3gpp. As I 
understand they are built into the GPRS procedures, and reservation 
occurs only on the wireless link.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Pianigiani, Jacopo (Jacopo)" <[email-masked]>
Date: Wed, 8 Jan 2003 16:43:10 +0100

Mark,
I've written some thoughts inline along your mail. 
Thanks for your comments and regards.

Jac
 -----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, January 08, 2003 12:50 PM
To: 'Pianigiani, Jacopo (Jacopo)'; 'Jonathan Rosenberg'; Mukul Purohit
Cc: [email-masked]
Subject: RE: [Sip] resource reservation

Well, for the avoidance of confusion: 

1) GPRS terminals need to perform a GPRS-specific resource reservation mechanims to get resources on the radio network/GPRS core network. This is known as a PDP Context. 3GPP IMS uses the "Integration of Resource Management and SIP" mechanisms to delay completion of the SIP session establishment until this GPRS-specific procedure has been completed. 

2) Various mechanism can be used within the GPRS network/RAN to ensure that the traffic receives the QoS agreed in the PDP Context establishment negotiation. This could include Diffserv/MPLS but is internal to the GPRS network and not visible to the terminal     

 3) The Go interface is COPS-PR, not Diameter. It is used to authorise PDP Context establishements which are related to SIP sessions. 

Sorry for the confusion in writing. What i meant is that both Go (COPS-PR) and Diameter are used netween IMS and HSS and IMS and GGSN (Diameter is used to perform AAA function toward the HSS and this is applied whenever a PDP context with specific QoS constraint is requested from the IMS then Go implements the policy decisions. ). 

4) The terminal is free to attempt RSVP reservations, but these will have no effect on the GPRS network, unless the Layer 2 in the terminal is trapping them and firing off appropriate PDP Context requests. The RSVP may of course affect 'downstream' networks outside GPRS. 

Agreed. But if we consider a scenario where there is a mechanism to reserve QoS for SIP sessions is in place within the GPRS network, then it could be relevant to have a method to extend QoS from the edge of the GPRS network (GGSN) onward, to the other end (external bearer transport QoS and interworking of QoS parameters across distinct QoS domains)

...Mark 

> From: Pianigiani, Jacopo (Jacopo) [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: 07 January 2003 17:15 
> To: 'Jonathan Rosenberg'; Mukul Purohit 
> Cc: [email-masked] 
> Subject: RE: [Sip] resource reservation 
> 
> 
> Jonathan & Mukul, 
> as far as I know, referring to 3GPP, Rel.5 (frozen) and rel. 
> 6 (being written almost now) specs the following QoS 
> alternatives mechanisms to pure RSVP reservation mechanism 
> will be available: 
> a) Go Diameter interface on the GGSN (traffic gating & 
> shaping + CAC) + conditioning of the Radio Access Bearer 
> c) as you correctly stated, end to end RSVP signalling 
> (inheritance of Signalled SIP QoS parameters) 
> 
> Jac 
> 
> From: Jonathan Rosenberg [ mailto:[email-masked] <mailto:[email-masked]> ] 
> http://www.jdrosen.net <http://www.jdrosen.net>                       PHONE: (973) 952-5000 
> http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
> 
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip <https://www1.ietf.org/mailman/listinfo/sip>  
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip <https://www1.ietf.org/mailman/listinfo/sip>