Subject: RE: [PCN] charter, addition to scope

From: "Lee, Richard FTC" <[email-masked]>
Date: Wed, 31 Jan 2007 16:27:57 -0500

To all,
	I agree that there must be a prioritization of flows from the
aggregation devices
However, it's not just the media gateway that should speak RSVP, but the
edge proxy (or firewall "proxy") as well - it is the signaling proxy at
the edge that reserves the media path. The reservation protocol request
to the network from the VoIP proxy/gateway must reserve resources to the
destination in the network. 
The resource reservation request to the network by the edge proxy/media
gateway, must at the very minimum, meet the following conditions:
1. it needs to specify the resources required for the IP & ports
(RTP/RTCP & bandwidth)
   for example, G.711 and G.729 voice and various MPEG-4 video codecs
all have very different requirements
2. it must be mapped to the signaling request
   for SIP, it must map the SDP for media with the reservation flow -
for example something along the lines of RFC 3524
   while not the answer, the mapping of the media flows is a necessary
component
   It should be noted that the edge proxies/media gateways may have a
large number of flows (and ports for each  
   RTP/RTCP flow) from the same source IP. The request is made for each
flow or conversation
3. it must be honored by the edge network device. 
   The trust boundary must be extended to the edge proxy/media gateway
for each new flow.
   This brings up the issue of security authentication of the edge
proxy/media gateway to the network
	Does this happen in EAP, NAC, or just interoperability and
certification among vendors
   If the resources are not available, then the signaling indicates the
session is not completed. For example a SIP
   CANCEL from the edge proxy

In addition, the network device must have priority queuing enabled for
input queues from the edge device.
The media flows must not be subject to input buffers being filled prior
to classification

Thanks,
Richard Lee
Fidelity Investments
Enterprise Technology and Architecture
617-563-3278

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 31, 2007 2:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

Georgios wrote:

> > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
> > > In the first phase of PCN work to reduce the list of issues it was

> > > proposed that the WG focus on network deployment scenario where
all 
> > > nodes can be trusted and delay work on deployment scenarios where
some 
> > > of the nodes are not trusted.
> > 
> > (by Lars:) If by "nodes" you mean routers, then yes, I agree. If
"nodes" 
> > include end systems, proxies or other entities, then I don't 
> > agree we had agreement on that.
> 
> Georgios: This imposes an additional restriction on the scope 
> of the charter, which has been not discussed yet.
> >From what I remember before, during and after the PCN BOF 
> there was no objection on using
> the term edge node, that could mean something different than a edge
router.
> Please note that this is something different than a scenario covered
by 
> an application based deployment model.

It's certainly not a new restriction based on the discussion in the
BOF engendered about whether a SIP telephone (used on some of the
slides) was a good example.  I believe the BOF conclusion was that
a SIP telephone was a bad example.

IMHO, a SIP telephone causes two sets of issues wrt the proposed work:
	(1) It speaks SIP, and 
	(2) It's a telephone ;-)
The first set of issues  has already been discussed extensively - my
understanding is that the SIP scenario is currently out of scope, and
I don't care to reopen that discussion.

The "telephone" issues come up in two ways:
(2a) Small number of flows may make relatively fine-grained adjustment
	on the link to the phone impossible.  The PCN work prior to
	the BOF relied on the ability to make such adjustments.
(2b) While other sorts of phones may be trusted, a SIP phone (which
	may be software-only) is definitely not trustable in general.

I would observe that Lars Westerberg's suggestion of a Media Gateway:

> I am referring telecom scenario where MGWs are connected to an
IP-backbone.
> In these scenarios, the admission control function is a part of the
MGW
> and not the routers. The IP-backbone is provisioned by a network
> management system.

could avoid all of these issues:
(1) The media gateway could speak RSVP to the network management system,
	avoiding any need to deal with SIP here.
(2a) A media gateway is likely to handle enough flows to be consistent
	with the fine-grained adjustment assumed by the work done to
date.
(2b) One can plausibly assume/require that media gateways be trusted
	with respect to the IP network.
To the extent that one can vest "edge" functionality in a trusted
media gateway, I see no reason to exclude that scenario.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn