[Speermint] RE: SPEERMINT Peering Architecture - LF - OF - SF

["Michael Hammer \(mhammer\)" <[e-mail]>]

Hey, it worked for Socrates. :)

While not adverse to calling it a PF versus OF, I am not certain that
policy is all that is there, or whether to sort the other stuff out into
other bins.  I was hoping to do some grouping over the list provided by
Bob Natale in:  draft-natale-sip-voip-requirements-00.txt but haven't
gotten to that yet.

Mike


> -----Original Message-----
> From: Stastny Richard [mailto:[e-mail]] 
> Sent: Wednesday, May 24, 2006 4:37 AM
> To: Michael Hammer (mhammer); Brian Rosen; Francois D. 
> Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
> Subject: RE: SPEERMINT Peering Architecture - LF - OF - SF
> 
> Michael,
> > 
> > Let me turn this around to you.
> 
> Good policy, answering a questing with another question ;-)
> > 
> > How much policy data do you stuff into ENUM?
> 
> None, the basic idea of Infrastructure ENUM (which will be 
> used for service providers is to provide a domain name in a 
> SIP URI = a service provider ID (SPID)
> 
> > 
> > How general a database do you expect DNS to become?
> 
> Good question. The DNS is reliable, scalable and fast and it 
> is available. So IMHO if some information is needed in some 
> kind of database, DNS is the first choice (public and/or private DNS)
> 
> > 
> > Do you expect that all peers will be pointed to the same 
> entry point 
> > into the network?
> 
> I assume with network you mean the destination "network"?
> The answer is no,
>  
> > The thought was that before you blast the SF with INVITEs, 
> it might be 
> > useful to learn something about the nature of the interface 
> > expectations.
> 
> Agreed,
> 
> I would suggest to rename OF to PF (Policy detection 
> Function) IMHO the short description is ok Operation Function 
> (OF):  Purpose is to enable discovery and
> > >       exchange of policy and parameters to be used in with the SF
> > >       peering point.
> 
> the long description mentioning CALEA and Accounting is a bit 
> misleading an needs rewording. Especially the negotiation of 
> application servers is a bit early at this time.
> 
> 
> >For the most part these are bins into which things can be  organized 
> >while this group gets started.  If later it is concluded a
> bin
> > isn't needed, then it can be removed and whatever was collected
> handled
> > by some other bin.
> 
> Ok
> 
> Richard
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[e-mail]]
> > > Sent: Tuesday, May 23, 2006 5:09 PM
> > > To: Michael Hammer (mhammer); Brian Rosen; Francois D.
> > > Menard; Khan, Sohel Q [CTO]; David Meyer; [e-mail]
> > > Subject: SPEERMINT Peering Architecture - LF - OF - SF
> > >
> > > Folks,
> > >
> > > One general statement in advance:
> > > Coming from the VON Europe last week with discussions 
> about walled 
> > > garden and IMS, my overall expression is that this draft 
> in IMS in 
> > > text-mode.
> > >
> > > I have another question for clarification to this draft, 
> because I 
> > > am confused:
> > >
> > > I do not understand that the LF is discovering the OF
> > >
> > >    o  Location Function (LF):  Purpose is to enable 
> discovery of the 
> > > OF
> > >       peering point.
> > >
> > >    o  Operation Function (OF):  Purpose is to enable discovery and
> > >       exchange of policy and parameters to be used in with the SF
> > >       peering point.
> > >
> > >    o  Signaling Function (SF):  Purpose is to enable the discovery
> of
> > >       endpoints and assist in discovery and exchange of 
> parameters 
> > > to be
> > >       used with the MF peering point.
> > >
> > > I always had the naive idea (also triggered by the SPEERMINT 
> > > chartert that e.g. ENUM is a LF and discovering the SIP 
> URIs uses in 
> > > the SF
> > >
> > > How is now OF coming in between thsi, especially what is 
> listed in 
> > > the draft, especially CALEA, Accounting and Applications?
> > >
> > > "Operational data mediation:  TBD
> > >
> > >    o  CALEA implementation:  TBD
> > >
> > >    o  Accounting:  Call Detail Record's (CDR's) MAY be 
> collected to 
> > > be
> > >       utilized by the peering operators.  Based on the 
> application, 
> > > the
> > >       format should be an open standard for common consumption of
> > >       billing systems.  Operators may use this data for a 
> number of
> > >       reasons, including billing in the event the peering 
> > > relationship
> > >       becomes asymmetric (unbalanced traffic flow) or there is a 
> > > Tier 1
> > >       to Tier 2 relationship.  In order to limit the potential for
> > >       billing systems to impact the OF, a separate server 
> should be
> > >       created to maintain all records collected from a single
> > >       interconnection to any number of OF's.
> > >     An OF can also be a special function that contains 
> bi-laterally
> > >    disclosed information about the application servers 
> and databases 
> > > of
> > >    each IP service provider. An example of this function 
> is to allow 
> > > a
> > >    session to select a better suited application server from a set
> of
> > >    application servers located inside both service providers'
> > > network.  "
> > >
> > > Richard
> > >
> 

_______________________________________________
Speermint mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/speermint