Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations

From: Wanqun Bao <[email-masked]>
Date: Wed, 8 Aug 2001 10:03:29 -0700

Having "Create" w/o open can give the caller more flexibility and the
ability to store
partial attributes of a pinhole on the middlebox if the caller chooses too
(Bob gave
an example w/ SIP in his email).
I'd like to include a flag in the "Create" to indicate whether the pinhole
needs to
be opened after it's created.

Wanqun

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Wednesday, August 08, 2001 9:27 AM
To: 'Bob Penfield'; midcom mail-list
Subject: RE: [midcom] requirements - resource (p.k.a. pin-hole) operations

Bob, 
Why can't we wait till the offer/answer exchange (both for regular & Early
media) is completed, before "opening" pinholes? What is the purpose of the
interim "Create" phase? 

> -----Original Message----- 
> From: Bob Penfield [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, August 07, 2001 7:59 AM 
> To: midcom mail-list 
> Subject: [midcom] requirements - resource (p.k.a. pin-hole) operations 
> 
> 
> Hi all, 
> 
> Section 5.3 mentions 3 operations to be performed on a 
> resource (pin-hole) 
> in a middlebox. I believe that we need at least 2 more. 
> Namely "create" (or 
> "allocate") and "delete" (or "free"). 
> 
> The create operation would allocate the resource in the middlebox, but 
> packets would not be allowed through until an "open" 
> operation is performed. 
> An open operation for an unallocated resource could imply a 
> create & open 
> operation to minimize the number and size of messages between 
> the agent and 
> the middlebox 
> 
> The delete operation would be used to free the resource. 
> Close would only 
> stop packets from flowing. The resource would not be freed for a close 
> operation. The resource could subsequently re-opened by the agent. 
> A delete operation on an open resource would imply close & delete. 
> 
> A concrete example of an application that needs this 
> capability is SIP. When 
> a session is initiated in SIP with an INVITE, the session 
> description may 
> define multiple media streams that the client is willing to 
> accept. The 
> response from the server may include only a subset of these 
> media streams. 
> The resource in the middlebox needs to be allocated/reserved 
> before the 
> INVITE is forwarded to the client. However, we do not want to 
> enable packet 
> flow until the response is received from the client. 
> 
> cheers, 
> (-:bob 
> 
> Robert F. Penfield 
> Chief Software Architect 
> Acme Packet, Inc. 
> 130 New Boston Street 
> Woburn, MA 01801 
> [email-masked] 
> 
> 
> 
> _______________________________________________ 
> midcom mailing list 
> [email-masked] 
> http://www1.ietf.org/mailman/listinfo/midcom
<http://www1.ietf.org/mailman/listinfo/midcom>

---

From: John LaCour <[email-masked]>
Date: Thu, 9 Aug 2001 06:57:38 -0700

> From: Bob Penfield [mailto:[email-masked]]
>
>> From: "Sanjoy Sen" <[email-masked]>
> 
> > Bob,
> I suppose we could do that. However, one might want to make 
> sure there are
> enough resources in the middlebox to handle the flow before 
> sending the
> INVITE on the called party.

Which resources are those?  The only resource you could really
check is if you can add an additional policy/ACL/pin-hole-rule
unless you were to make an assumption about other resource
requirements that pin-holes requested via MIDCOM require
(ie. bandwidth, midbox CPU, etc.) in your implementation.

I'd much rather make the protocol allow these resource requirements
to be specified explicitly in the 'open' request though.

-John