Federations

1
Federations

• Otmar Lendl
• enum.at

IETF speermint interim meeting Philadelphia,
2006/09/18
2
Content

• Context and Aim
• A closer look at the requirements
• Design Goals
• Federations
• The Domain Policy DDDS Application
• Use Cases

3
Status Quo

• No technical hurdles for universal VoIP
  Interconnection
• RFC 3261 / 3263 exist
• VoIP Islands
• The open Internet is not a friendly place
• Operators want to keep control on who they talk
  to
• Lots of interconnection is happening
• Private arrangements
• Commercial Peering Services

4
Speermint Goals

• No call originating on IP and terminating on IP
  should have to traverse the PSTN.
• Remove roadblocks to widespread VoIP Peering
• Build a framework for the overall call routing
• Provide guidance for individual interconnects
• Give VSPs a clear path forward

5
Lets be realistic

• Nothing we can do here will cause universal
  peering
• RFC3261/3263 would be enough
• There is no solution to SPIT if you assume that
  anybody can connect to anybody
• This is business and not techie territory
• So lets just aim for making peering as easy and
  flexible, and thus as widespread as possible.

6
Observations

• VoIP Interconnect differs from SS7 or BGP
• Not only point to point links
• That changes the provisioning
• Could be zero settlement
• That changes the provisioning even more
• Information flows are not bound to peering
  relationships
• Lookup functions can be independent

7
Two main Aspects

• Routing decision
• Input Destination address
• Output Next hop (peer)
• Call establishment procedure
• SIP parameters
• Codecs
• QoS,

We need a unified solution for this.
This can vary by federation.
8
Requirements

• Unified solution
• Domain Based
• No blocked calls
• Scaling
• Independence of lower layers
• Administrative and technical policies
• Minimal additional cost on call initiation

9
Unified solution

• Private 11 peerings
• Private nn peerings
• TLS based
• Walled gardens (10.x, IPsec, IPX, )
• Assisted peering
• SIP redirect
• SIP forward
• Open Internet

10
Domain based

• Dialing URIs must be supported.
• Hard requirement
• Routing decisions cannot be based on E.164
  numbers.
• Just as in email local part (username) of URI
  should not matter in routing decisions.
• Thus Domain is the input to the routing algorithm

11
Scaling

• Problem size?
• VSPs Large.
• domains Really Large.
• Corollaries
• We need aggregation even between VSPs.
• Either as service or in the routing scheme
• Exchanging routing tables based on domains wont
  cut it.

12
No blocked calls

• There are things worse than a SIP 5xx error
• Timeouts!
• This is easy for explicitly configured bi-lateral
  peerings.
• For more ad-hoc scenarios, this is important
• Firewalls
• TLS parameters
• IPsec

13
Independence of lower layers

• The speermint routing architecture should not
  depend on specific parameters for
• MPLS setups
• Ethernet
• ATM
• Assuming IP layer connectivity must be enough.

14
Administrative and technical policies

• Peering decisions can be based on
• Contracts / Memberships / MoUs ..
• Technical preconditions
• Necessary vs. sufficient conditions

15
Call Flow Questions

• Is the target number on IP?
• Who is hosting the number?
• Do we peer with each other?
• If not, who can I use as transit?
• How do I deliver the call?

16
Current schemes
E.164 Number
E.164 Number
Simple Lookup
Integrated Solution
SIP URI
Peering Policy
SIP Next Hop Info
SIP Next Hop Info
One Lookup
Two Lookups
17
What about layering?

• speermint is not about E.164 numbers.
• URI dialing is not possible.
• Mix of enum and speermint work.
• Is that really simpler?

E.164 Number
Integrated Solution
SIP Next Hop Info
18
Scaling
How to decide which fabric to use?
E.164 Number
E.164 Number
Simple Lookup
SIP URI
Multiple Fabrics
Peering Policy
SIP Next Hop Info
SIP Next Hop Info
19
Design Goals

• Policy autonomy
• Separate number matching from policy matching
• Automatic peer discovery must be possible
• Call flow intermediaries must be optional
• Based on standard
• Minimal changes to SIP stacks

20
Federations

• Aggregation vehicle for peering relationships.
• Reduce the O(n²) scaling
• Enables automatic peering
• Keyed on the domain

21
Federations

• A Group of VoIP Service Providers, that
• Allows calls between each other
• Have a common administrative policy
• Share a common technical setup for
  interconnection
• Multiple memberships possible.
• These are simple sets.

22
Examples

• Bilateral Peering
• Open SIP servers on the Internet
• TLS Cloud
• Layer 3 walled gardens
• SIP Hub
• A single provider (wrt. Network grooming)

23
Federation based Routing

• If source and destination are members of the same
  federation then a direct connection is possible.
• Discovering such a shared federation needs to be
  as automatic as possible.
• One way federation distributes list of all
  members (and their SIP domains).
• Better Members publish their list of
  federation.
• Much better scaling than just private peerings.

24
Why the DNS

• VSPs can be identified by their Domain
• Cant be done with SIP Chicken Egg
• Its the next abstraction after A, SRV and NAPTR
  records
• The infrastructure is in place (incl.
  authentication)
• No extra cost no more lookups than RFC3263
• Scaling

25
Dynamic Delegation Discovery System (DDDS)

• RFC 3401ff
• Lazy bindings of strings to data
• Sequence of mapping operations
• Distributed database
• Can use the DNS as DB.
• Example
• ENUM (E.164 to URI mapping)

26
The Domain Policy DDDS

• Input Domain
• As taken from the destination SIP URI
• Output
• Set of atomic policy rules
• Boolean expression, listing options.
• Combined with local configuration
• Call routing data

27
Federation Types

• Named Federations
• Based on contracts
• Sponsoring organisation
• Services-field D2PSIPfed
• Ad-Hoc Federations
• Based on common standards
• Services-field D2PSIPstd
• Both use URIs as identifiers.

28
Usage scenarios

• Based on
• draft-lendl-domain-policy-ddds-02
• draft-lendl-speermint-federations-03
• draft-lendl-speermint-technical-policy-00
• OpenSer domainpolicy module
• Freely available at www.enum.at
• About 2k lines of code
• Updated version up next week

29
Components

• Destination side
• DNS entries announcing federation memberships
• A local database on the sender side
• Which federations have I joined?
• What special call processing rules apply within
  these federations?

30
TLS based federation

• Calls over the public Internet are accepted if a
  signed X.509 cert is used.
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urnexamplef
  ed1! .
• Openser.cfg
• tls_client_domainfed1"
• tls_certificate "/path/to/tlsfed/example-com.
  key"
• tls_private_key "/path/to/tlsfed/example-com.
  crt"
• tls_ca_list "/path/to/tlsfed/ca.pem"
• tls_method tlsv1
• tls_verify_server 1
• Local DB

31
SIP hub

• Calls inside the federation are routed via a
  central SIP proxy.
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urnexamplef
  ed2! .
• Local DB

32
Private Network

• The federation has established its own L3
  network. A DNS prefix is used to discover ingress
  points within that network.
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urnexamplef
  ed3! .
• sip-fed3 A 10.0.0.42
• Local DB

33
Private Network (2)

• Same as before, plus The prefix is
  sender-dependent.
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urnexamplef
  ed4! .
• dt.sip-fed4 A 10.0.0.40
• sprint.sip-fed4 A 10.0.0.41
• .sip-fed4 A 10.0.0.42
• Local DB
• Here are the records for sprint

34
Private Network (IPX case)

• Branch off to a private DNS tree
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urn3gpp!
  .
• ORIGIN 3gpp.org
• _sip._udp.example.com SRV 10 5060 sip.example.com
• sip.example.com A 192.168.0.1
• Local DB

35
Referrals

• Small.com contracts big.com to provide incoming
  SIP transit
• DNS
• NAPTR 10 10 D2PSIP big.com
• Local DB

36
Mixing

• Small.com from above joins fed1
• DNS
• NAPTR 10 10 u D2PSIPfed !.!urnexamplefe
  d1! .
• NAPTR 20 10 D2PSIP big.com
• Local DB

37
Standard based federations

• E.g. Reinaldos SUBSCRIBE draft
• DNS
• NAPTR 10 10 u D2PSIPstd !.!urnietfidp
  enno-.! .
• Local DB (not implemented yet)

38
Thats all for now, folks!