Subject: RE: Use of SIP to set up MPLS paths

From: "Mark Gibson" <[email-masked]>
Date: Mon, 1 Nov 1999 13:59:21 -0000

Henry

Thanks for your comments and support, I've added responses below:

> -----Original Message-----
> From:	Henry Sinnreich [SMTP:[email-masked]]
> Sent:	Monday, November 01, 1999 11:43 AM
> To:	'SIP List'; Gibson, Mark [HAL02:HM60:EXCH]; [email-masked]
> Cc:	Richard H. Wilder; Lou Berger
> Subject:	Use of SIP to set up MPLS paths
> 
> >This draft defines a modification of the use of the SIP protocol to
> >perform route reservation. These modifications are applied...to be
> >used to find the best path across a particular network based on QoS
> metrics.
> 
> The proposed use of the route record of SIP to chose the most appropriate
> path for real time applications is a new capability that is not available,
> to my understanding, at present using LDP and RSVP. This or a similar
> proposal was in the making, since the choice of MPLS routes for real time
> traffic is a useful feature. Though I like the draft as an excellent
> illustration of the various applications for SIP, (beyond such mundane
> tasks
> as setting up phone calls :->), two issues come to mind:
> 
> 1. Scalability
> The Label Switched Routers (LSRs) in Figure 1 in the Core Transport
> Network
> seem to require state for every QoS tunnel across the network. If that is
> what the schema implies, it may still be an acceptable schema for smaller
> networks, but the applications should be only such 'specials' as the
> provisioning of trunk groups between large network (public CO) IP
> telephony
> media gateways, high bandwidth video channels or the provisioning of
> special
> (premium price?) private lines.
> 
> Tracking individual tunnels in the core may be a debatable proposition.
> Does that mean that for 100,000s of phone calls, the LSRs have to keep
> state
> for each call? Or do I misunderstand the schema?
> How scalable and how desirable is it to keep state of every phone call in
> backbone routers?
> Would the substitution of the pipe model (tunnels) with the hose mode not
> be
> more scalable?
> It seems several advantages can be combined if the schema would be
> changed:
>  * discovering and recording a desirable route using SIP,
>  * using the hose model to keep state only at the edge,
>  * using only aggregate QoS PHB in the core,
> IMHO there may be a better scalable way to set up MPLS paths using SIP:
> Classifying aggregate behaviors and just incrementing/decrementing the
> bandwidth for a specific class of traffic from the connection managers
> (CMs)...(to discuss off line)
> 
	 
	  Our opinion is that the scalability required for this scheme is
not significantly greater than that already needed by MPLS. Schemes like
RSVP already consider the storing of a large amout of state which we believe
can be significantly reduced.

	At present we've concentrated on getting the basis of the operation
of the extensions before expanding its applications. The sessions being
established could, as you say, be a mixture of individual calls, high
bandwidth multimedia or trunk groups. However, the proposal stores state
only in certain, if you like well-known, routers in the backbone, each of
these being interconnected by a number of LSPs. A network of 20 LSRs may
have, perhaps, only 5 storing state. 

	I'm not entirely familiar with the hose model you propose but I see
no reason why the extensions could not be applied to fit with this model.  

> 2. More Complex Signaling for MPLS
> It appears the MPLS community considers RSVP and LDP as the preferred
> methods of signaling for setting up MPLS paths.
> See
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-04.txt
> and
> http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-06.txt
> These methods allow only to set up QoS and perform traffic engineering,
> but
> are already a quite complex set.
> MPLS versed readers may excuse any naiveties expressed here.
> Adding SIP for MPLS signaling may be felt as too much complexity, but
> that's
> for the MPLS WG to decide.
> 
> Is SIP as proposed here orthogonal/compatible with RSVP and LDP for MPLS
> QoS
> setup?
> Would you comment?
> 
	  
	It was originally intended for the SIP extensions to inter-operate
with CR-LDP. This protocol features an Explicite Route (ER) TLV that permits
the specification of the set of routers to be used in an LSP. Moreover, we
see this as the means for defining the paths between the 'well-known' LSRs
(those with AM/CMs) by use of the Traffic Parameters TLV to achieve a
constrained set of paths. Then using CR-LDP end to end (AM to AM) for each
SIP session. See
	http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-03.txt

	The Record-Route header therefore provides an excellent means of
determining this ER-TLV.

	We have not directly considered its applicability to vanilla LDP or
RSVP.

> The possible intellectual property claim by Nortel may be a problem that
> both the SIP and MPLS WGs may want to consider. Would changing the schema,
> as suggested here or in any other way, remove the intellectual property
> claim?
> Please comment.
> 
> 
	I'm not an expert on IPR, however we have included what is a general
statement of our intent to provide access to all patented materials using
fair and resonable terms. I don't belive this is significantly different to
some other draft submissions. I would have to check the specific claims of
the application to see how changing the schema affected the patent.

> It is intriguing that besides upsetting other VoIP models (H.323), SIP may
> also influence various other IETF WGs (IMPP is a  notable example).
> 
> The companion draft, <draft-gibson-manage-mpls-qos>
> http://search.ietf.org/internet-drafts/draft-gibson-manage-mpls-qos-00.txt
> deals with scalability, but to my understanding would also require to keep
> track of every single phone call in the core.
> Is this correct?
> 
	See above.

> Thanks, Henry
> 
> Henry Sinnreich
> MCI WorldCom
> 400 International Parkway
> Richardson, Texas 75081, USA
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Mark Gibson
> > Sent: Wednesday, October 27, 1999 7:48 AM
> > To: 'SIP List'
> > Subject: New Internet Draft
> >
> >
> > The following Internet Draft has been submitted :
> >
> > Title:		Use of SIP for the Reservation of QoS
> > guaranteed Paths
> > Authors:	M. Gibson, J. Crowcroft
> > Filename:	draft-gibson-sip-qos-resv-00.txt
> > Date:		October 1999
> >
> > And subject to its approval, we will present it at the 46th IETF.
> >
> > Abstract:	This draft defines a modification of the use of the SIP
> > protocol to
> >    	perform route reservation. These modifications are applied to two of
> >    	the existing SIP Methods: INVITE and REGISTER. The modifications
> >    	allow the INVITE method to be used to find the best path across a
> >    	particular network based on QoS metrics. The route choice is able to
> >    	be restricted at the network edge. The proposed modifications also
> >    	allow the REGISTER method to be used as a means of disseminating
> >    	information necessary to determine these QoS metrics. This
> >    	information can be used to route INVITEs away from known areas of
> >    	congestion.
> >
> > Available from:
> > http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt
> >
> >
> >
>

---

From: John Hopkins <[email-masked]>
Date: Mon, 1 Nov 1999 15:11:35 -0000

Hi Mark,

Per-call triggering of path establishment, e.g in support of a voip application seems interesting, but delay in establishing the paths might be an issue. I would regard "ISUP/SIP" at the top of the figure 1 as a application-layer 'call control' protocol in that regard, and the protocol to be used in the 'core management' layer of fig 1. as connection control. In this respect I would think MPLS LDP or RSVP would be a appropriate 'connection control' protocol rather than the combination of SIP and COPS shown? 

One issue is if MPLS CR-LDP or RSVP (or SIP/COPS) can meet the path delay establishment requirements of the application. e.g. MPLS has been designed with a traffic engineering application in mind, that may have less stringent performance requirements than an intended SIP application such as VoIP path establishment can tolerate (i.e. where there is a 1-to-1 relationship between calls and LSP establishment).

If LSPs are being estabished to support trunks (i.e. a many-to-1 trunkiing relationship between sip 'calls' and LSP 'connections') then delays in establishing paths would be less critcial, as the lsp setup would become an adminstrative procedure applied to engineer traffic for later use by the sip application, rather than a 'per-call' operation.

Has anyone got figures or experience of LSP establishment delays (e.g. using CR-LDP) to shed light on its suitablity for per-call or trunking usage e.g. in ip-telephony applications?

John Hopkins

N.B. .
If 'per-call' path establishment is felt to be a valid application (i'm not sure myself due to the large amount of state implied) and a MPLS control plane such as CR-LDP is felt to be too heavy/slow, then there may be a case for introducing a lightweight resource reservation for isup/sip/h323 applications between the session control and core tramsport layers as shown in your diagram. My feeling though is that SIP+COPS might be a bit heavyweight.

> From:	Ken Carlberg [SMTP:[email-masked]]
> Sent:	01 November 1999 13:08
> To:	Henry Sinnreich
> Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject:	Re: Use of SIP to set up MPLS paths 
> 
> 
> > 1. Scalability
> > The Label Switched Routers (LSRs) in Figure 1 in the Core Transport Network
> > provisioning of trunk groups between large network (public CO) IP telephony
> > media gateways, high bandwidth video channels or the provisioning of special
> I agree that there will probably be a need to expand the model that Mark 
> initially introduces to support a more aggregated set of calls.  and as 
> you allude to, for specialty 'mom-&-pop' and leaf ISPs, the granularity 
> that Mark describes is probably fine.  
> 
> however, beyond the 'special' of trunking groups for large carriers, i 
> believe there will still be a need to support a limited set of individual 
> call traffic that corresponds to HPC signaling.  so perhaps, its not a 
> question of changing Mark's model as oppposed to expanding it.
> 
> -ken
>

---

From: "Mark Gibson" <[email-masked]>
Date: Tue, 2 Nov 1999 11:21:02 -0000

Hi John, thanks for the feedback. 

I think I'd like to say upfront that what I'd aimed to do with the draft and
obviously not succeeded in doing was to emphasise that the sessions
established across the network I've described do not have to be single
calls. They could be leased line equivalents, trunk groups...

I agree that the setup time may be significant on a per call basis, however
this scheme is not alone in that respect. The area of LSP setup latency is
an area of ongoing interest.

It is my belief, however, that the SIP extensions neatly combine the best
parts of both RSVP and CR-LDP insomuch that it allows for the reservation of
'sessions' (be they calls or groups of calls), allows for the route to be
defined at the edge of the network and allows the network itself to make
intelligent path choices based on the contents of the request message.

Mark

> From:	John Hopkins [SMTP:[email-masked]]
> Sent:	Monday, November 01, 1999 3:12 PM
> To:	Gibson, Mark [HAL02:HM60:EXCH]
> Cc:	[email-masked]; [email-masked]; Henry Sinnreich; 'Ken
> Carlberg'; [email-masked]; [email-masked]
> Subject:	RE: Use of SIP to set up MPLS paths
> 
> Hi Mark,
> 
> Per-call triggering of path establishment, e.g in support of a voip
> application seems interesting, but delay in establishing the paths might
> be an issue. I would regard "ISUP/SIP" at the top of the figure 1 as a
> application-layer 'call control' protocol in that regard, and the protocol
> to be used in the 'core management' layer of fig 1. as connection control.
> In this respect I would think MPLS LDP or RSVP would be a appropriate
> 'connection control' protocol rather than the combination of SIP and COPS
> shown? 
> 
> One issue is if MPLS CR-LDP or RSVP (or SIP/COPS) can meet the path delay
> establishment requirements of the application. e.g. MPLS has been designed
> with a traffic engineering application in mind, that may have less
> stringent performance requirements than an intended SIP application such
> as VoIP path establishment can tolerate (i.e. where there is a 1-to-1
> relationship between calls and LSP establishment).
> 
> If LSPs are being estabished to support trunks (i.e. a many-to-1 trunkiing
> relationship between sip 'calls' and LSP 'connections') then delays in
> establishing paths would be less critcial, as the lsp setup would become
> an adminstrative procedure applied to engineer traffic for later use by
> the sip application, rather than a 'per-call' operation.
> 
> Has anyone got figures or experience of LSP establishment delays (e.g.
> using CR-LDP) to shed light on its suitablity for per-call or trunking
> usage e.g. in ip-telephony applications?
> 
> John Hopkins
> 
> N.B. .
> If 'per-call' path establishment is felt to be a valid application (i'm
> not sure myself due to the large amount of state implied) and a MPLS
> control plane such as CR-LDP is felt to be too heavy/slow, then there may
> be a case for introducing a lightweight resource reservation for
> isup/sip/h323 applications between the session control and core tramsport
> layers as shown in your diagram. My feeling though is that SIP+COPS might
> be a bit heavyweight.
>