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

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 30 May 2006 13:22:51 -0400

Those are good steps to capture in a draft.  Perhaps eventually we'll
see specific use case I-Ds that will consistently demonstrate out a need
for each of these steps.  Once we get some consensus there, that can
inform the requirements draft now developing.

Jason 

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Monday, May 29, 2006 8:27 PM
> To: [email-masked]; Khan, Sohel Q [CTO]; Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Speermint] Defining Location Function 
> (RE:UpdatedDraft:SPEERMINT Peering Architecture)
> 
> 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:[email-masked]]
> > Sent: Monday, May 29, 2006 2:54 PM
> > To: 'Khan, Sohel Q [CTO]'; 'Stastny Richard'
> > Cc: [email-masked]
> > 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:[email-masked]]
> > > Sent: Monday, May 29, 2006 2:56 PM
> > > To: Stastny Richard
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > Sent: Monday, May 29, 2006 10:06 AM
> > > To: Khan, Sohel Q [CTO]
> > > Cc: [email-masked]
> > > 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:[email-masked]]
> > > > Sent: Monday, May 29, 2006 4:30 PM
> > > > To: Stastny Richard
> > > > Cc: [email-masked]
> > > > 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:[email-masked]]
> > > > Sent: Sunday, May 28, 2006 3:07 AM
> > > > To: Khan, Sohel Q [CTO]
> > > > Cc: [email-masked]
> > > > 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:[email-masked]]
> > > > Gesendet: So 28.05.2006 06:48
> > > > An: Stastny Richard; Reinaldo Penno
> > > > Cc: [email-masked]
> > > > 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" <[email-masked]>
> > > > To: "Reinaldo Penno" <[email-masked]>
> > > > Cc: "[email-masked]" <[email-masked]>
> > > > Sent: 5/27/06 4:52 PM
> > > > Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering
> Architecture
> > > >
> > > > What question?
> > > > Richard
> > > >
> > > > ________________________________
> > > >
> > > > Von: Reinaldo Penno [mailto:[email-masked]]
> > > > Gesendet: Sa 27.05.2006 23:46
> > > > An: Stastny Richard
> > > > Cc: [email-masked]
> > > > 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:[email-masked]]
> > > > > Sent: Saturday, May 27, 2006 2:38 PM
> > > > > To: Reinaldo Penno
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > > Architecture
> > > > >
> > > > > ENUM issues should not be discussed in SPEERMINT, just some
> > > questions
> > > > >
> > > > > >Enum? When I dial (650) 453 2312, 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 +16504532312
> > > > >
> > > > > 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:[email-masked]]
> > > > > Gesendet: Sa 27.05.2006 21:30
> > > > > An: Stastny Richard; Otmar Lendl
> > > > > Cc: [email-masked]
> > > > > Betreff: RE: [Speermint] Updated Draft: SPEERMINT Peering
> > > Architecture
> > > > >
> > > > >
> > > > >
> > > > > Enum? When I dial (650) 453 2312, 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:[email-masked]]
> > > > > > Sent: Saturday, May 27, 2006 4:26 AM
> > > > > > To: Reinaldo Penno; Otmar Lendl
> > > > > > Cc: [email-masked]
> > > > > > 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:[email-masked]]
> > > > > > Gesendet: Sa 27.05.2006 11:04
> > > > > > An: Otmar Lendl; Patrick Melampy
> > > > > > Cc: Khan, Sohel Q [CTO]; [email-masked]
> > > > > > 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:[email-masked]]
> > > > > > > Sent: Saturday, May 27, 2006 1:29 AM
> > > > > > > To: Patrick Melampy
> > > > > > > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]
> > > > > > > Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering
> > > > > Architecture
> > > > > > >
> > > > > > > On 2006/05/26 18:05, Patrick Melampy
> <[email-masked]>
> > > > > 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 ([email-masked]) | nic.at Systems Engineer >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> 

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