Subject: Re: new subscriber question on OSP

From: "Matt Squire" <[email-masked]>
Date: Tue, 23 Nov 1999 10:32:59 -0500

My understanding of OSP was that it was basically an authorization and
accounting protocol - server X in domain 1 can request access to server Y
in domain 2, transmit usage records, etc.  I know its a bit more
complicated than this, but this is my one sentence summary.  OSP is,
generally, much more comparable to the work going on in AAA than here.  I
didn't think it was designed to route signalling messages.  

So I'm not aware of the route selection capabilities of OSP, in particular
whether it makes routing decisions based upon E164 numbers, what kind of
routing policies and route selection it supports, etc.  To the extent that
OSP does these things, there may indeed be overlap.  Just don't know enough
about OSP to answer definitively.  

At 03:11 PM 11/22/99 +0000, Gerry Reilly wrote:
>Hi
>
>Please forgive this newbee question.
>
>I've been reading through the TBGP, SCSP & TRIP drafts with great
>interest:-) As a relative newcomer to the VoIP area, I'm not entirely
>clear as to where the Open Settlements Protocol fits into the model, if at
>all.
>
>OSP seems to claim to be designed for inter-domain route selection as well
>as facilitating billing. 
>Would this protocol supplement TRIP, or am I missing the point?
>
>Kind Regards
>
>Gerry Reilly
>
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>

Matt Squire
Nortel Networks
innovations.lab
[email-masked]
(919)992-9048

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Stephen Thomas" <[email-masked]>
Date: Tue, 23 Nov 1999 14:23:31 -0500

Matt has some of the essentials exactly right, but OSP
can (optionally) provide call routing information as
well as authorization. A typical application would
work something like this:

  Server X in domain 1 needs to locate a peer (e.g.
    a terminating gateway to complete a call to the
    PSTN).

  Server X uses OSP (as a client) to query a third
    party for the call routing and authorization
    information.

  Server X recieves the IP address of Server Y and
    an authorization token that will grant it access
    to the peer (sort of like Kerberos).

  Server X sets up a the call to server Y (e.g. SIP
    INVITE), including the authorization token
    (e.g. as per draft-thomas-mime-osp-token-00.txt).

  After the call is released, servers X and Y use OSP
    to report usage information.

To Matt's specific questions:

  OSP Servers can route based on E.164 numbers as well as other
    identifiers (e.g. email addresses).

  Routing policies and route selection are up to the OSP
    Server.

At a high enough level, there is overlap between TRIP and
OSP. OSP does things other than call routing as well, but
where the overlap exists, I would characterize the
difference as primarily one of philosophy. TRIP is
a distributed protocol like IP routing protocols (BGP,
and also RIP, OSPF, ...). OSP is a hierarchical protocol
like directory service protocols (DNS, LDAP, ...)

Stephen

----- Original Message -----
From: "Matt Squire" <[email-masked]>
To: "Gerry Reilly" <[email-masked]>;
<[email-masked]>
Sent: 23 November 1999 10:32 AM
Subject: Re: new subscriber question on OSP

|
| My understanding of OSP was that it was basically an authorization and
| accounting protocol - server X in domain 1 can request access to server Y
| in domain 2, transmit usage records, etc.  I know its a bit more
| complicated than this, but this is my one sentence summary.  OSP is,
| generally, much more comparable to the work going on in AAA than here.  I
| didn't think it was designed to route signalling messages.
|
| So I'm not aware of the route selection capabilities of OSP, in particular
| whether it makes routing decisions based upon E164 numbers, what kind of
| routing policies and route selection it supports, etc.  To the extent that
| OSP does these things, there may indeed be overlap.  Just don't know
enough
| about OSP to answer definitively.
|
|
| At 03:11 PM 11/22/99 +0000, Gerry Reilly wrote:
| >Hi
| >
| >Please forgive this newbee question.
| >
| >I've been reading through the TBGP, SCSP & TRIP drafts with great
| >interest:-) As a relative newcomer to the VoIP area, I'm not entirely
| >clear as to where the Open Settlements Protocol fits into the model, if
at
| >all.
| >
| >OSP seems to claim to be designed for inter-domain route selection as
well
| >as facilitating billing.
| >Would this protocol supplement TRIP, or am I missing the point?
| >
| >Kind Regards
| >
| >Gerry Reilly
| >
| >
| >
| >---------
| >This message came from the IETF IPTEL Working Group Mailing List.
| >
|
| Matt Squire
| Nortel Networks
| innovations.lab
| [email-masked]
| (919)992-9048
|
| ---------
| This message came from the IETF IPTEL Working Group Mailing List.
|

---------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 1999 16:35:29 -0500

Thanks for the clarification, Stephen.

Based on this, I see their roles as complementary. An OSP server needs
some way to build up the routing table it uses to answer OSP queries.
TRIP fits this need perfectly. In fact, OSP is effectively what is
called "the front end" in the TRIP framework document; its the way by
which TRIP databases are accessed. OSP is a query protocol, and TRIP is
more like a routing protocol. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---------

---

From: "Stephen Thomas" <[email-masked]>
Date: Mon, 29 Nov 1999 14:34:53 -0500

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>

| Based on this, I see their roles as complementary. An OSP server needs
| some way to build up the routing table it uses to answer OSP queries.
| TRIP fits this need perfectly. In fact, OSP is effectively what is
| called "the front end" in the TRIP framework document; its the way by
| which TRIP databases are accessed. OSP is a query protocol, and TRIP is
| more like a routing protocol. 

Exactly.

Stephen

---------

---

From: "Hussein F. Salama" <[email-masked]>
Date: Mon, 29 Nov 1999 15:27:56 -0800

I remember having discussed a different model with Stephen Thomas long
time
ago. Here's roughly how I think the other model worked:
- An OSP server supplies an LS with the destination sets (prefixes) that
LS is permitted/authorized to advertise. For each destination set, the
OSP server provides an authentication token. In addition, the OSP server
may provide the LS with attributes of the destination set, e.g.
capacity.
- The LS advertises the destination set, the authorization token, and
the associated attributed to its peers.
- When a peer LS receives this advertisement it can verify the
advertised information using the attached  authentication token.
- The advertisement propagates through the network.
- When an ingress gateway or voice proxy receives a call, it queries its
TRIP LS, and NOT it OSP server on how to route it next.

OSP server have to deal with many queries other than call routing, e.g.
authentication and billing. In the above model, TRIP LSs relieve the OSP
servers from having to respond to call routing queries coming from the
individual gateways and proxies. However, the OSP servers are still in
control of call routing, because any call routing update propagated
through the network must carry an authorization token issued by an OSP
server.

One more comment below.

> Jonathan Rosenberg wrote:
> >

AFAIK (Stephen, please correct me if I am wrong) a single OSP server
will probably be responsible for multiple domains. I doubt that such a
big server will have a fine enough view of the topology, which is
necessary to do call routing. On the other hand there has to be at least
one TRIP LS per ITAD.

Hussein

> Hussein F. Salama
> Cisco Systems
> Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
> Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

-- 
Hussein F. Salama
Cisco Systems
Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134
Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714

---------