Subject: RE: [Speermint] Multihop routing

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 23 Feb 2007 15:45:50 -0500

Even with the federation draft, I believe that the problem still exists, just moved slightly.  Equate the SIP domain, either P2P or Federation model, to an autonomous system, and the problem lies with there being no SIP inter-AS mechanisms.

-AU

 -----Original Message-----
From: 	Reinaldo Penno [mailto:[email-masked]]
Sent:	Fri Feb 23 15:32:58 2007
To:	Andrew Newton; Otmar Lendl
Cc:	[email-masked]
Subject:	RE: [Speermint] Multihop routing

Reading Otmar's federation draft I had the impression that many
practical problems related to multi-hop SIP routing were addresed there.

IMO a SIP layer routing protocol have a very low chance (zero?) of not
only becoming a WG item but being implemented as well. 

This begs the question on what is going on with the federation drafts?
They are not WG items, but they are referred byt other WG docs
explicitly. Everytbody talks about it but in San Diego it seemed we did
not get enough raised hands to make it a WG item....

So?

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Friday, February 23, 2007 11:20 AM
> To: Otmar Lendl
> Cc: [email-masked]
> Subject: Re: [Speermint] Multihop routing
> 
> This sounds like RFC 3219.
> 
> -andy
> 
> On Feb 23, 2007, at 11:57 AM, Otmar Lendl wrote:
> 
> > On 2007/02/20 22:02, "Livingood, Jason"  
> > <[email-masked]> wrote:
> >>
> >> If you have some suggestions on how multi-hop routing and routing 
> >> based on numbers should occur that is not fully addressed 
> elsewhere, 
> >> I encourage you to start up some threads on the mailing 
> list here.  I 
> >> suspect other folks may be experiencing the same issues 
> you cite, but 
> >> the only way to tell is to start up discussion.
> >
> > The issue is rather simple:
> >
> > One of the basic premises of SIP is the famous end-to-end principle:
> >
> >   The destination uses the DNS to publish the IP addresses of
> >   its ingress elements.
> >
> >   On the sender side, the call may be handed to one outbound-
> >   proxy, which is independent of the destination of the call.
> >
> >   Between that outbound proxy and the ingress proxy all
> >   routing is pure layer3: no further SIP device is involved.
> >
> >   To achieve worldwide reachability, the ingress elements of the
> >   destination must accept calls from any source on the Internet.
> >
> > Almost all of the scenarios as documented by current drafts in the 
> > speermint WG deviate from this model, they assume:
> >
> > * A VSP wants to control with whom he peers
> >
> > * Peering is done over private networks
> >
> > * Non-public databases are used to route calls over such
> >   interconnection networks.
> >
> > * In order to complete calls to any valid destination TN/URI,
> >   VSPs have to rely on the PSTN (as fall-back) and transit
> >   service providers.
> >
> > ---------------------
> >
> > What does that mean for a typical call? The SIP 
> architecture assumes 
> > something like this:
> >
> >
> >    /---\  /---\    ----------------  /---\  /---\
> >    |UAC|--|VSP|-- / pure layer 3 / --|VSP|--|UAC|
> >    \---/  \---/  ----------------    \---/  \---/
> >
> > whereas the speermint requirements lead to diagrams like this:
> >
> >    /---\  /---\  /-----\  /-----\   /---\  /---\
> >    |UAC|--|VSP|--|tVSP1|--|tVSP2|---|VSP|--|UAC|
> >    \---/  \---/  \-----/  \-----/   \---/  \---/
> >
> > (with transit VSPs involved at the SIP layer).
> >
> >
> > Real life is way more complicated: There are a lot of VSPs which 
> > interconnect to each other over private links, peering fabrics, or 
> > even over the Internet.
> >
> > If we start to draw that as a graph with VSPs as nodes and 
> peerings as 
> > edges, than we have a text-book example of a generic 
> network. A call 
> > from one side of the network to the other needs to find a 
> path through 
> > this graph. Each step is a SIP peering, which could involve 
> any number 
> > of layer3 hops between the SIP proxies.
> >
> > The SIP mechanisms are fine _within_ each step: The 
> microcosmos of a 
> > peering fabric looks like the Internet as envisioned by the SIP
> > standard: full L3 connectivity between participants plus a 
> shared DNS 
> > tree including an ENUM branch.
> >
> > What SIP can't do is routing between these mini-Internets. 
> There are 
> > no mechnisms to choose the best of a multitude of possible paths 
> > through the network of VSPs.
> >
> > That wasn't part of the design, as this is a radical departure from 
> > the sacred end to end principle.
> >
> > There are just two possible choices:
> >
> > * Convince the VSPs to adopt the end to end priciple and open
> >   up their networks (and forget about termination fees as a side
> >   effect), or
> >
> > * Be prepared to design a routing protocol on the SIP layer.
> >
> > (Compromises here don't look feasible to me, something like 
> > http://en.wikipedia.org/wiki/Open_settlement_protocol might 
> be used to 
> > decouple the trust relations from connectivity, but I doubt 
> that would 
> > be enough.)
> >
> > ------------
> >
> > Here is an analogy from a bit lower on the protocol stack:
> >
> > If you want to send an IP packet over a switched ethernet 
> > infrastructure, you just need one ARP request to map IP 
> address to MAC 
> > address which is used to send the packet on its way.  Both 
> sides don't 
> > care how many L2 switches are involved, and what version of the 
> > spanning tree protocol they use to build their mac-based forwarding 
> > table.
> >
> > As long as the whole network is a single broadcast domain, 
> this works 
> > fine. If you have just a few other LANs you might employ 
> proxy ARP to 
> > bridge these together.
> >
> > This band-aid is clearly insufficient once the single L2 network is 
> > split up in multiple networks connected via L3 routers. ARP 
> is still 
> > fine within each segment, but a L3 routing protocol is needed to 
> > maintain connectivity on the IP layer.
> >
> > Substitute as follows:
> >
> > IP layer	-> SIP layer
> > IP address	-> SIP URI  (or Telephone number)
> > MAC address	-> IP address
> > spanning tree	-> BGP
> > broadcast domain-> IP layer connectivity
> > ARP		-> DNS lookup to map domain to IP address
> > proxy-ARP	-> announcing non-local destinations in a
> > 		   fabric's DNS
> >
> > and thus
> >
> > L3 routing	-> SIP routing
> >
> > Just as it would be ridiculous to propose to use proxy-ARP to solve 
> > the worldwide IP routing problem, I'd be very sceptical 
> that one can 
> > solve the VoIP routing problem with minor tweaks of the 
> RFC3263 rules.
> >
> > ------------
> >
> > All this doesn't mean we don't need to talk about how individual 
> > peering fabrics (these mini-Internets) work and what BCPs 
> with regards 
> > to SIP we need to come up with for them.
> >
> > But all that will never ever be enough to replace the PSTN as THE 
> > global voice network with a SIP-based alternative.
> >
> > Comments?
> >
> > /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