RE: [Speermint] Defining Location Function (RE: UpdatedDraft:SPEERMINT Peering Architecture)

["Reinaldo Penno" <[e-mail]>]

Sohel,

I believe a VoIP-VoIP call have several stages:

1. Location

How do I (domain A) discover where the proxy (which could be the final
one) to cross into domain B? There can be more than one in a certain
location and even geographically dispersed locations.

1.1 Policy exchange I

In determining domain's B crossing point, a policy query/exchange might
happen. This might come in the form of DNS, a lookup on SUBSCRIPTION
data or both

2. Membership

After I discover domain's B proxy how to establish peering? Is it
already established? Is it a federation?

This is what I call membership process.

3. Policy exchange II

In a certain location where domain A and B peer, domain A's proxy might
perform (another) policy exchange/query to find out which of domain's B
several proxies is the best suited at that point in time. 

4. Call establishment

Call gets established.

5. Media

Media goes probably through the same path being marked according to the
peering fabric's dscp.

Regards,

Reinaldo

> -----Original Message-----
> From: Richard Shockey [mailto:[e-mail]]
> Sent: Monday, May 29, 2006 2:54 PM
> To: 'Khan, Sohel Q [CTO]'; 'Stastny Richard'
> Cc: [e-mail]
> Subject: RE: [Speermint] Defining Location Function (RE:
> UpdatedDraft:SPEERMINT Peering Architecture)
> 
> 
> NO .. that was called TRIP ( go do a RFC search) and no one in their
right
> mind wants to put a BGB like layer on VoIP routing.
> 
> 
> 
> > -----Original Message-----
> > From: Khan, Sohel Q [CTO] [mailto:[e-mail]]
> > Sent: Monday, May 29, 2006 2:56 PM
> > To: Stastny Richard
> > Cc: [e-mail]
> > Subject: [Speermint] Defining Location Function (RE: Updated
> > Draft:SPEERMINT Peering Architecture)
> >
> >
> > Is it possible to take lessons from hierarchical eBGP routing?
> > We can consider each provider as the Autonomous System (say Level
0), a
> > federation is a hierarchical Autonomous system (say Level 1) that
> > contains a group of Autonomous-system (level 0).  Hierarchical
> > Autonomous system's (Level 1) SIP route-database (as opposed to the
BGP
> > routing table) is the Location Function (LF). SIP call routing
feature
> > will be destination-based, path-vector based, and policy based
similar
> > to BGP features.
> > I am trying to initiate a discussion in a different angle.
> >
> > Thanks,
> >
> > Sohel Khan, Ph.D.
> > Technology Strategist
> > Sprint-Nextel
> > 913-794-1470 (office)
> > 913-486-3145 (cell)
> >
> >
> >
> >
> > -----Original Message-----
> > From: Stastny Richard [mailto:[e-mail]]
> > Sent: Monday, May 29, 2006 10:06 AM
> > To: Khan, Sohel Q [CTO]
> > Cc: [e-mail]
> > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> >
> > Sohel,
> >
> > I posted this already on Friday, but I think everybody (including
me)
> > lost track already;-)
> >
> > So here once again:
> >
> > "May I try my summary: the Location function is a process containing
> > eventually more then one step:
> >
> > "If you start with the CRD (e.g a SIP AoR entered by the User or
derived
> > from ENUM)"
> >
> > Remark: Whith this I ment that the E.164 to SIP URI mapping is
already
> > done, because this is out-of-scope of SPEERMINT.
> > In addition, SPEERMINT MUST be able to work in the same way if the
user
> > has entered a SIP URI direct. This is why I prefer that the result
of an
> > ENUM query is an AoR and not directly the ingress element to the
> > destination network.
> >
> >
> > "1. The AoR gives you the destination network
> >
> > 2. You need to locate the peering club (= federation) for exchanging
SIP
> > messages (L5 )with the destination network
> >
> > 3. so you need to locate the policy you want to use and make a
decision
> > on the federation
> > (note: a destination network may belong to more then one
federations)"
> > (Remark: both origination network and destination network may be
members
> > of more then one federation. They may need to locate a common one.
If
> > more then one federation is in common, it is the choice of the
> > origination network to select one - So the Policy Function is
embedded
> > in the LF)
> >
> > 4.  "having chosen a federation, you need to locate the ingress
> > proxy(ies) the destination network is using within this federation.
> >
> > 5. If you are using a separate peering for exchanging media, you now
may
> > locate these"
> >
> > Additional remark: In step 4. and 5. some geographic location magic
> > could come into play as requested by some on this list.
> >
> > Regards
> > Richard
> >
> > > -----Original Message-----
> > > From: Khan, Sohel Q [CTO] [mailto:[e-mail]]
> > > Sent: Monday, May 29, 2006 4:30 PM
> > > To: Stastny Richard
> > > Cc: [e-mail]
> > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> > >
> > > Richard,
> > >
> > > Would you please describe what LF should perform (in your
opinion)?
> > >
> > >
> > > Thanks,
> > >
> > > Sohel
> > >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[e-mail]]
> > > Sent: Sunday, May 28, 2006 3:07 AM
> > > To: Khan, Sohel Q [CTO]
> > > Cc: [e-mail]
> > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> > >
> > > I do not know how often I stated here that numbering issues (and
> > > therefore also NUMBER Portability issues) are out-of-scope in
> > SPEERMINT
> > >
> > > So NUMBER Portablility cannot ne addressed in SPEERMINT LF
> > >
> > > Or we change the SPEERMINT charter
> > >
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Khan, Sohel Q [CTO] [mailto:[e-mail]]
> > > Gesendet: So 28.05.2006 06:48
> > > An: Stastny Richard; Reinaldo Penno
> > > Cc: [e-mail]
> > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> > >
> > >
> > >
> > > I think issues of mobility and number portability need to be
addressed
> >
> > > together in SPEERMINT LF.
> > >
> > > Sohel Khan, Ph.D.
> > > Sprint-Nextel
> > >
> > > -----Original Message-----
> > > From: "Stastny Richard" <[e-mail]>
> > > To: "Reinaldo Penno" <[e-mail]>
> > > Cc: "[e-mail]" <[e-mail]>
> > > Sent: 5/27/06 4:52 PM
> > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> > >
> > > What question?
> > > Richard
> > >
> > > ________________________________
> > >
> > > Von: Reinaldo Penno [mailto:[e-mail]]
> > > Gesendet: Sa 27.05.2006 23:46
> > > An: Stastny Richard
> > > Cc: [e-mail]
> > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
Architecture
> > >
> > >
> > >
> > > Apart form your outside-of-the-us rhetoric the questions remains.
> > >
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[e-mail]]
> > > > Sent: Saturday, May 27, 2006 2:38 PM
> > > > To: Reinaldo Penno
> > > > Cc: [e-mail]
> > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > Architecture
> > > >
> > > > ENUM issues should not be discussed in SPEERMINT, just some
> > questions
> > > >
> > > > >Enum? When I dial [phone], what is there to resolve
_inside_
> > > the
> > > > >wireless network that owns this number apart from the location
of
> > the
> > >
> > > > >user?
> > > >
> > > > and _outside_?
> > > > ENUM is about numbers like [phone]
> > > >
> > > > hello, we are talking E.164 numbers in ENUM, which is
international
> > > > numbers
> > > >
> > > > >Now, in the scenario where an external call (for example, a
> > cingular
> > > > >customer calling a Verizon customer (which owns an original
> > t-mobile
> > > > >number). How that works today? If you say ENUM I would stand
> > > corrected
> > > > >(and surprised), since LNP has been fully deployed since 2003.
> > > >
> > > > Cingular?Verizon? ...
> > > >
> > > > we are talking about a global solution here You are a bit US
centric
> >
> > > > here, there is also some 200 other nations ozt there.
> > > >
> > > > I have no access to the US LNP database from e.g. Austria
> > > >
> > > > So you want to consider US national databases only in speermint?
> > > >
> > > > Richard
> > > >
> > > >
> > > >
> > > > ________________________________
> > > >
> > > > Von: Reinaldo Penno [mailto:[e-mail]]
> > > > Gesendet: Sa 27.05.2006 21:30
> > > > An: Stastny Richard; Otmar Lendl
> > > > Cc: [e-mail]
> > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
> > Architecture
> > > >
> > > >
> > > >
> > > > Enum? When I dial [phone], what is there to resolve
_inside_
> > > the
> > > > wireless network that owns this number apart from the location
of
> > the
> > > > user?
> > > >
> > > >
> > > > Now, in the scenario where an external call (for example, a
cingular
> >
> > > > customer calling a Verizon customer (which owns an original
t-mobile
> >
> > > > number). How that works today? If you say ENUM I would stand
> > corrected
> > >
> > > > (and surprised), since LNP has been fully deployed since 2003.
> > > >
> > > > When a user takes its number with them, I assumed this punches a
> > whole
> > >
> > > > in the telephone prefix hierarchy and a specific entry somewhere
is
> > > > needed.
> > > >
> > > > Regards,
> > > >
> > > > Reinaldo
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Stastny Richard [mailto:[e-mail]]
> > > > > Sent: Saturday, May 27, 2006 4:26 AM
> > > > > To: Reinaldo Penno; Otmar Lendl
> > > > > Cc: [e-mail]
> > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > > Architecture
> > > > >
> > > > > >I wonder how
> > > > > >LNP is solved within wireless...A specific entry for each
phone?
> > > That
> > > > > >would be crazy.
> > > > >
> > > > > Ahem, ENUM?
> > > > >
> > > > > I thought that is all what ENUM is about?
> > > > >
> > > > > Richard
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > Von: Reinaldo Penno [mailto:[e-mail]]
> > > > > Gesendet: Sa 27.05.2006 11:04
> > > > > An: Otmar Lendl; Patrick Melampy
> > > > > Cc: Khan, Sohel Q [CTO]; [e-mail]
> > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
> > > Architecture
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > I believe the crux of the problem was missed.
> > > > >
> > > > > The issue is not really the number of domains. We have today
some
> > > > > 400.000.000 million hosts on the Internet. BGP peers to do not
> > > > exchange
> > > > > 400.000.000 million routes, they exchange in the low hundreds
of
> > > > > thousands.
> > > > >
> > > > > And why is that? (I guess you know where I'm getting at).
That's
> > > > because
> > > > > IP addresses lend themselves very well to hierarchical
deployment,
> >
> > > > > compression through prefix/CIDR usage and the like. DNS names
are
> > > > > strings and hence difficult to come up with a similar scheme.
> > > > >
> > > > >
> > > > > I believe that if domains need to be exchanged between peers:
> > > > >
> > > > > 1 - Just a limited set would be exchanged and a "default layer
5
> > > > route"
> > > > > (equivalent to a traditional default route) would be used.
> > > > >
> > > > > 2 - Compression schemes like *.company.com, regular
expressions or
> > > the
> > > > > like would need to be used. Having specific routes to AORs
would
> > be
> > > > > hairy (maybe for the eventual roaming or visiting user). I
wonder
> > > how
> > > > > LNP is solved within wireless...A specific entry for each
phone?
> > > That
> > > > > would be crazy.
> > > > >
> > > > > 3 - Some new scheme that will make somebody rich....until
then..
> > > > >
> > > > > I believe subscriptions would be used to exchange mostly
"cost"
> > and
> > > > > policy information and some domains. I use cost here in the
layer
> > 3
> > > > > sense (number of calls, jitter, whatever). Cost would be an
> > abstract
> > >
> > > > > value or a more specific one (up to the administrator).
> > > > >
> > > > > Regards,
> > > > >
> > > > > Reinaldo
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Otmar Lendl [mailto:[e-mail]]
> > > > > > Sent: Saturday, May 27, 2006 1:29 AM
> > > > > > To: Patrick Melampy
> > > > > > Cc: 'Khan, Sohel Q [CTO]'; [e-mail]
> > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > > > Architecture
> > > > > >
> > > > > > On 2006/05/26 18:05, Patrick Melampy
<[e-mail]>
> > > > wrote:
> > > > > > > I suppose like in any distributed routing protocol, there
are
> > > some
> > > > > > chicken
> > > > > > > an egg issues. But consider the following.
> > > > > > >
> > > > > > > PREREQUISITES:
> > > > > > > 1.) You know the destination DOMAIN from either ENUM or
other
> > > > means.
> > > > > >
> > > > > > [...]
> > > > > > >
> > > > > > > This technique is very similar to TRIP, only its for
DOMAINS
> > and
> > > > not
> > > > > > partial
> > > > > > > E.164 numbers.
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > > > Obviously, the data set could get large, as the list of
> > domains
> > > > can
> > > > > be
> > > > > > > really big. There are some possibilities here...
> > > > > >
> > > > > > Let's do a quick estimate on the number of domains involved:
> > > > > >
> > > > > > Right now, operators usually give customers URIs of the form
> > > > > > <number>@<providerdomain>. As long as this is the state of
> > > affairs,
> > > > > > we're fine as the number of providers is quite finite (a few
> > > > > > thousands, perhaps).
> > > > > >
> > > > > > This is like the state of affairs with respect to email,
anno
> > > 1990.
> > > > > > Back then customers started to notice that if they use their
own
> > > > > domain
> > > > > > for email, then they can switch providers without having to
> > change
> > >
> > > > > > their email address. Thus a *lot* of people opted to use
their
> > own
> > >
> > > > > > domain for email.
> > > > > >
> > > > > > My guess is that the same will happen to SIP. Once customers
> > print
> > >
> > > > > > their SIP uris on business cards, they will want to use
their
> > own
> > > > > > domains. If providers won't support that feature then I
suspect
> > > that
> > > > > > the regulators will step in and mandate an URI portability
> > > solution
> > > > > > just as they did in the PSTN with respect to numbers from
number
> > > > > blocks.
> > > > > > (This could get really nasty protocol-wise, so I guess using
> > > > customer-
> > > > > > owned domains is the far better and likelier solution to the
> > > porting
> > > > > > question.)
> > > > > >
> > > > > > So: Anything we come up with here in SPEERMINT needs to cope
> > with
> > > a
> > > > > > scenario where the use of customer domains in SIP URIs is
just
> > as
> > > > > > widespread as it is for email.
> > > > > >
> > > > > > How many domains are used for email? That's hard to say.
There
> > are
> > >
> > > > > > about 60 million gTLD domains and probably more than 20
ccTLD
> > > ones.
> > > > > > Assuming that only a tenth of that is used for email we're
at
> > > > > > 8 million domains. Given the exponential growth any system
which
> >
> > > > > > doesn't scale to at least 10 million domains will be
obsolete
> > > before
> > > > > > the ink is dry on the RFC.
> > > > > >
> > > > > > So what happens if we do some sort of BGP or TRIP with
domains?
> > > > > >
> > > > > > Let's say we need at least 100 bytes of state information
per
> > > > domain.
> > > > > > That makes a full routing table 1 GB worth of data. That
also
> > > means
> > > > > > that a new border element needs to exchange that amount of
data
> > > > > > with its peers before it has learned the current state of
the
> > > > > > routing table.
> > > > > >
> > > > > > That is some serious amount of data.
> > > > > >
> > > > > > > 1.) Have notification point to a published document, and
the
> > > > > document
> > > > > > lists
> > > > > > > all of the relevant reachability in real time. Thus any
change
> > > to
> > > > > the
> > > > > > > document would generate a NOTIFICATION.
> > > > > >
> > > > > > + a download of up to 1 GB per peer.
> > > > > >
> > > > > > > 2.) User partial domains, broken up by the "dots". This
may
> > > allow
> > > > > some
> > > > > > > wildcarding to reduce the number of domains. For instance,
a
> > > > carrier
> > > > > > like
> > > > > > > Verizon may have many 100's of domains attached to it, and
> > > version
> > > > > is
> > > > > > > willing to route and manage SIP traffic to any of them.
The
> > > NOTIFY
> > > > > could
> > > > > > > contain something like: Verizon.com or *.verizon.com to
> > indicate
> > > > > that
> > > > > > any
> > > > > > > domain in Verizon is reachable.
> > > > > >
> > > > > > That's helpful if a provider uses subdomains for internal
> > > purposes,
> > > > > > but that won't help you with customer owned domains.
> > > > > >
> > > > > > > This technique may work -- and fit nicely into an existing
> > > > protocol.
> > > > > All
> > > > > > we
> > > > > > > would need to do is define the data models (XML?) and or
> > > documents
> > > > > for
> > > > > > > exchanging.
> > > > > >
> > > > > > I think this technique can work -- if you add an aggregation
> > step
> > > > > > before the routing scheme.
> > > > > >
> > > > > > Take another look at BGP: there you have the concept of an
> > > > > > Autonomous System and not only that of prefixes. Maybe you
need
> > > > > > something similar.
> > > > > >
> > > > > > One approach to cope with hosted SIP domains could be to use
the
> >
> > > > > > hostnames as found in SRV records. E.g. for settings like
> > > > > >
> > > > > > _sip._tcp.customer.domain IN SRV 10 10 5060 sip.provider.com
> > > > > >
> > > > > > run the routing algorithm on "sip.provider.com" instead of
> > > > > > "customer.domain".
> > > > > >
> > > > > > Another option is to store some AS-equivalent in the
customer
> > > domain
> > > > > > and have the routing algorithm operate on that. In my
> > > domain-policy
> > > > > > framework this could be expressed e.g. like
> > > > > >
> > > > > > customers.domain IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > > > > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > > > > >
> > > > > > stating that this domain can be reached using the Speermint
> > > routing
> > > > > > logic by using the learned route to RoutingID 1042.
> > > > > >
> > > > > > Or, even better, use non-terminals, and thus refer to the
> > ingress
> > > > > > policy stored in the provider's domain:
> > > > > >
> > > > > > customers.domain IN NAPTR "" 10 10 "D2P+SIP" "" provider.com
> > > > > >
> > > > > > provider.com. IN NAPTR 10 10 "u" "D2P+SIP:route-id"
> > > > > >       "!.*!urn:ietf:speermint:RID:1042!" .
> > > > > >
> > > > > > (+ whatever other facts provider.com wants to announce about
his
> > > > > > reachability.)
> > > > > >
> > > > > > This combination of our ideas can indeed work and scale to
an
> > > > > > unlimited number of customer-owned domains.
> > > > > >
> > > > > > /ol
> > > > > > --
> > > > > > < Otmar Lendl ([e-mail]) | nic.at Systems Engineer >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Speermint mailing list
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> 
> _______________________________________________
> Speermint mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/speermint

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