Subject: RE: [Speermint] Reachability

From: "Stastny Richard" <[email-masked]>
Date: Thu, 6 Apr 2006 10:45:38 +0200

Hi Reinaldo,

> I'm having a hard time understanding the complications...Sorry but I'm
> going to ask basic questions again before we dwell in many (more)
> discussions. It _seems_ to me we are overly complicating each topic.

Yes, yes ;-)

My two cents:

IMHO we have two basic options in the A-B-C scenario:
Assuming that A-B-C are all in the same IP address space
(and leaving out for the moment that A and C are in different
IP address spaces and B is doing some fancy NAT/MediaGW/SBC ;-)
stuff having connections to both spaces.)

Option 1: B is only involved in signalling, mediastream is direct A-C
Option 2: B is also involved in media stream

Option 1: The only task of B is to provide transit of TRUST
C is not trusting A, so a cannot place a call directly to C,
but B is trusting A and C is trusting B. This is basically what
all these "peering" fabrics such as SIPIX and XConnect provide.
One should also keep in mind that in most cases the mediastream
is not even going A-C, it is going O-UA to T-UA and may not
even touch the A and C "networks". This is the case if A and C
are only "administrative domains"

IMHO this is the first priority case of SPEERMINT to be solved

Option 2 implies by definition that the mediastream is
going through A and C "networks" in the first place. To do
so, the mediastream from O-UA and T-UA has first to be
brought into the A and C "networks". This can be done either
that they are connected directly or tunnelled into these networks
This also implies that they are not by definition in the same
address space, but in a private address space of A or C. Reason
is of course walled garden, QoS and charging.

A and C have first to gateway now the media and signalling from
the UAs into a common address space where also B lives.

We see, Option 2 is getting quite complicated very fast. 
(and BTW this is the IMS model solved somewhere else anyway)

This is why I want to get Option 1 done first

Cheers

Richard

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 9:55 AM
> To: Stastny Richard; Lee, Yiu; Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> I'm having a hard time understanding the complications...Sorry but I'm
> going to ask basic questions again before we dwell in many (more)
> discussions. It _seems_ to me we are overly complicating each topic.
> 
> Are A and C paying B to carry _IP_ packets (which includes signaling
and
> media)? Can A send and receive packets from C? So, unless A and C want
> something special done to their signaling traffic I wonder what B has
to
> do with it... Why would I pay B to be a proxy hop if I can send
packets
> directly? Are A and C concerned with security, or wondering how to
peer
> directly? Well, then peer directly over a TLS connection.
> 
> Also, I do not understand "transit services" in this context. This is
> not the PSTN. We are talking IP backbones, right?
> 
> I'm assuming A has DNS access and so has C. They can figure out by
> themselves the "sip route" of the signaling services. There is nothing
> SIP related that B can provide that A and C cannot figure out. The
> endpoints are in A and C; B does not have control over the E.164
> numbers, ENUM, SIP URIS, etc.
> 
> I can have a SIP TLS connection from my house over 5 different
backbones
> and peer with another proxy server in Japan. That's the fundamental of
> Layer 5 peering, no? It is an overlay network over IP. Unless some
> carrier/provider has some access list, I wonder what the problem is.
> 
> Now, maybe I'm missing something, maybe we need to hash out this
example
> further.
> 
> Regards,
> 
> Reinaldo
> 
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Thursday, April 06, 2006 12:05 AM
> > To: Lee, Yiu; Hadriel Kaplan; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Inline
> >
> > > -----Original Message-----
> > > From: Lee, Yiu [mailto:[email-masked]]
> > > Sent: Thursday, April 06, 2006 1:22 AM
> > > To: Hadriel Kaplan; Stastny Richard; [email-masked]
> > > Subject: RE: [Speermint] Reachability
> > >
> > > This is an interesting thread especially for the scenario A-B-C
> where
> > B
> > > is providing transit services. In near term , I don't see any
> operator
> > > will like to provide transit services since I don't smell money in
> > this
> > > area ;-) Also, if A doesn't peer C directly, we have our old
friend
> > PSTN
> > > to do the work (at least working for the voice service).
> >
> > No, you do NOT have the Good old PSTN to do the work in SPEERMIND
> > SPEERMINT (peering, interreconnect; whatever) is not E.164 aware,
> > so the PSTN is NOT an Option
> >
> > > The
> > > complication of providing transit services is to guarantee service
> > > delivery. In theory, the SIP proxy in B doesn't need to
record-route
> > > itself so that it can leave the signaling path as soon as A & C
> > > establish the session. Reality is B must stay in the signaling
path
> > > because A signed a peering agreement with B and B signed a peering
> > > agreement with C, there is no agreement between A & C and the
> > agreement
> > > is not transitive. If A sends a mid-dialog request directly to C,
> C's
> > > policy may probably reject it. For the media flow, I also argue
that
> > > even if A & C have directly IP peering connectivity, A's media
> traffic
> > > should flow through B's IP network then to C's IP network.
> >
> > You are implying L3 peering is atomatically with L5 peering,
> > I thought we had this one
> >
> > > The reason is
> > > B signed QoS agreement with A & C, but A & C may not have any, so
C
> > > won't prioritize the media traffic coming directly from A's IP
> peering
> > > interface. If the link is congested, the service quality will
> degrade.
> >
> > Implying there is an unneccessary Qos agreement in the core. As the
> > Scott
> > Marcus paper points out, this is unnecessary in most cases and
> > also not controllable. QoS, if at all, is only required in the
access.
> >
> > We should not waste our time with unimplementable issues.
> >
> > >
> > > I think peering is above policy. I assume that this WG will take
the
> > > lead to define and standardize the peering policy as well as the
> > > protocol distributing the policy.
> > >
> > > Yiu
> > >
> > >
> > > -----Original Message-----
> > > From: Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Sunday, April 02, 2006 9:48 PM
> > > To: 'Stastny Richard'; [email-masked]
> > > Subject: RE: [Speermint] Reachability
> > >
> > > Hi Richard, comments inline...
> > >
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Saturday, April 01, 2006 2:46 PM
> > > > To: [email-masked]
> > > > Subject: [Speermint] Reachability
> > > >
> > > > after reading the document from Scott Markus on NGN Interconnect
I
> > > > referenced for weekend reading in my last posting
> > > >
> >
http://www.itu.int/osg/spu/ngn/documents/Papers/Marcus-060323-Fin-v2.1
> > > > .pdf
> > >
> > > Indeed that was an interesting paper - thanks for the pointer!
(not
> > that
> > > I agree with everything in it)
> > >
> > > > and second we always started naturally at provider A in
direction
> of
> > > > call set-up and not at provider B
> > >
> > > Personally, I think the bigger "problem" is the provider C, the
one
> > > after B.
> > > :)  C trying to be reachable by A through B.  But that's out of
> scope
> > I
> > > guess.  It's too bad, because that's when BGP got interesting, for
> > > example.
> > >
> > > > Provider B has now (currently only for Public User Identities in
> the
> > > > form of E.164 numbers) the OBLIGATION making this PUI reachable
> for
> > > > the public by interconnecting with the public network (in this
> case
> > at
> > >
> > > > least via the PSTN) [snipped] So IMHO we can assume that
provider
> B
> > > > hosting a Public User Identity (a SIP URI) MUST make this PUI
> > > > reachable in principle.
> > >
> > > I would think that would only be true if you define the AoR to be
a
> > > public identity in the public domain, and such regulation was to
be
> > > created for AoRs.  E.164 numbers are by definition such numbers, I
> > > think.  But if, for example, I build a private enterprise network
-
> > > there's no way I'm obligated to do so just because I use the same
> SIP
> > > fields AoRs are used in.
> > >
> > > Having said that, I would think most providers _want_ to make them
> > > reachable, because that increases their value.  But as the paper
> > pointed
> > > out, peering is difficult to manage beyond a few hundred peers,
nor
> do
> > > IP or PSTN providers peer with everyone directly to achieve
> universal
> > > reachability.  That's why, for me, the more complex problem is the
> > > peer(s) between.  But documenting A-B/B-A is a good start.
> > >
> > > > The NRA normally sets the limits to such an offer.
> > >
> > > The power of the national rifle association is staggering.  ;)
> > >
> > > -hadriel
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint

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