Subject: Use of SIP to set up MPLS paths

From: Henry Sinnreich <[email-masked]>
Date: Mon, 01 Nov 1999 05:43:03 -0600

>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)

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?

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.

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?

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: Ken Carlberg <[email-masked]>
Date: Mon, 01 Nov 1999 08:08:21 -0500

> (premium price?) private lines.

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: Henry Sinnreich <[email-masked]>
Date: Mon, 01 Nov 1999 11:56:40 -0600

Jon Crowcroft wrote:
> 3/ This is probably largely applied
> inter-domain (inter-ITAD), so its not concerned with the
> scalign at the level of numbers of switch or router hops, but at
> the level of
> numbers of domains

Sorry, I missed this point reading the draft. Inter-domain route selection
using SIP has indeed no scaling problems and is a very interesting
application, such as for selecting carriers based on various criteria. More
than real-time application criteria could probably be added and negotiated
in the SDP body of SIP messages. Such as commercial preferences, time of day
routing, etc.
Would suggest to make this more clear in the draft.

Mark Gibson writes:
>The Record-Route header therefore provides an excellent means of
determining this ER-TLV.
Agree, this has great value.

Incidentally, the SIP enhanced routing for MPLS would also have to include
some mechanisms for authentication between 1,000 of ISPs and or a clearing
house as a trust broker in the model. ISPs will implement inter-domain QoS
only if they are sure to be paid for it. This is the topic of a related
draft
http://www.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-
00.txt
possibly complementary to
http://search.ietf.org/internet-drafts/draft-gibson-manage-mpls-qos-00.txt

Henry

> From: Jon Crowcroft [mailto:[email-masked]]
> Sent: Monday, November 01, 1999 6:02 AM
> To: Henry Sinnreich
> Cc: 'SIP List'; Mark Gibson; [email-masked]; Richard H. Wilder; Lou Berger
> Subject: Re: Use of SIP to set up MPLS paths
>
>
>
> In message
> <[email-masked]>, Henry Sinnr
> eich typed:
>
> the intention for the initial applicability of the proposed extensions
>  is that
> 1/ the underlying networks are typically "carrier strength" IP -
> 2/ that "carrier strength" means that there is a good correspondance
> between flow and VC, and that aggregation is very efficient I.e. the
> vast majority of admission tests are trivial (basically borrow from
> classic telephony traffic engineering).
> 3/ This is probably largely applied
> inter-domain (inter-ITAD), so its not concerned with the
> scalign at the level of numbers of switch or router hops, but at
> the level of
> numbers of domains
>
>
> see above.....
> see the companion draft....but yes, this needs a LOT more detail
> filling in - the problem I had was that there are a LOT of options for
> this, and only some can be completely described just yet...
>
> hmmmmm....
> ...
> ...

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 01 Nov 1999 12:01:49 +0000

In message <[email-masked]>, Henry Sinnr

scalign at the level of numbers of switch or router hops, but at the level of
numbers of domains

see above.....

hmmmmm....

...

...

 cheers

   jon