1. The Domain Policy DDDS Application
draft-lendl-domain-policy-ddds-00
draft-lendl-speermint-federations-00
Otmar Lendl
2006/03/15
Domain Policy DDDS

2. Introduction
Interconnect SIP-based networks (enterprise and service providers) directly via SIP
Avoid transcoding, enable wideband codecs
Avoid service limitations (presence, IM, Video, …)
Cost saving
Avoid drawbacks of the open Internet model
Spam/Spit
Lack of trusted CallerID
Selective and controlled association
2006/03/15
Domain Policy DDDS

3. Evolution (1)
VoIP Service Providers interconnect via PSTN using E.164 numbers for addressing
VSP
VSP
VSP
VSP
VSP
PSTN Plane
2006/03/15
Domain Policy DDDS

4. Evolution (2)
User ENUM can be used to route calls over the public Internet.
Public Internet
User
ENUM
VSP
VSP
VSP
VSP
VSP
PSTN Plane
2006/03/15
Domain Policy DDDS

5. Evolution (3) The reality is more complex: Public Internet PSTN Plane
Private Interconnection Network
Private Interconnection Network
VSP
VSP
VSP
VSP
VSP
Public Internet
Closed SIP federation
PSTN Plane
2006/03/15
Domain Policy DDDS

6. Problem Statement Destination VSP Calling VSP
can be member of several VoIP peering fabrics.
may also accept calls over the Internet from certain parties.
Calling VSP
needs to find a path to the destination VSP.
can also be member of some (potentially different) VoIP peering fabrics.
Trial and Error during call-setup is not a good idea.
Thus he needs to discover which peering fabrics they share.
How does the calling VSP do this?
2006/03/15
Domain Policy DDDS

7. Proposed Solution Destination VSP publishes his reachability
List of his federation memberships
Other ways of reaching him
Calling VSPs
Fetches this policy set
Compares this to his own membership list
Protocol
DDDS Application to map domains to policy sets.
2006/03/15
Domain Policy DDDS

8. Big picture Dialstring normalization
E.164 based dialing starts here
Dialstring normalization
Destination URI Discovery (I-ENUM)
Destination URI Policy Discovery
Path (fabric) selection
Call setup over discovered path
Call admission …
URI based dialing starts here
2006/03/15
Domain Policy DDDS

9. Federations
A Federation is a group of VoIP service providers / enterprises which
agree to receive calls from each other via SIP
agree on a set of administrative rules for such calls (settlement, abuse-handling, ...), and
agree on specific rules for the technical details of the interconnection.
Federations have a unique identifier
2006/03/15
Domain Policy DDDS

10. Federation examples TLS based Private Network
Public Internet, SIP over TLS, Federation acts as X.509 Certification Authority.
Private Network
Federation builds its own network (the GRX case), members connect directly over this network.
SIP Hubs / Transit networks
Calls are routed via a central SIP proxy
2006/03/15
Domain Policy DDDS

11. Domain Policy DDDS basics
The domain is the key to the destination policy
Use the DNS as rule store
No special translation rules necessary
Infrastructure is in place
Example:
example.com. IN NAPTR "U" "D2P+SIP:fed" "!^.*$! .
“Regarding SIP, example.com is a member of the federation identified by this URI.”
Non-terminal NAPTR for customer domains referring to provider domains
Protocol agnostic
SIP is just a special case
2006/03/15
Domain Policy DDDS

12. Policy Rule Elements A NAPTR record contains a single policy rule
Examples
A federation membership
draft-lendl-speermint-federations-00
A technical restriction
e.g. a specific anti-SPIT rule
examples in draft-lendl-sip-peering-policy-00
A reference to an external policy document
e.g. SAML or XACML
2006/03/15
Domain Policy DDDS

13. Complex Rule Sets A NAPTR RRSet defines the policy of a domain.
“order” and “preference” define a Boolean expression of individual policy rules.
Example:
$ORIGIN example.com.
; order pref flags service regexp replacement
(1) IN NAPTR "U" "D2P+SIP:fed" "!^.*$! .
(2) IN NAPTR "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:2246!" .
(3) IN NAPTR "U" "D2P+SIP:std" "!^.*$!urn:ietf:rfc:3711!" .
(1) OR ( (2) AND (3) )
RFC2246: TLS
RFC3711: srtp
2006/03/15
Domain Policy DDDS

14. Summary draft-lendl-domain-policy-ddds-00 solves: Out of scope:
Policy announcement (“I am member of federations X and Y”)
Policy discovery (“I’ll reach the destination through federation Y”)
Enables ad-hoc peering under clearly defined rules
One step towards satisfying the requirements of draft-ietf- speermint-reqs-and-terminology-01
Out of scope:
Peering rules within federations
It’s not about how to peer, but how to select which peering method/fabric to use.
2006/03/15
Domain Policy DDDS