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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 1 Feb 2007 10:45:08 +0200

Maybe we should stop for a moment and consider what layer should PCN
deal with. It looks to me that we are mixing network admission control
and call admission control in this discussion. This problem is quite
complex, and there are many scenarios that need to be taken into
consideration. Sometimes flow = call, sometimes call =NOT flow and
sometimes there is a mix on the same path. In some cases media gateways
are collocated with the edge nodes in some other cases not. Even when
flow = call there are two admission control layers (network and call)
that are in dependency but not identical and separate protocols run at
transport and session. I am not sure how much of all this falls under
what PCN should do. 

Dan

> -----Original Message-----
> From: Lee, Richard FTC [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 11:28 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [PCN] charter, addition to scope
> 
> 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
> 

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 1 Feb 2007 10:43:47 +0100

Hi Dan,

your proposal seems sound to me. My impression is the discussion 
may have approached consensus on the following issues to get 
chartered initially:

- PCN is limited to a single DiffServ domain.
- PCN aware nodes must be "on path".
- PCN only standardises PCN related IP layer 
  functionalities including RSVP or NSIS signaling 
  between edge nodes.
- PCN only works on "network admission control".

If "Edge node" requires further definition to exclude things to 
close to an "end system", we should add it at appropriate places. 

"PCN related" would exclude dealing with middleboxes doing anything 
else with packets than PCN DiffServ forwarding.

Another question is, what the reaction of an ingress edge 
node should be in case of an indicated network congestion. My 
impression is, that with the initial charter we should just 
define a desired behaviour in terms of an aggregate traffic 
reduction (e.g. "stop admission new flows demanding CL 
forwarding or bandwidth increases of admitted ones" or 
"reduce CL traffic by x percent"). 

Future work items may be added when the WG is re-chartered after 
having reached first aims. It may indeed be useful to think about 
some requirements for future PCN use already now. As I didn't think 
about particular topics in detail, I don't try to summarise which 
requirements that could be by this mail.

Regards,

Ruediger

|-----Original Message-----
|From: Romascanu, Dan (Dan) [mailto:[email-masked]]
|Sent: Thursday, February 01, 2007 9:45 AM
|To: Lee, Richard FTC; [email-masked]; [email-masked]
|Cc: [email-masked]
|Subject: RE: [PCN] charter, addition to scope
|
|
|Maybe we should stop for a moment and consider what layer should PCN
|deal with. It looks to me that we are mixing network admission control
|and call admission control in this discussion. This problem is quite
|complex, and there are many scenarios that need to be taken into
|consideration. Sometimes flow = call, sometimes call =NOT flow and
|sometimes there is a mix on the same path. In some cases media gateways
|are collocated with the edge nodes in some other cases not. Even when
|flow = call there are two admission control layers (network and call)
|that are in dependency but not identical and separate protocols run at
|transport and session. I am not sure how much of all this falls under
|what PCN should do. 
|
|Dan
|
|
|
|
| 
| 
|
|> -----Original Message-----
|> From: Lee, Richard FTC [mailto:[email-masked]] 
|> Sent: Wednesday, January 31, 2007 11:28 PM
|> To: [email-masked]; [email-masked]
|> Cc: [email-masked]
|> Subject: RE: [PCN] charter, addition to scope
|> 
|> 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
|> 
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Lars Westberg <[email-masked]>
Date: Thu, 01 Feb 2007 12:58:02 +0100

commenst inline.

> transport and session. I am not sure how much of all this falls under

I agree that this is one of the problem with the discussion. We are 
mixing definitions.
I tried to explain more about the scenario I though of.

The scenario I am thinking of is that the MGW has some way to reduce the 
traffic volume (blocking calls, rejecting call,  rate-adaptation....) . 
How MGW is the interacting with the call-control signalling and all 
application interaction should be out-of-scope.

I would like to avoid the limitations imposed by the assumption of an 
edge-router such as diff.serv.edge and interactions with 
RSVP-state-managment.

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Thu, 1 Feb 2007 13:16:23 -0500

What I think you mean, and the admission control that PCN deals with,
better not be described as "network admission control" since that term
often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control)
refers to admission based on the identity of the sender, which is
probably out of scope for PCN. The flow admission control in PCN scope
is based on considerations related to network status i.e.
pre-congestion. 

The PCN flow admission control can be part of a call admission control
solution, if it interacts with other mechanisms such as for example with
Int-Serv outside the PCN domain and/or with SIP QoS pre-conditions. Such
interactions, or assumptions about them, may not be in the scope of PCN.

Benny 

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: Thursday, February 01, 2007 4:44 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]
Subject: RE: [PCN] charter, addition to scope

Hi Dan,

your proposal seems sound to me. My impression is the discussion may
have approached consensus on the following issues to get chartered
initially:

If "Edge node" requires further definition to exclude things to close to
an "end system", we should add it at appropriate places. 

"PCN related" would exclude dealing with middleboxes doing anything else
with packets than PCN DiffServ forwarding.

Another question is, what the reaction of an ingress edge node should be
in case of an indicated network congestion. My impression is, that with
the initial charter we should just define a desired behaviour in terms
of an aggregate traffic reduction (e.g. "stop admission new flows
demanding CL forwarding or bandwidth increases of admitted ones" or
"reduce CL traffic by x percent"). 

Future work items may be added when the WG is re-chartered after having
reached first aims. It may indeed be useful to think about some
requirements for future PCN use already now. As I didn't think about
particular topics in detail, I don't try to summarise which requirements
that could be by this mail.

Regards,

Ruediger

|are collocated with the edge nodes in some other cases not. Even when 
|flow = call there are two admission control layers (network and call) 
|that are in dependency but not identical and separate protocols run at 
|transport and session. I am not sure how much of all this falls under 
|what PCN should do.
|
|Dan
|
|
|
|
| 
| 
|
|> -----Original Message-----
|> From: Lee, Richard FTC [mailto:[email-masked]]
|> Sent: Wednesday, January 31, 2007 11:28 PM
|> To: [email-masked]; [email-masked]
|> Cc: [email-masked]
|> Subject: RE: [PCN] charter, addition to scope
|> 
|> 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

|> (1) The media gateway could speak RSVP to the network management 
|> system,

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 2 Feb 2007 08:52:25 +0100

Hi Benny,

thanks for the advice. I think the charter should still highlight the 
differentiation of the PCN functionalities from "call admission 
control". To suggest something: "Edge-to-edge admission control" 
with a definition of "edge-to-edge" in the architecture document.

Regards,

Ruediger

|-----Original Message-----
|From: Rodrig, Benny (Benny) [mailto:[email-masked]]
|Sent: Thursday, February 01, 2007 7:16 PM
|To: Geib, Rudiger; Romascanu, Dan (Dan)
|Cc: [email-masked]
|Subject: RE: [PCN] charter, addition to scope
|
|
|What I think you mean, and the admission control that PCN deals with,
|better not be described as "network admission control" since that term
|often (e.g. see http://en.wikipedia.org/wiki/Network_Admission_Control)
|refers to admission based on the identity of the sender, which is
|probably out of scope for PCN. The flow admission control in PCN scope
|is based on considerations related to network status i.e.
|pre-congestion. 
|
|The PCN flow admission control can be part of a call admission control
|solution, if it interacts with other mechanisms such as for 
|example with
|Int-Serv outside the PCN domain and/or with SIP QoS 
|pre-conditions. Such
|interactions, or assumptions about them, may not be in the 
|scope of PCN.
|
|
|Benny 
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:[email-masked]] 
|Sent: Thursday, February 01, 2007 4:44 AM
|To: Romascanu, Dan (Dan)
|Cc: [email-masked]
|Subject: RE: [PCN] charter, addition to scope
|
|Hi Dan,
|
|your proposal seems sound to me. My impression is the discussion may
|have approached consensus on the following issues to get chartered
|initially:
|
|- PCN is limited to a single DiffServ domain.
|- PCN aware nodes must be "on path".
|- PCN only standardises PCN related IP layer
|  functionalities including RSVP or NSIS signaling
|  between edge nodes.
|- PCN only works on "network admission control".
|
|If "Edge node" requires further definition to exclude things 
|to close to
|an "end system", we should add it at appropriate places. 
|
|"PCN related" would exclude dealing with middleboxes doing 
|anything else
|with packets than PCN DiffServ forwarding.
|
|Another question is, what the reaction of an ingress edge node 
|should be
|in case of an indicated network congestion. My impression is, that with
|the initial charter we should just define a desired behaviour in terms
|of an aggregate traffic reduction (e.g. "stop admission new flows
|demanding CL forwarding or bandwidth increases of admitted ones" or
|"reduce CL traffic by x percent"). 
|
|Future work items may be added when the WG is re-chartered after having
|reached first aims. It may indeed be useful to think about some
|requirements for future PCN use already now. As I didn't think about
|particular topics in detail, I don't try to summarise which 
|requirements
|that could be by this mail.
|
|Regards,
|
|Ruediger
|
|
||-----Original Message-----
||From: Romascanu, Dan (Dan) [mailto:[email-masked]]
||Sent: Thursday, February 01, 2007 9:45 AM
||To: Lee, Richard FTC; [email-masked]; [email-masked]
||Cc: [email-masked]
||Subject: RE: [PCN] charter, addition to scope
||
||
||Maybe we should stop for a moment and consider what layer should PCN 
||deal with. It looks to me that we are mixing network 
|admission control 
||and call admission control in this discussion. This problem is quite 
||complex, and there are many scenarios that need to be taken into 
||consideration. Sometimes flow = call, sometimes call =NOT flow and 
||sometimes there is a mix on the same path. In some cases 
|media gateways
|
||are collocated with the edge nodes in some other cases not. Even when 
||flow = call there are two admission control layers (network and call) 
||that are in dependency but not identical and separate 
|protocols run at 
||transport and session. I am not sure how much of all this falls under 
||what PCN should do.
||
||Dan
||
||
||
||
|| 
|| 
||
||> -----Original Message-----
||> From: Lee, Richard FTC [mailto:[email-masked]]
||> Sent: Wednesday, January 31, 2007 11:28 PM
||> To: [email-masked]; [email-masked]
||> Cc: [email-masked]
||> Subject: RE: [PCN] charter, addition to scope
||> 
||> 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
||> 
||
||_______________________________________________
||PCN mailing list
[email-masked]
||https://www1.ietf.org/mailman/listinfo/pcn
||
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: Lars Eggert <[email-masked]>
Date: Fri, 2 Feb 2007 10:19:44 +0200

> is based on considerations related to network status i.e.

The charter does not contain the phrase "network admission control."  
It specifically talks about flow admission.

Lars

---

From: Michael Menth <[email-masked]>
Date: Fri, 02 Feb 2007 12:16:20 +0100

Hi,

I've got a comment on the term "Network Admission Control" (NAC).

Wikipedia http://en.wikipedia.org/wiki/Network_Admission_Control only 
knows NAC in the context of restricting access to the network based on 
identity or security posture (it's essentially a Cisco product). 
However, most important is the aspect that access is denied to a whole 
network, subnetwork, domain, region, etc. NAC is in contrast to AC 
algorithms deciding whether a new flow can be admitted to be transported 
over a single link which has been studied in depth in the 1990s in the 
context of ATM systems. Three years ago, I have reviewed and studied 
different approaches for NAC (based on resource management issues) in my 
PhD thesis:
http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04.pdf
The terms connection or flow admission control are less specific than 
NAC as they do not tell the scope of the AC.

Best regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Tina TSOU <[email-masked]>
Date: Fri, 02 Feb 2007 15:24:34 +0100

Hi,
How about Resource Admission Control or Network Resource Admission Control?
I don't have strong opinion on that, just some terms popped up in my mind:)

B. R.
Tina

----- Original Message ----- 
From: "Michael Menth" <[email-masked]>
To: "Rodrig, Benny (Benny)" <[email-masked]>
Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
Sent: Friday, February 02, 2007 12:16 PM
Subject: [PCN] "Network Admission Control" (NAC)

> identity or security posture (it's essentially a Cisco product). However, 
> most important is the aspect that access is denied to a whole network, 
> subnetwork, domain, region, etc. NAC is in contrast to AC algorithms 
> deciding whether a new flow can be admitted to be transported over a 
> single link which has been studied in depth in the 1990s in the context of 
> ATM systems. Three years ago, I have reviewed and studied different 
> approaches for NAC (based on resource management issues) in my PhD thesis:
> The terms connection or flow admission control are less specific than NAC 
> as they do not tell the scope of the AC.
>
> Best regards,
>
>    Michael
>
>> From: Geib, Ruediger [mailto:[email-masked]] Sent: Thursday, 
>> February 01, 2007 4:44 AM
>> To: Romascanu, Dan (Dan)
>> Cc: [email-masked]
>> | | |
>> |> |> 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)
>> |> all have very different requirements 2. it must be mapped to the |> 
>> signaling request
>> |>    while not the answer, the mapping of the media flows is a |> 
>> necessary component
>> |>    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
>> |> |> In addition, the network device must have priority queuing enabled 
>> |> The media flows must not be subject to input buffers being filled |> 
>> prior to classification
>> |> |> Thanks,
>> |> Richard Lee
>> |> Fidelity Investments
>> |> |> |> -----Original Message-----
>> |> |> |> Georgios wrote:
>> |> |> > > On 2007-1-30, at 2:39, ext Jozef Babiarz wrote:
>> |> |> > > > proposed that the WG focus on network deployment scenario 
>> where
>> |> all
>> |> > > |> > > (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.
>> |> |> It's certainly not a new restriction based on the discussion in the 
>> |> |> IMHO, a SIP telephone causes two sets of issues wrt the
>> |proposed work:
>> |> (1) It speaks SIP, and |> (2) It's a telephone ;-)
>> |> |> The "telephone" issues come up in two ways:
>> |> |> 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.
>> |> > 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,
>> |> To the extent that one can vest "edge" functionality in a trusted |> 
>> |> |> Thanks,
>> |> |> _______________________________________________
>> |> PCN mailing list
>> |> [email-masked]
>> |> |> _______________________________________________
>> |> PCN mailing list
>> |> [email-masked]
>> |> |

---

From: "Moore, Sean \(Sean\)" <[email-masked]>
Date: Fri, 2 Feb 2007 09:59:00 -0500

Probably shouldn't use "Resource Admission Control" as this term (RAC)
is used in IMS and it is not the same as what we are discussing
- Sean 

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: Friday, February 02, 2007 9:25 AM
To: Rodrig, Benny (Benny); [email-masked]
Cc: [email-masked]; Geib, Ruediger
Subject: Re: [PCN] "Network Admission Control" (NAC)

Hi,
How about Resource Admission Control or Network Resource Admission
Control?
I don't have strong opinion on that, just some terms popped up in my
mind:)

B. R.
Tina

----- Original Message -----
From: "Michael Menth" <[email-masked]>
To: "Rodrig, Benny (Benny)" <[email-masked]>
Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
Sent: Friday, February 02, 2007 12:16 PM
Subject: [PCN] "Network Admission Control" (NAC)

> identity or security posture (it's essentially a Cisco product).
However, 

> approaches for NAC (based on resource management issues) in my PhD
thesis:
http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04.p
df
> The terms connection or flow admission control are less specific than
NAC 
>> often (e.g. see
http://en.wikipedia.org/wiki/Network_Admission_Control)
>> "PCN related" would exclude dealing with middleboxes doing anything
else
>> Future work items may be added when the WG is re-chartered after
having

|> 
|> 
|> 
|> 
>> |>    If the resources are not available, then the signaling
indicates |> 
|> 

>> |> slides) was a good example.  I believe the BOF conclusion was that
a 
|> 
|> 
|>

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Fri, 2 Feb 2007 11:09:16 -0500

I think the 'flow admission' wording in the charter is fine and we don't
need to choose a more precise term. The charter text explaining that
this flow admission happens at the domain boundary in reaction to
pre-congestion info from within the domain, etc. seems to describe it
sufficiently.

Benny

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Friday, February 02, 2007 9:25 AM
To: Rodrig, Benny (Benny); [email-masked]
Cc: [email-masked]; Geib, Ruediger
Subject: Re: [PCN] "Network Admission Control" (NAC)

Hi,

B. R.
Tina

----- Original Message -----
From: "Michael Menth" <[email-masked]>
To: "Rodrig, Benny (Benny)" <[email-masked]>
Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
Sent: Friday, February 02, 2007 12:16 PM
Subject: [PCN] "Network Admission Control" (NAC)

> algorithms deciding whether a new flow can be admitted to be 
> transported over a single link which has been studied in depth in the 
> 1990s in the context of ATM systems. Three years ago, I have reviewed 
> and studied different approaches for NAC (based on resource management
issues) in my PhD thesis:
> http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04
> .pdf The terms connection or flow admission control are less specific 
> than NAC as they do not tell the scope of the AC.
>
> Best regards,
>
>    Michael
>

>> better not be described as "network admission control" since that 
>> term often (e.g. see 
>> probably out of scope for PCN. The flow admission control in PCN 
>> scope is based on considerations related to network status i.e.
>> pre-congestion.
>> The PCN flow admission control can be part of a call admission 
>> control solution, if it interacts with other mechanisms such as for 
>> example with Int-Serv outside the PCN domain and/or with SIP QoS 
>> pre-conditions. Such interactions, or assumptions about them, may not
be in the scope of PCN.
>> From: Geib, Ruediger [mailto:[email-masked]] Sent: 
>> Thursday, February 01, 2007 4:44 AM
>> To: Romascanu, Dan (Dan)
>> Cc: [email-masked]
>> If "Edge node" requires further definition to exclude things to close

>> to an "end system", we should add it at appropriate places.
>> Another question is, what the reaction of an ingress edge node should

>> be in case of an indicated network congestion. My impression is, that

>> with the initial charter we should just define a desired behaviour in

>> terms of an aggregate traffic reduction (e.g. "stop admission new 
>> flows demanding CL forwarding or bandwidth increases of admitted 
>> ones" or "reduce CL traffic by x percent").

>> |deal with. It looks to me that we are mixing network admission 
>> |control and call admission control in this discussion. This problem 
>> |is quite complex, and there are many scenarios that need to be taken

>> |into consideration. Sometimes flow = call, sometimes call =NOT flow 
>> |and sometimes there is a mix on the same path. In some cases media 
>> |gateways
>>
>> |are collocated with the edge nodes in some other cases not. Even 
>> |when flow = call there are two admission control layers (network and

>> |call) that are in dependency but not identical and separate 
>> |protocols run at transport and session. I am not sure how much of 
>> |all this falls under what PCN should do.
>> |
>> |Dan
>> |
>> |
>> |
>> |
>> | | |
>> |> it is the signaling proxy at the edge that reserves the media 
>> |> path. |>
>> |> |>
>> |>    for example, G.711 and G.729 voice and various MPEG-4 video 
>> |> codecs
>>
>> |> |>
>> |>    for SIP, it must map the SDP for media with the reservation 
>> |> flow -
>>
>> |>    It should be noted that the edge proxies/media gateways may 
>> |> have a
>>

>> |> |>
>> each flow or conversation 3. it must be honored by the edge network 
>> |> device.

>> |> |>
>> |> indicates |>
>> |> |> In addition, the network device must have priority queuing 
>> |> |> enabled
>> |> |>
>> |> "nodes" |> > > include end systems, proxies or other entities, 
>> |> then I
>> |> > |> > Georgios: This imposes an additional restriction on the 
>> |> > |> > scope
>> |> > the term edge node, that could mean something different than a 
>> |> > edge
>> |> router.
>> |> |> It's certainly not a new restriction based on the discussion in

>> |> |> the

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

>> |> > |>
>> |> |>
>> |> (2b) One can plausibly assume/require that media gateways be 
>> |> trusted with respect to the IP network.
>> |> |>
>> |> David L. Black, Senior Technologist EMC Corporation, 176 South 
>> |> St., Hopkinton, MA  01748
> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, 
> room B206

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 5 Feb 2007 09:01:01 +0100

I'm not sure whether "flow admission" is the correct description. 
Wouldn' or couldn't that mean that PCN includes work on the per 
flow admission control functionality. PCN then is chartered to 
work on RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it 
with Network- or Aggregate- or Per Domain Behaviour- Admission 
Control, then the chartered PCN work could be limited to provide 
an interface (API?) to the per flow signaling protocol. Isn't 
the latter sufficient for the initial charter?

Regards,

Ruediger

|-----Original Message-----
|From: Rodrig, Benny (Benny) [mailto:[email-masked]]
|Sent: Friday, February 02, 2007 5:09 PM
|To: Moore, Sean (Sean); Tina TSOU; [email-masked];
|Geib, Rudiger
|Cc: [email-masked]
|Subject: RE: [PCN] "Network Admission Control" (NAC)
|
|
|I think the 'flow admission' wording in the charter is fine 
|and we don't
|need to choose a more precise term. The charter text explaining that
|this flow admission happens at the domain boundary in reaction to
|pre-congestion info from within the domain, etc. seems to describe it
|sufficiently.
|
|Benny
|
|-----Original Message-----
|From: Moore, Sean (Sean) 
|Sent: Friday, February 02, 2007 9:59 AM
|To: Tina TSOU; Rodrig, Benny (Benny); [email-masked]
|Cc: [email-masked]; Geib, Ruediger
|Subject: RE: [PCN] "Network Admission Control" (NAC)
|
|Probably shouldn't use "Resource Admission Control" as this term (RAC)
|is used in IMS and it is not the same as what we are discussing
|- Sean 
|
|-----Original Message-----
|From: Tina TSOU [mailto:[email-masked]]
|Sent: Friday, February 02, 2007 9:25 AM
|To: Rodrig, Benny (Benny); [email-masked]
|Cc: [email-masked]; Geib, Ruediger
|Subject: Re: [PCN] "Network Admission Control" (NAC)
|
|Hi,
|How about Resource Admission Control or Network Resource Admission
|Control?
|I don't have strong opinion on that, just some terms popped up in my
|mind:)
|
|B. R.
|Tina
|
|----- Original Message -----
|From: "Michael Menth" <[email-masked]>
|To: "Rodrig, Benny (Benny)" <[email-masked]>
|Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
|Sent: Friday, February 02, 2007 12:16 PM
|Subject: [PCN] "Network Admission Control" (NAC)
|
|
|> Hi,
|>
|> I've got a comment on the term "Network Admission Control" (NAC).
|>
|> Wikipedia 
|http://en.wikipedia.org/wiki/Network_Admission_Control only 
|> knows NAC in the context of restricting access to the 
|network based on
|
|> identity or security posture (it's essentially a Cisco product). 
|> However, most important is the aspect that access is denied 
|to a whole
|
|> network, subnetwork, domain, region, etc. NAC is in contrast to AC 
|> algorithms deciding whether a new flow can be admitted to be 
|> transported over a single link which has been studied in 
|depth in the 
|> 1990s in the context of ATM systems. Three years ago, I have 
|reviewed 
|> and studied different approaches for NAC (based on resource 
|management
|issues) in my PhD thesis:
|> 
|http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04
|> .pdf The terms connection or flow admission control are less 
|specific 
|> than NAC as they do not tell the scope of the AC.
|>
|> Best regards,
|>
|>    Michael
|>
|> Rodrig, Benny (Benny) wrote:
|>> What I think you mean, and the admission control that PCN 
|deals with,
|
|>> better not be described as "network admission control" since that 
|>> term often (e.g. see 
|>> http://en.wikipedia.org/wiki/Network_Admission_Control)
|>> refers to admission based on the identity of the sender, which is 
|>> probably out of scope for PCN. The flow admission control in PCN 
|>> scope is based on considerations related to network status i.e.
|>> pre-congestion.
|>> The PCN flow admission control can be part of a call admission 
|>> control solution, if it interacts with other mechanisms such as for 
|>> example with Int-Serv outside the PCN domain and/or with SIP QoS 
|>> pre-conditions. Such interactions, or assumptions about 
|them, may not
|be in the scope of PCN.
|>>
|>>
|>> Benny
|>> -----Original Message-----
|>> From: Geib, Ruediger [mailto:[email-masked]] Sent: 
|>> Thursday, February 01, 2007 4:44 AM
|>> To: Romascanu, Dan (Dan)
|>> Cc: [email-masked]
|>> Subject: RE: [PCN] charter, addition to scope
|>>
|>> Hi Dan,
|>>
|>> your proposal seems sound to me. My impression is the 
|discussion may 
|>> have approached consensus on the following issues to get chartered
|>> initially:
|>>
|>> - PCN is limited to a single DiffServ domain.
|>> - PCN aware nodes must be "on path".
|>> - PCN only standardises PCN related IP layer
|>>   functionalities including RSVP or NSIS signaling
|>>   between edge nodes.
|>> - PCN only works on "network admission control".
|>>
|>> If "Edge node" requires further definition to exclude 
|things to close
|
|>> to an "end system", we should add it at appropriate places.
|>> "PCN related" would exclude dealing with middleboxes doing anything 
|>> else with packets than PCN DiffServ forwarding.
|>>
|>> Another question is, what the reaction of an ingress edge 
|node should
|
|>> be in case of an indicated network congestion. My 
|impression is, that
|
|>> with the initial charter we should just define a desired 
|behaviour in
|
|>> terms of an aggregate traffic reduction (e.g. "stop admission new 
|>> flows demanding CL forwarding or bandwidth increases of admitted 
|>> ones" or "reduce CL traffic by x percent").
|>> Future work items may be added when the WG is re-chartered after 
|>> having reached first aims. It may indeed be useful to think about 
|>> some requirements for future PCN use already now. As I didn't think 
|>> about particular topics in detail, I don't try to summarise which 
|>> requirements that could be by this mail.
|>>
|>> Regards,
|>>
|>> Ruediger
|>>
|>>
|>> |-----Original Message-----
|>> |From: Romascanu, Dan (Dan) [mailto:[email-masked]]
|>> |Sent: Thursday, February 01, 2007 9:45 AM
|>> |To: Lee, Richard FTC; [email-masked]; [email-masked]
|>> |Cc: [email-masked]
|>> |Subject: RE: [PCN] charter, addition to scope
|>> |
|>> |
|>> |Maybe we should stop for a moment and consider what layer 
|should PCN
|
|>> |deal with. It looks to me that we are mixing network admission 
|>> |control and call admission control in this discussion. 
|This problem 
|>> |is quite complex, and there are many scenarios that need 
|to be taken
|
|>> |into consideration. Sometimes flow = call, sometimes call 
|=NOT flow 
|>> |and sometimes there is a mix on the same path. In some cases media 
|>> |gateways
|>>
|>> |are collocated with the edge nodes in some other cases not. Even 
|>> |when flow = call there are two admission control layers 
|(network and
|
|>> |call) that are in dependency but not identical and separate 
|>> |protocols run at transport and session. I am not sure how much of 
|>> |all this falls under what PCN should do.
|>> |
|>> |Dan
|>> |
|>> |
|>> |
|>> |
|>> | | |
|>> |> -----Original Message-----
|>> |> From: Lee, Richard FTC [mailto:[email-masked]]
|>> |> Sent: Wednesday, January 31, 2007 11:28 PM
|>> |> To: [email-masked]; [email-masked]
|>> |> Cc: [email-masked]
|>> |> Subject: RE: [PCN] charter, addition to scope
|>> |> |> 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
|>> |> |
|>> |_______________________________________________
|>> |PCN mailing list
|>> [email-masked]
|>> |https://www1.ietf.org/mailman/listinfo/pcn
|>> |
|>>
|>> _______________________________________________
|>> PCN mailing list
|>> [email-masked]
|>> https://www1.ietf.org/mailman/listinfo/pcn
|>>
|>>
|>> _______________________________________________
|>> PCN mailing list
|>> [email-masked]
|>> https://www1.ietf.org/mailman/listinfo/pcn
|>>
|>
|> --
|> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
|> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
|Germany, 
|> room B206
|> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 
|> mailto:[email-masked]
|> http://www3.informatik.uni-wuerzburg.de/research/ngn
|>
|>
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|
|
|

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Mon, 5 Feb 2007 13:33:29 -0500

Ruediger,

To me the charter doesn't seem to imply the expansion of scope that
you're concerned about. Unlike many other terms "flow admission" doesn't
seem to have misleading connotations. But I could be ok with "network
flow admission". 

If it is important that the charter be more explicit about this point,
then perhaps a sentence should be added with some explicit description
e.g. that the flow admission behavior at the boundary includes policing
and/or interaction with per-flow mechanisms that are out of scope of
PCN. 

Benny

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: Monday, February 05, 2007 3:01 AM
To: Rodrig, Benny (Benny)
Cc: [email-masked]
Subject: RE: [PCN] "Network Admission Control" (NAC)

I'm not sure whether "flow admission" is the correct description. 
Wouldn' or couldn't that mean that PCN includes work on the per flow
admission control functionality. PCN then is chartered to work on
RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with Network- or
Aggregate- or Per Domain Behaviour- Admission Control, then the
chartered PCN work could be limited to provide an interface (API?) to
the per flow signaling protocol. Isn't the latter sufficient for the
initial charter?

Regards,

Ruediger

|I think the 'flow admission' wording in the charter is fine and we 
|don't need to choose a more precise term. The charter text explaining 
|that this flow admission happens at the domain boundary in reaction to 
|>> |> > there was no objection on using the term edge node, that could 
|>> |> > mean something different than a edge

---

From: Michael Menth <[email-masked]>
Date: Mon, 05 Feb 2007 20:36:57 +0100

Hi,

the word NAC itself means that access is possibly denied to a network 
which can be due to security or resource reasons. NAC in the security 
context has become a quite popular expression as it is the name of a 
Cisco product. The name NAC sounds good (to me) as it is very catchy and 
easy to understand also for non-experts. I don't see a large problem 
when the term NAC exists in different contexts. If people need to 
distinguish both approaches, security-related NAC and resource-related 
NAC can be used. However, people working in both areas might see this 
differently.

As the new version of the PCN charter talks about domains, domain 
admission control (DAC) would be a natural substitute for NAC. DAC has 
no misleading connotations, but it doesn't sound nice (to me). Better 
sounds maybe per-domain AC (PDAC) and concisely states what it is. In 
analogy to routing, intradomain admission control is another option, but 
it also implies the existence of interdomain admission control. I'm not 
sure whether we want this right now.
 
If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN 
charter, we can leave this issue open until we have a clearer opinion.

    Michael

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 6 Feb 2007 09:18:12 +0100

Benny,

I prefer Michaels proposal, NAC or DAC is allright with me if we 
provide a definition for our terminology. The same would hold 
if "flow admission" is used, which I feel to be to close to 
"per flow".

A side note on the abbreviation NAC: it is also described as 
Network Access Control by Wikipedia. I've checked that because 
within my company what is described by Wiki as Network 
"Admission Control" is called Network Access Control.

Regards,

Ruediger

|-----Original Message-----
|From: Michael Menth [mailto:[email-masked]]
|Sent: Monday, February 05, 2007 8:37 PM
|To: Rodrig, Benny (Benny)
|Cc: Geib, Rüdiger; [email-masked]
|Subject: Re: [PCN] "Network Admission Control" (NAC)
|
|
|Hi,
|
|the word NAC itself means that access is possibly denied to a network 
|which can be due to security or resource reasons. NAC in the security 
|context has become a quite popular expression as it is the name of a 
|Cisco product. The name NAC sounds good (to me) as it is very catchy and 
|easy to understand also for non-experts. I don't see a large problem 
|when the term NAC exists in different contexts. If people need to 
|distinguish both approaches, security-related NAC and resource-related 
|NAC can be used. However, people working in both areas might see this 
|differently.
|
|As the new version of the PCN charter talks about domains, domain 
|admission control (DAC) would be a natural substitute for NAC. DAC has 
|no misleading connotations, but it doesn't sound nice (to me). Better 
|sounds maybe per-domain AC (PDAC) and concisely states what it is. In 
|analogy to routing, intradomain admission control is another option, but 
|it also implies the existence of interdomain admission control. I'm not 
|sure whether we want this right now.
| 
|If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN 
|charter, we can leave this issue open until we have a clearer opinion.
|
|    Michael
|
|Rodrig, Benny (Benny) wrote:
|> Ruediger,
|>
|> To me the charter doesn't seem to imply the expansion of scope that
|> you're concerned about. Unlike many other terms "flow admission" doesn't
|> seem to have misleading connotations. But I could be ok with "network
|> flow admission". 
|>
|> If it is important that the charter be more explicit about this point,
|> then perhaps a sentence should be added with some explicit description
|> e.g. that the flow admission behavior at the boundary includes policing
|> and/or interaction with per-flow mechanisms that are out of scope of
|> PCN. 
|>
|> Benny
|>  
|>
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[email-masked]] 
|> Sent: Monday, February 05, 2007 3:01 AM
|> To: Rodrig, Benny (Benny)
|> Cc: [email-masked]
|> Subject: RE: [PCN] "Network Admission Control" (NAC)
|>
|> I'm not sure whether "flow admission" is the correct description. 
|> Wouldn' or couldn't that mean that PCN includes work on the per flow
|> admission control functionality. PCN then is chartered to work on
|> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with 
|Network- or
|> Aggregate- or Per Domain Behaviour- Admission Control, then the
|> chartered PCN work could be limited to provide an interface (API?) to
|> the per flow signaling protocol. Isn't the latter sufficient for the
|> initial charter?
|>
|> Regards,
|>
|> Ruediger
|>
|> |-----Original Message-----
|> |From: Rodrig, Benny (Benny) [mailto:[email-masked]]
|> |Sent: Friday, February 02, 2007 5:09 PM
|> |To: Moore, Sean (Sean); Tina TSOU; 
[email-masked];
|> |Geib, Rudiger
|> |Cc: [email-masked]
|> |Subject: RE: [PCN] "Network Admission Control" (NAC)
|> |
|> |
|> |I think the 'flow admission' wording in the charter is fine and we 
|> |don't need to choose a more precise term. The charter text 
|explaining 
|> |that this flow admission happens at the domain boundary in 
|reaction to 
|> |pre-congestion info from within the domain, etc. seems to 
|describe it 
|> |sufficiently.
|> |
|> |Benny
|> |
|> |-----Original Message-----
|> |From: Moore, Sean (Sean)
|> |Sent: Friday, February 02, 2007 9:59 AM
|> |To: Tina TSOU; Rodrig, Benny (Benny); 
[email-masked]
|> |Cc: [email-masked]; Geib, Ruediger
|> |Subject: RE: [PCN] "Network Admission Control" (NAC)
|> |
|> |Probably shouldn't use "Resource Admission Control" as this 
|term (RAC) 
|> |is used in IMS and it is not the same as what we are discussing
|> |- Sean
|> |
|> |-----Original Message-----
|> |From: Tina TSOU [mailto:[email-masked]]
|> |Sent: Friday, February 02, 2007 9:25 AM
|> |To: Rodrig, Benny (Benny); [email-masked]
|> |Cc: [email-masked]; Geib, Ruediger
|> |Subject: Re: [PCN] "Network Admission Control" (NAC)
|> |
|> |Hi,
|> |How about Resource Admission Control or Network Resource Admission 
|> |Control?
|> |I don't have strong opinion on that, just some terms popped up in my
|> |mind:)
|> |
|> |B. R.
|> |Tina
|> |
|> |----- Original Message -----
|> |From: "Michael Menth" <[email-masked]>
|> |To: "Rodrig, Benny (Benny)" <[email-masked]>
|> |Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
|> |Sent: Friday, February 02, 2007 12:16 PM
|> |Subject: [PCN] "Network Admission Control" (NAC)
|> |
|> |
|> |> Hi,
|> |>
|> |> I've got a comment on the term "Network Admission Control" (NAC).
|> |>
|> |> Wikipedia
|> |http://en.wikipedia.org/wiki/Network_Admission_Control only
|> |> knows NAC in the context of restricting access to the
|> |network based on
|> |
|> |> identity or security posture (it's essentially a Cisco product). 
|> |> However, most important is the aspect that access is denied
|> |to a whole
|> |
|> |> network, subnetwork, domain, region, etc. NAC is in 
|contrast to AC 
|> |> algorithms deciding whether a new flow can be admitted to be 
|> |> transported over a single link which has been studied in
|> |depth in the
|> |> 1990s in the context of ATM systems. Three years ago, I have
|> |reviewed
|> |> and studied different approaches for NAC (based on resource
|> |management
|> |issues) in my PhD thesis:
|> |> 
|> 
||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pdf/Menth04
|> |> .pdf The terms connection or flow admission control are less
|> |specific
|> |> than NAC as they do not tell the scope of the AC.
|> |>
|> |> Best regards,
|> |>
|> |>    Michael
|> |>
|> |> Rodrig, Benny (Benny) wrote:
|> |>> What I think you mean, and the admission control that PCN
|> |deals with,
|> |
|> |>> better not be described as "network admission control" 
|since that 
|> |>> term often (e.g. see
|> |>> http://en.wikipedia.org/wiki/Network_Admission_Control)
|> |>> refers to admission based on the identity of the sender, 
|which is 
|> |>> probably out of scope for PCN. The flow admission control in PCN 
|> |>> scope is based on considerations related to network status i.e.
|> |>> pre-congestion.
|> |>> The PCN flow admission control can be part of a call admission 
|> |>> control solution, if it interacts with other mechanisms 
|such as for 
|> |>> example with Int-Serv outside the PCN domain and/or with SIP QoS 
|> |>> pre-conditions. Such interactions, or assumptions about
|> |them, may not
|> |be in the scope of PCN.
|> |>>
|> |>>
|> |>> Benny
|> |>> -----Original Message-----
|> |>> From: Geib, Ruediger [mailto:[email-masked]] Sent: 
|> |>> Thursday, February 01, 2007 4:44 AM
|> |>> To: Romascanu, Dan (Dan)
|> |>> Cc: [email-masked]
|> |>> Subject: RE: [PCN] charter, addition to scope
|> |>>
|> |>> Hi Dan,
|> |>>
|> |>> your proposal seems sound to me. My impression is the
|> |discussion may
|> |>> have approached consensus on the following issues to get 
|chartered
|> |>> initially:
|> |>>
|> |>> - PCN is limited to a single DiffServ domain.
|> |>> - PCN aware nodes must be "on path".
|> |>> - PCN only standardises PCN related IP layer
|> |>>   functionalities including RSVP or NSIS signaling
|> |>>   between edge nodes.
|> |>> - PCN only works on "network admission control".
|> |>>
|> |>> If "Edge node" requires further definition to exclude
|> |things to close
|> |
|> |>> to an "end system", we should add it at appropriate places.
|> |>> "PCN related" would exclude dealing with middleboxes 
|doing anything 
|> |>> else with packets than PCN DiffServ forwarding.
|> |>>
|> |>> Another question is, what the reaction of an ingress edge
|> |node should
|> |
|> |>> be in case of an indicated network congestion. My
|> |impression is, that
|> |
|> |>> with the initial charter we should just define a desired
|> |behaviour in
|> |
|> |>> terms of an aggregate traffic reduction (e.g. "stop 
|admission new 
|> |>> flows demanding CL forwarding or bandwidth increases of admitted 
|> |>> ones" or "reduce CL traffic by x percent").
|> |>> Future work items may be added when the WG is re-chartered after 
|> |>> having reached first aims. It may indeed be useful to 
|think about 
|> |>> some requirements for future PCN use already now. As I 
|didn't think 
|> |>> about particular topics in detail, I don't try to 
|summarise which 
|> |>> requirements that could be by this mail.
|> |>>
|> |>> Regards,
|> |>>
|> |>> Ruediger
|> |>>
|> |>>
|> |>> |-----Original Message-----
|> |>> |From: Romascanu, Dan (Dan) [mailto:[email-masked]]
|> |>> |Sent: Thursday, February 01, 2007 9:45 AM
|> |>> |To: Lee, Richard FTC; [email-masked]; 
[email-masked]
|> |>> |Cc: [email-masked]
|> |>> |Subject: RE: [PCN] charter, addition to scope
|> |>> |
|> |>> |
|> |>> |Maybe we should stop for a moment and consider what layer
|> |should PCN
|> |
|> |>> |deal with. It looks to me that we are mixing network admission 
|> |>> |control and call admission control in this discussion.
|> |This problem
|> |>> |is quite complex, and there are many scenarios that need
|> |to be taken
|> |
|> |>> |into consideration. Sometimes flow = call, sometimes call
|> |=NOT flow
|> |>> |and sometimes there is a mix on the same path. In some 
|cases media 
|> |>> |gateways
|> |>>
|> |>> |are collocated with the edge nodes in some other cases 
|not. Even 
|> |>> |when flow = call there are two admission control layers
|> |(network and
|> |
|> |>> |call) that are in dependency but not identical and separate 
|> |>> |protocols run at transport and session. I am not sure 
|how much of 
|> |>> |all this falls under what PCN should do.
|> |>> |
|> |>> |Dan
|> |>> |
|> |>> |
|> |>> |
|> |>> |
|> |>> | | |
|> |>> |> -----Original Message-----
|> |>> |> From: Lee, Richard FTC [mailto:[email-masked]]
|> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM
|> |>> |> To: [email-masked]; [email-masked]
|> |>> |> Cc: [email-masked]
|> |>> |> Subject: RE: [PCN] charter, addition to scope
|> |>> |> |> 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
|> |>> |> |
|> |>> |_______________________________________________
|> |>> |PCN mailing list
|> |>> [email-masked]
|> |>> |https://www1.ietf.org/mailman/listinfo/pcn
|> |>> |
|> |>>
|> |>> _______________________________________________
|> |>> PCN mailing list
|> |>> [email-masked]
|> |>> https://www1.ietf.org/mailman/listinfo/pcn
|> |>>
|> |>>
|> |>> _______________________________________________
|> |>> PCN mailing list
|> |>> [email-masked]
|> |>> https://www1.ietf.org/mailman/listinfo/pcn
|> |>>
|> |>
|> |> --
|> |> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
|> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,
|> |Germany,
|> |> room B206
|> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 
|> |> mailto:[email-masked]
|> |> http://www3.informatik.uni-wuerzburg.de/research/ngn
|> |>
|> |>
|> |> _______________________________________________
|> |> PCN mailing list
|> |> [email-masked]
|> |> https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> |
|> |_______________________________________________
|> |PCN mailing list
|> [email-masked]
|> |https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> |
|> |
|>
|>
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|>   
|
|-- 
|Dr. Michael Menth, Assistant Professor
|University of Wuerzburg, Institute of Computer Science
|Am Hubland, D-97074 Wuerzburg, Germany, room B206
|phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
|mailto:[email-masked]
|http://www3.informatik.uni-wuerzburg.de/research/ngn
|
|

---

From: Tina TSOU <[email-masked]>
Date: Tue, 06 Feb 2007 16:32:12 +0800

Hi Ruediger,
Do we also consider Network Access Control in PCN?

B. R.
Tina
----- Original Message ----- 
From: "Geib, Ruediger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 06, 2007 4:18 PM
Subject: RE: [PCN] "Network Admission Control" (NAC)

Benny,

Regards,

Ruediger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 6 Feb 2007 10:23:56 +0100

Hi Tina,

|Do we also consider Network Access Control in PCN?

No, that's out of scope.

Regards, Ruediger

|
|B. R.
|Tina
|----- Original Message ----- 
|From: "Geib, Ruediger" <[email-masked]>
|To: <[email-masked]>
|Cc: <[email-masked]>
|Sent: Tuesday, February 06, 2007 4:18 PM
|Subject: RE: [PCN] "Network Admission Control" (NAC)
|
|
|Benny,
|
|I prefer Michaels proposal, NAC or DAC is allright with me if we
|provide a definition for our terminology. The same would hold
|if "flow admission" is used, which I feel to be to close to
|"per flow".
|
|A side note on the abbreviation NAC: it is also described as
|Network Access Control by Wikipedia. I've checked that because
|within my company what is described by Wiki as Network
|"Admission Control" is called Network Access Control.
|
|Regards,
|
|Ruediger
|
||-----Original Message-----
||From: Michael Menth [mailto:[email-masked]]
||Sent: Monday, February 05, 2007 8:37 PM
||To: Rodrig, Benny (Benny)
||Cc: Geib, Rüdiger; [email-masked]
||Subject: Re: [PCN] "Network Admission Control" (NAC)
||
||
||Hi,
||
||the word NAC itself means that access is possibly denied to a network
||which can be due to security or resource reasons. NAC in the security
||context has become a quite popular expression as it is the name of a
||Cisco product. The name NAC sounds good (to me) as it is very 
|catchy and
||easy to understand also for non-experts. I don't see a large problem
||when the term NAC exists in different contexts. If people need to
||distinguish both approaches, security-related NAC and resource-related
||NAC can be used. However, people working in both areas might see this
||differently.
||
||As the new version of the PCN charter talks about domains, domain
||admission control (DAC) would be a natural substitute for NAC. DAC has
||no misleading connotations, but it doesn't sound nice (to me). Better
||sounds maybe per-domain AC (PDAC) and concisely states what it is. In
||analogy to routing, intradomain admission control is another 
|option, but
||it also implies the existence of interdomain admission 
|control. I'm not
||sure whether we want this right now.
||
||If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN
||charter, we can leave this issue open until we have a clearer opinion.
||
||    Michael
||
||Rodrig, Benny (Benny) wrote:
||> Ruediger,
||>
||> To me the charter doesn't seem to imply the expansion of scope that
||> you're concerned about. Unlike many other terms "flow 
|admission" doesn't
||> seem to have misleading connotations. But I could be ok 
|with "network
||> flow admission".
||>
||> If it is important that the charter be more explicit about 
|this point,
||> then perhaps a sentence should be added with some explicit 
|description
||> e.g. that the flow admission behavior at the boundary 
|includes policing
||> and/or interaction with per-flow mechanisms that are out of scope of
||> PCN.
||>
||> Benny
||>
||>
||> -----Original Message-----
||> From: Geib, Ruediger [mailto:[email-masked]]
||> Sent: Monday, February 05, 2007 3:01 AM
||> To: Rodrig, Benny (Benny)
||> Cc: [email-masked]
||> Subject: RE: [PCN] "Network Admission Control" (NAC)
||>
||> I'm not sure whether "flow admission" is the correct description.
||> Wouldn' or couldn't that mean that PCN includes work on the per flow
||> admission control functionality. PCN then is chartered to work on
||> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with
||Network- or
||> Aggregate- or Per Domain Behaviour- Admission Control, then the
||> chartered PCN work could be limited to provide an interface 
|(API?) to
||> the per flow signaling protocol. Isn't the latter sufficient for the
||> initial charter?
||>
||> Regards,
||>
||> Ruediger
||>
||> |-----Original Message-----
||> |From: Rodrig, Benny (Benny) [mailto:[email-masked]]
||> |Sent: Friday, February 02, 2007 5:09 PM
||> |To: Moore, Sean (Sean); Tina TSOU;
[email-masked];
||> |Geib, Rudiger
||> |Cc: [email-masked]
||> |Subject: RE: [PCN] "Network Admission Control" (NAC)
||> |
||> |
||> |I think the 'flow admission' wording in the charter is fine and we
||> |don't need to choose a more precise term. The charter text
||explaining
||> |that this flow admission happens at the domain boundary in
||reaction to
||> |pre-congestion info from within the domain, etc. seems to
||describe it
||> |sufficiently.
||> |
||> |Benny
||> |
||> |-----Original Message-----
||> |From: Moore, Sean (Sean)
||> |Sent: Friday, February 02, 2007 9:59 AM
||> |To: Tina TSOU; Rodrig, Benny (Benny);
[email-masked]
||> |Cc: [email-masked]; Geib, Ruediger
||> |Subject: RE: [PCN] "Network Admission Control" (NAC)
||> |
||> |Probably shouldn't use "Resource Admission Control" as this
||term (RAC)
||> |is used in IMS and it is not the same as what we are discussing
||> |- Sean
||> |
||> |-----Original Message-----
||> |From: Tina TSOU [mailto:[email-masked]]
||> |Sent: Friday, February 02, 2007 9:25 AM
||> |To: Rodrig, Benny (Benny); [email-masked]
||> |Cc: [email-masked]; Geib, Ruediger
||> |Subject: Re: [PCN] "Network Admission Control" (NAC)
||> |
||> |Hi,
||> |How about Resource Admission Control or Network Resource Admission
||> |Control?
||> |I don't have strong opinion on that, just some terms 
|popped up in my
||> |mind:)
||> |
||> |B. R.
||> |Tina
||> |
||> |----- Original Message -----
||> |From: "Michael Menth" <[email-masked]>
||> |To: "Rodrig, Benny (Benny)" <[email-masked]>
||> |Cc: <[email-masked]>; "Geib, Ruediger" <[email-masked]>
||> |Sent: Friday, February 02, 2007 12:16 PM
||> |Subject: [PCN] "Network Admission Control" (NAC)
||> |
||> |
||> |> Hi,
||> |>
||> |> I've got a comment on the term "Network Admission Control" (NAC).
||> |>
||> |> Wikipedia
||> |http://en.wikipedia.org/wiki/Network_Admission_Control only
||> |> knows NAC in the context of restricting access to the
||> |network based on
||> |
||> |> identity or security posture (it's essentially a Cisco product).
||> |> However, most important is the aspect that access is denied
||> |to a whole
||> |
||> |> network, subnetwork, domain, region, etc. NAC is in
||contrast to AC
||> |> algorithms deciding whether a new flow can be admitted to be
||> |> transported over a single link which has been studied in
||> |depth in the
||> |> 1990s in the context of ATM systems. Three years ago, I have
||> |reviewed
||> |> and studied different approaches for NAC (based on resource
||> |management
||> |issues) in my PhD thesis:
||> |>
||>
|||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/pd
|f/Menth04
||> |> .pdf The terms connection or flow admission control are less
||> |specific
||> |> than NAC as they do not tell the scope of the AC.
||> |>
||> |> Best regards,
||> |>
||> |>    Michael
||> |>
||> |> Rodrig, Benny (Benny) wrote:
||> |>> What I think you mean, and the admission control that PCN
||> |deals with,
||> |
||> |>> better not be described as "network admission control"
||since that
||> |>> term often (e.g. see
||> |>> http://en.wikipedia.org/wiki/Network_Admission_Control)
||> |>> refers to admission based on the identity of the sender,
||which is
||> |>> probably out of scope for PCN. The flow admission control in PCN
||> |>> scope is based on considerations related to network status i.e.
||> |>> pre-congestion.
||> |>> The PCN flow admission control can be part of a call admission
||> |>> control solution, if it interacts with other mechanisms
||such as for
||> |>> example with Int-Serv outside the PCN domain and/or with SIP QoS
||> |>> pre-conditions. Such interactions, or assumptions about
||> |them, may not
||> |be in the scope of PCN.
||> |>>
||> |>>
||> |>> Benny
||> |>> -----Original Message-----
||> |>> From: Geib, Ruediger [mailto:[email-masked]] Sent:
||> |>> Thursday, February 01, 2007 4:44 AM
||> |>> To: Romascanu, Dan (Dan)
||> |>> Cc: [email-masked]
||> |>> Subject: RE: [PCN] charter, addition to scope
||> |>>
||> |>> Hi Dan,
||> |>>
||> |>> your proposal seems sound to me. My impression is the
||> |discussion may
||> |>> have approached consensus on the following issues to get
||chartered
||> |>> initially:
||> |>>
||> |>> - PCN is limited to a single DiffServ domain.
||> |>> - PCN aware nodes must be "on path".
||> |>> - PCN only standardises PCN related IP layer
||> |>>   functionalities including RSVP or NSIS signaling
||> |>>   between edge nodes.
||> |>> - PCN only works on "network admission control".
||> |>>
||> |>> If "Edge node" requires further definition to exclude
||> |things to close
||> |
||> |>> to an "end system", we should add it at appropriate places.
||> |>> "PCN related" would exclude dealing with middleboxes
||doing anything
||> |>> else with packets than PCN DiffServ forwarding.
||> |>>
||> |>> Another question is, what the reaction of an ingress edge
||> |node should
||> |
||> |>> be in case of an indicated network congestion. My
||> |impression is, that
||> |
||> |>> with the initial charter we should just define a desired
||> |behaviour in
||> |
||> |>> terms of an aggregate traffic reduction (e.g. "stop
||admission new
||> |>> flows demanding CL forwarding or bandwidth increases of admitted
||> |>> ones" or "reduce CL traffic by x percent").
||> |>> Future work items may be added when the WG is re-chartered after
||> |>> having reached first aims. It may indeed be useful to
||think about
||> |>> some requirements for future PCN use already now. As I
||didn't think
||> |>> about particular topics in detail, I don't try to
||summarise which
||> |>> requirements that could be by this mail.
||> |>>
||> |>> Regards,
||> |>>
||> |>> Ruediger
||> |>>
||> |>>
||> |>> |-----Original Message-----
||> |>> |From: Romascanu, Dan (Dan) [mailto:[email-masked]]
||> |>> |Sent: Thursday, February 01, 2007 9:45 AM
||> |>> |To: Lee, Richard FTC; [email-masked];
[email-masked]
||> |>> |Cc: [email-masked]
||> |>> |Subject: RE: [PCN] charter, addition to scope
||> |>> |
||> |>> |
||> |>> |Maybe we should stop for a moment and consider what layer
||> |should PCN
||> |
||> |>> |deal with. It looks to me that we are mixing network admission
||> |>> |control and call admission control in this discussion.
||> |This problem
||> |>> |is quite complex, and there are many scenarios that need
||> |to be taken
||> |
||> |>> |into consideration. Sometimes flow = call, sometimes call
||> |=NOT flow
||> |>> |and sometimes there is a mix on the same path. In some
||cases media
||> |>> |gateways
||> |>>
||> |>> |are collocated with the edge nodes in some other cases
||not. Even
||> |>> |when flow = call there are two admission control layers
||> |(network and
||> |
||> |>> |call) that are in dependency but not identical and separate
||> |>> |protocols run at transport and session. I am not sure
||how much of
||> |>> |all this falls under what PCN should do.
||> |>> |
||> |>> |Dan
||> |>> |
||> |>> |
||> |>> |
||> |>> |
||> |>> | | |
||> |>> |> -----Original Message-----
||> |>> |> From: Lee, Richard FTC [mailto:[email-masked]]
||> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM
||> |>> |> To: [email-masked]; [email-masked]
||> |>> |> Cc: [email-masked]
||> |>> |> Subject: RE: [PCN] charter, addition to scope
||> |>> |> |> 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
||> |>> |> |
||> |>> |_______________________________________________
||> |>> |PCN mailing list
||> |>> [email-masked]
||> |>> |https://www1.ietf.org/mailman/listinfo/pcn
||> |>> |
||> |>>
||> |>> _______________________________________________
||> |>> PCN mailing list
||> |>> [email-masked]
||> |>> https://www1.ietf.org/mailman/listinfo/pcn
||> |>>
||> |>>
||> |>> _______________________________________________
||> |>> PCN mailing list
||> |>> [email-masked]
||> |>> https://www1.ietf.org/mailman/listinfo/pcn
||> |>>
||> |>
||> |> --
||> |> Dr. Michael Menth, Assistant Professor University of Wuerzburg,
||> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,
||> |Germany,
||> |> room B206
||> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
||> |> mailto:[email-masked]
||> |> http://www3.informatik.uni-wuerzburg.de/research/ngn
||> |>
||> |>
||> |> _______________________________________________
||> |> PCN mailing list
||> |> [email-masked]
||> |> https://www1.ietf.org/mailman/listinfo/pcn
||> |
||> |
||> |_______________________________________________
||> |PCN mailing list
||> [email-masked]
||> |https://www1.ietf.org/mailman/listinfo/pcn
||> |
||> |
||> |
||>
||>
||> _______________________________________________
||> PCN mailing list
||> [email-masked]
||> https://www1.ietf.org/mailman/listinfo/pcn
||>
||
||-- 
||Dr. Michael Menth, Assistant Professor
||University of Wuerzburg, Institute of Computer Science
||Am Hubland, D-97074 Wuerzburg, Germany, room B206
||phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
||mailto:[email-masked]
||http://www3.informatik.uni-wuerzburg.de/research/ngn
||
||
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn 
|
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Tue, 6 Feb 2007 09:41:37 -0500

Ruediger, Michael,

I don't feel strongly about this either way. Terminology debates are often significant when they indicate differences in views and assumptions about scope and focus. But my impression is that this is not the case here and that we're talking about the same thing.

Benny 

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 3:18 AM
To: Rodrig, Benny (Benny)
Cc: [email-masked]; [email-masked]
Subject: RE: [PCN] "Network Admission Control" (NAC)

Benny,

I prefer Michaels proposal, NAC or DAC is allright with me if we provide a definition for our terminology. The same would hold if "flow admission" is used, which I feel to be to close to "per flow".

A side note on the abbreviation NAC: it is also described as Network Access Control by Wikipedia. I've checked that because within my company what is described by Wiki as Network "Admission Control" is called Network Access Control.

Regards,

Ruediger

|Cisco product. The name NAC sounds good (to me) as it is very catchy 
|and easy to understand also for non-experts. I don't see a large 
|problem when the term NAC exists in different contexts. If people need 
|to distinguish both approaches, security-related NAC and 
|resource-related NAC can be used. However, people working in both areas 
|might see this differently.
|analogy to routing, intradomain admission control is another option, 
|but it also implies the existence of interdomain admission control. I'm 
|not sure whether we want this right now.
|> you're concerned about. Unlike many other terms "flow admission" 
|> doesn't seem to have misleading connotations. But I could be ok with 
|> "network flow admission".
|> If it is important that the charter be more explicit about this 
|> point, then perhaps a sentence should be added with some explicit 
|> description e.g. that the flow admission behavior at the boundary 
|> includes policing and/or interaction with per-flow mechanisms that 
|> are out of scope of PCN.
|University of Wuerzburg, Institute of Computer Science Am Hubland, 
|D-97074 Wuerzburg, Germany, room B206

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Thu, 8 Feb 2007 11:07:30 -0500

Hi,

Just a thought that there will be a number of terminology issues to address once the WG is formed. I wonder if this discussion can become part of the work on the terminology that would eventually find its way into (I think) the architecture draft?

Anna 

> Sent: Tuesday, February 06, 2007 3:32 AM
> To: [email-masked]; Geib, Ruediger
> Cc: [email-masked]

---

From: Tina TSOU <[email-masked]>
Date: Fri, 09 Feb 2007 09:31:54 +0800

Hi Anna,
I agree with you. Probably we need the terminology in the session of the 
architecture draft, or a small informal draft.

B. R.
Tina

----- Original Message ----- 
From: "Anna Charny (acharny)" <[email-masked]>
To: "Tina TSOU" <[email-masked]>; <[email-masked]>; "Geib, Ruediger" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 09, 2007 12:07 AM
Subject: RE: [PCN] "Network Admission Control" (NAC)

Hi,

Just a thought that there will be a number of terminology issues to address 
once the WG is formed. I wonder if this discussion can become part of the 
work on the terminology that would eventually find its way into (I think) 
the architecture draft?

Anna

---

From: Lars Westberg <[email-masked]>
Date: Fri, 09 Feb 2007 07:48:51 +0100

good suggestion. I agrre, the terminology for admision control is a good 
topic for the framework draft.

regards Lasse

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 9 Feb 2007 08:57:50 +0100

Hi Anna,

I'd appreciate that. I think that a fair part of the 
discussions on different threads we had on this list
was related to architecture and requirements, not 
just to the charter.

Regards,

Ruediger

|-----Original Message-----
|From: Anna Charny (acharny) [mailto:[email-masked]]
|Sent: Thursday, February 08, 2007 5:08 PM
|To: Tina TSOU; [email-masked]; Geib, Rüdiger
|Cc: [email-masked]
|Subject: RE: [PCN] "Network Admission Control" (NAC)
|
|
|Hi,
|
|Just a thought that there will be a number of terminology 
|issues to address once the WG is formed. I wonder if this 
|discussion can become part of the work on the terminology that 
|would eventually find its way into (I think) the architecture draft?
|
|Anna 
|
|
|> -----Original Message-----
|> From: Tina TSOU [mailto:[email-masked]] 
|> Sent: Tuesday, February 06, 2007 3:32 AM
|> To: [email-masked]; Geib, Ruediger
|> Cc: [email-masked]
|> Subject: Re: [PCN] "Network Admission Control" (NAC)
|> 
|> Hi Ruediger,
|> Do we also consider Network Access Control in PCN?
|> 
|> B. R.
|> Tina
|> ----- Original Message -----
|> From: "Geib, Ruediger" <[email-masked]>
|> To: <[email-masked]>
|> Cc: <[email-masked]>
|> Sent: Tuesday, February 06, 2007 4:18 PM
|> Subject: RE: [PCN] "Network Admission Control" (NAC)
|> 
|> 
|> Benny,
|> 
|> I prefer Michaels proposal, NAC or DAC is allright with me if we
|> provide a definition for our terminology. The same would hold
|> if "flow admission" is used, which I feel to be to close to
|> "per flow".
|> 
|> A side note on the abbreviation NAC: it is also described as
|> Network Access Control by Wikipedia. I've checked that because
|> within my company what is described by Wiki as Network
|> "Admission Control" is called Network Access Control.
|> 
|> Regards,
|> 
|> Ruediger
|> 
|> |-----Original Message-----
|> |From: Michael Menth [mailto:[email-masked]]
|> |Sent: Monday, February 05, 2007 8:37 PM
|> |To: Rodrig, Benny (Benny)
|> |Cc: Geib, Rüdiger; [email-masked]
|> |Subject: Re: [PCN] "Network Admission Control" (NAC)
|> |
|> |
|> |Hi,
|> |
|> |the word NAC itself means that access is possibly denied to 
|a network
|> |which can be due to security or resource reasons. NAC in 
|the security
|> |context has become a quite popular expression as it is the name of a
|> |Cisco product. The name NAC sounds good (to me) as it is 
|> very catchy and
|> |easy to understand also for non-experts. I don't see a large problem
|> |when the term NAC exists in different contexts. If people need to
|> |distinguish both approaches, security-related NAC and 
|> resource-related
|> |NAC can be used. However, people working in both areas 
|might see this
|> |differently.
|> |
|> |As the new version of the PCN charter talks about domains, domain
|> |admission control (DAC) would be a natural substitute for 
|> NAC. DAC has
|> |no misleading connotations, but it doesn't sound nice (to 
|me). Better
|> |sounds maybe per-domain AC (PDAC) and concisely states what 
|it is. In
|> |analogy to routing, intradomain admission control is another 
|> option, but
|> |it also implies the existence of interdomain admission 
|> control. I'm not
|> |sure whether we want this right now.
|> |
|> |If we don't need a term for NAC/DAC/PDAC/intradomain AC in the PCN
|> |charter, we can leave this issue open until we have a 
|> clearer opinion.
|> |
|> |    Michael
|> |
|> |Rodrig, Benny (Benny) wrote:
|> |> Ruediger,
|> |>
|> |> To me the charter doesn't seem to imply the expansion of 
|scope that
|> |> you're concerned about. Unlike many other terms "flow 
|> admission" doesn't
|> |> seem to have misleading connotations. But I could be ok 
|> with "network
|> |> flow admission".
|> |>
|> |> If it is important that the charter be more explicit about 
|> this point,
|> |> then perhaps a sentence should be added with some explicit 
|> description
|> |> e.g. that the flow admission behavior at the boundary 
|> includes policing
|> |> and/or interaction with per-flow mechanisms that are out 
|> of scope of
|> |> PCN.
|> |>
|> |> Benny
|> |>
|> |>
|> |> -----Original Message-----
|> |> From: Geib, Ruediger [mailto:[email-masked]]
|> |> Sent: Monday, February 05, 2007 3:01 AM
|> |> To: Rodrig, Benny (Benny)
|> |> Cc: [email-masked]
|> |> Subject: RE: [PCN] "Network Admission Control" (NAC)
|> |>
|> |> I'm not sure whether "flow admission" is the correct description.
|> |> Wouldn' or couldn't that mean that PCN includes work on 
|> the per flow
|> |> admission control functionality. PCN then is chartered to work on
|> |> RFC2205 RSVP, QoS NSLP, SIP and so on. If we leave it with
|> |Network- or
|> |> Aggregate- or Per Domain Behaviour- Admission Control, then the
|> |> chartered PCN work could be limited to provide an 
|> interface (API?) to
|> |> the per flow signaling protocol. Isn't the latter 
|> sufficient for the
|> |> initial charter?
|> |>
|> |> Regards,
|> |>
|> |> Ruediger
|> |>
|> |> |-----Original Message-----
|> |> |From: Rodrig, Benny (Benny) [mailto:[email-masked]]
|> |> |Sent: Friday, February 02, 2007 5:09 PM
|> |> |To: Moore, Sean (Sean); Tina TSOU;
|> [email-masked];
|> |> |Geib, Rudiger
|> |> |Cc: [email-masked]
|> |> |Subject: RE: [PCN] "Network Admission Control" (NAC)
|> |> |
|> |> |
|> |> |I think the 'flow admission' wording in the charter is 
|fine and we
|> |> |don't need to choose a more precise term. The charter text
|> |explaining
|> |> |that this flow admission happens at the domain boundary in
|> |reaction to
|> |> |pre-congestion info from within the domain, etc. seems to
|> |describe it
|> |> |sufficiently.
|> |> |
|> |> |Benny
|> |> |
|> |> |-----Original Message-----
|> |> |From: Moore, Sean (Sean)
|> |> |Sent: Friday, February 02, 2007 9:59 AM
|> |> |To: Tina TSOU; Rodrig, Benny (Benny);
|> [email-masked]
|> |> |Cc: [email-masked]; Geib, Ruediger
|> |> |Subject: RE: [PCN] "Network Admission Control" (NAC)
|> |> |
|> |> |Probably shouldn't use "Resource Admission Control" as this
|> |term (RAC)
|> |> |is used in IMS and it is not the same as what we are discussing
|> |> |- Sean
|> |> |
|> |> |-----Original Message-----
|> |> |From: Tina TSOU [mailto:[email-masked]]
|> |> |Sent: Friday, February 02, 2007 9:25 AM
|> |> |To: Rodrig, Benny (Benny); [email-masked]
|> |> |Cc: [email-masked]; Geib, Ruediger
|> |> |Subject: Re: [PCN] "Network Admission Control" (NAC)
|> |> |
|> |> |Hi,
|> |> |How about Resource Admission Control or Network Resource 
|Admission
|> |> |Control?
|> |> |I don't have strong opinion on that, just some terms 
|> popped up in my
|> |> |mind:)
|> |> |
|> |> |B. R.
|> |> |Tina
|> |> |
|> |> |----- Original Message -----
|> |> |From: "Michael Menth" <[email-masked]>
|> |> |To: "Rodrig, Benny (Benny)" <[email-masked]>
|> |> |Cc: <[email-masked]>; "Geib, Ruediger" 
|<[email-masked]>
|> |> |Sent: Friday, February 02, 2007 12:16 PM
|> |> |Subject: [PCN] "Network Admission Control" (NAC)
|> |> |
|> |> |
|> |> |> Hi,
|> |> |>
|> |> |> I've got a comment on the term "Network Admission 
|> Control" (NAC).
|> |> |>
|> |> |> Wikipedia
|> |> |http://en.wikipedia.org/wiki/Network_Admission_Control only
|> |> |> knows NAC in the context of restricting access to the
|> |> |network based on
|> |> |
|> |> |> identity or security posture (it's essentially a Cisco 
|product).
|> |> |> However, most important is the aspect that access is denied
|> |> |to a whole
|> |> |
|> |> |> network, subnetwork, domain, region, etc. NAC is in
|> |contrast to AC
|> |> |> algorithms deciding whether a new flow can be admitted to be
|> |> |> transported over a single link which has been studied in
|> |> |depth in the
|> |> |> 1990s in the context of ATM systems. Three years ago, I have
|> |> |reviewed
|> |> |> and studied different approaches for NAC (based on resource
|> |> |management
|> |> |issues) in my PhD thesis:
|> |> |>
|> |>
|> ||http://opus.bibliothek.uni-wuerzburg.de/volltexte/2004/994/p
|df/Menth04
|> |> |> .pdf The terms connection or flow admission control are less
|> |> |specific
|> |> |> than NAC as they do not tell the scope of the AC.
|> |> |>
|> |> |> Best regards,
|> |> |>
|> |> |>    Michael
|> |> |>
|> |> |> Rodrig, Benny (Benny) wrote:
|> |> |>> What I think you mean, and the admission control that PCN
|> |> |deals with,
|> |> |
|> |> |>> better not be described as "network admission control"
|> |since that
|> |> |>> term often (e.g. see
|> |> |>> http://en.wikipedia.org/wiki/Network_Admission_Control)
|> |> |>> refers to admission based on the identity of the sender,
|> |which is
|> |> |>> probably out of scope for PCN. The flow admission 
|> control in PCN
|> |> |>> scope is based on considerations related to network 
|status i.e.
|> |> |>> pre-congestion.
|> |> |>> The PCN flow admission control can be part of a call admission
|> |> |>> control solution, if it interacts with other mechanisms
|> |such as for
|> |> |>> example with Int-Serv outside the PCN domain and/or 
|> with SIP QoS
|> |> |>> pre-conditions. Such interactions, or assumptions about
|> |> |them, may not
|> |> |be in the scope of PCN.
|> |> |>>
|> |> |>>
|> |> |>> Benny
|> |> |>> -----Original Message-----
|> |> |>> From: Geib, Ruediger 
|[mailto:[email-masked]] Sent:
|> |> |>> Thursday, February 01, 2007 4:44 AM
|> |> |>> To: Romascanu, Dan (Dan)
|> |> |>> Cc: [email-masked]
|> |> |>> Subject: RE: [PCN] charter, addition to scope
|> |> |>>
|> |> |>> Hi Dan,
|> |> |>>
|> |> |>> your proposal seems sound to me. My impression is the
|> |> |discussion may
|> |> |>> have approached consensus on the following issues to get
|> |chartered
|> |> |>> initially:
|> |> |>>
|> |> |>> - PCN is limited to a single DiffServ domain.
|> |> |>> - PCN aware nodes must be "on path".
|> |> |>> - PCN only standardises PCN related IP layer
|> |> |>>   functionalities including RSVP or NSIS signaling
|> |> |>>   between edge nodes.
|> |> |>> - PCN only works on "network admission control".
|> |> |>>
|> |> |>> If "Edge node" requires further definition to exclude
|> |> |things to close
|> |> |
|> |> |>> to an "end system", we should add it at appropriate places.
|> |> |>> "PCN related" would exclude dealing with middleboxes
|> |doing anything
|> |> |>> else with packets than PCN DiffServ forwarding.
|> |> |>>
|> |> |>> Another question is, what the reaction of an ingress edge
|> |> |node should
|> |> |
|> |> |>> be in case of an indicated network congestion. My
|> |> |impression is, that
|> |> |
|> |> |>> with the initial charter we should just define a desired
|> |> |behaviour in
|> |> |
|> |> |>> terms of an aggregate traffic reduction (e.g. "stop
|> |admission new
|> |> |>> flows demanding CL forwarding or bandwidth increases 
|> of admitted
|> |> |>> ones" or "reduce CL traffic by x percent").
|> |> |>> Future work items may be added when the WG is 
|> re-chartered after
|> |> |>> having reached first aims. It may indeed be useful to
|> |think about
|> |> |>> some requirements for future PCN use already now. As I
|> |didn't think
|> |> |>> about particular topics in detail, I don't try to
|> |summarise which
|> |> |>> requirements that could be by this mail.
|> |> |>>
|> |> |>> Regards,
|> |> |>>
|> |> |>> Ruediger
|> |> |>>
|> |> |>>
|> |> |>> |-----Original Message-----
|> |> |>> |From: Romascanu, Dan (Dan) [mailto:[email-masked]]
|> |> |>> |Sent: Thursday, February 01, 2007 9:45 AM
|> |> |>> |To: Lee, Richard FTC; [email-masked];
|> [email-masked]
|> |> |>> |Cc: [email-masked]
|> |> |>> |Subject: RE: [PCN] charter, addition to scope
|> |> |>> |
|> |> |>> |
|> |> |>> |Maybe we should stop for a moment and consider what layer
|> |> |should PCN
|> |> |
|> |> |>> |deal with. It looks to me that we are mixing network 
|admission
|> |> |>> |control and call admission control in this discussion.
|> |> |This problem
|> |> |>> |is quite complex, and there are many scenarios that need
|> |> |to be taken
|> |> |
|> |> |>> |into consideration. Sometimes flow = call, sometimes call
|> |> |=NOT flow
|> |> |>> |and sometimes there is a mix on the same path. In some
|> |cases media
|> |> |>> |gateways
|> |> |>>
|> |> |>> |are collocated with the edge nodes in some other cases
|> |not. Even
|> |> |>> |when flow = call there are two admission control layers
|> |> |(network and
|> |> |
|> |> |>> |call) that are in dependency but not identical and separate
|> |> |>> |protocols run at transport and session. I am not sure
|> |how much of
|> |> |>> |all this falls under what PCN should do.
|> |> |>> |
|> |> |>> |Dan
|> |> |>> |
|> |> |>> |
|> |> |>> |
|> |> |>> |
|> |> |>> | | |
|> |> |>> |> -----Original Message-----
|> |> |>> |> From: Lee, Richard FTC [mailto:[email-masked]]
|> |> |>> |> Sent: Wednesday, January 31, 2007 11:28 PM
|> |> |>> |> To: [email-masked]; [email-masked]
|> |> |>> |> Cc: [email-masked]
|> |> |>> |> Subject: RE: [PCN] charter, addition to scope
|> |> |>> |> |> 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
|> |> |>> |> |
|> |> |>> |_______________________________________________
|> |> |>> |PCN mailing list
|> |> |>> [email-masked]
|> |> |>> |https://www1.ietf.org/mailman/listinfo/pcn
|> |> |>> |
|> |> |>>
|> |> |>> _______________________________________________
|> |> |>> PCN mailing list
|> |> |>> [email-masked]
|> |> |>> https://www1.ietf.org/mailman/listinfo/pcn
|> |> |>>
|> |> |>>
|> |> |>> _______________________________________________
|> |> |>> PCN mailing list
|> |> |>> [email-masked]
|> |> |>> https://www1.ietf.org/mailman/listinfo/pcn
|> |> |>>
|> |> |>
|> |> |> --
|> |> |> Dr. Michael Menth, Assistant Professor University of Wuerzburg,
|> |> |> Institute of Computer Science Am Hubland, D-97074 Wuerzburg,
|> |> |Germany,
|> |> |> room B206
|> |> |> phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
|> |> |> mailto:[email-masked]
|> |> |> http://www3.informatik.uni-wuerzburg.de/research/ngn
|> |> |>
|> |> |>
|> |> |> _______________________________________________
|> |> |> PCN mailing list
|> |> |> [email-masked]
|> |> |> https://www1.ietf.org/mailman/listinfo/pcn
|> |> |
|> |> |
|> |> |_______________________________________________
|> |> |PCN mailing list
|> |> [email-masked]
|> |> |https://www1.ietf.org/mailman/listinfo/pcn
|> |> |
|> |> |
|> |> |
|> |>
|> |>
|> |> _______________________________________________
|> |> PCN mailing list
|> |> [email-masked]
|> |> https://www1.ietf.org/mailman/listinfo/pcn
|> |>
|> |
|> |-- 
|> |Dr. Michael Menth, Assistant Professor
|> |University of Wuerzburg, Institute of Computer Science
|> |Am Hubland, D-97074 Wuerzburg, Germany, room B206
|> |phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
|> |mailto:[email-masked]
|> |http://www3.informatik.uni-wuerzburg.de/research/ngn
|> |
|> |
|> 
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn 
|> 
|> 
|> 
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|> 
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 9 Feb 2007 10:04:27 +0100

Hi Anna

I agree with you! This discussion should become 
part of the work on terminology.

Best Regards,
Georgios

> From: Anna Charny (acharny) [mailto:[email-masked]] 
> Sent: donderdag 8 februari 2007 17:08
> To: Tina TSOU; [email-masked]; Geib, Ruediger
> Cc: [email-masked]
> Just a thought that there will be a number of terminology 
> issues to address once the WG is formed. I wonder if this 
> discussion can become part of the work on the terminology 
> that would eventually find its way into (I think) the 
> architecture draft?
> 
> Anna 
> 
> 
> > provide a definition for our terminology. The same would 
> hold if "flow 
> > admission" is used, which I feel to be to close to "per flow".
> > 
> > A side note on the abbreviation NAC: it is also described 
> as Network 
> > Access Control by Wikipedia. I've checked that because within my 
> > company what is described by Wiki as Network "Admission Control" is 
> > called Network Access Control.
> > 
> > Regards,
> > 
> > Ruediger
> > 
> > |> |>> From: Geib, Ruediger 
> [mailto:[email-masked]] Sent:
> > |Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> > |Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> > |room B206

---

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Fri, 9 Feb 2007 09:21:09 -0500

I agree. It will be useful if these discussions, on terminology and beyond, feed into the architecture draft. 

Benny

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]] 
Sent: Friday, February 09, 2007 2:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [PCN] "Network Admission Control" (NAC)

Hi Anna,

I'd appreciate that. I think that a fair part of the discussions on different threads we had on this list was related to architecture and requirements, not just to the charter.

Regards,

Ruediger

|Just a thought that there will be a number of terminology issues to 
|address once the WG is formed. I wonder if this discussion can become 
|part of the work on the terminology that would eventually find its way 
|into (I think) the architecture draft?
|> provide a definition for our terminology. The same would hold if 
|> "flow admission" is used, which I feel to be to close to "per flow".
|> A side note on the abbreviation NAC: it is also described as Network 
|> Access Control by Wikipedia. I've checked that because within my 
|> company what is described by Wiki as Network "Admission Control" is 
|> called Network Access Control.
|> |Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
|> |Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
|> |Germany, room B206