[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03                                                   
Session PEERing for Multimedia                               M. Haberler
INTerconnect                                                         IPA
Internet-Draft                                                 M. Hammer
Expires: December 28, 2006                                         Cisco
                                                                O. Lendl
                                                                 enum.at
                                                           June 26, 2006


              A Federation based VoIP Peering Architecture
                  draft-lendl-speermint-federations-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines the federation concept and proposes a peering
   and routing architecture for SIP-based applications.  Federations can
   be used to establish selective peerings e.g. in the Voice over IP and
   Instant Messaging space.  Service providers may announce federation
   membership as domain attributes.  This documents contains the policy-



Haberler, et al.        Expires December 28, 2006               [Page 1]


Internet-Draft         The Federation Policy-Type              June 2006


   type definition for federations within the Domain Policy DDDS
   Application.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  Federations  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   4.  Federation based Routing . . . . . . . . . . . . . . . . . . .  4
     4.1   Assumptions  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2   Call Flows . . . . . . . . . . . . . . . . . . . . . . . .  5
       4.2.1   Direct Intra-federation calls  . . . . . . . . . . . .  5
       4.2.2   Single-transit Inter-federation calls  . . . . . . . .  6
       4.2.3   Multiple-Transit calls . . . . . . . . . . . . . . . .  6
     4.3   Procedures . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.4   Routing Architecture . . . . . . . . . . . . . . . . . . .  6
       4.4.1   Static configuration . . . . . . . . . . . . . . . . .  7
       4.4.2   Web based  . . . . . . . . . . . . . . . . . . . . . .  7
       4.4.3   Route Announcements  . . . . . . . . . . . . . . . . .  7

   5.  Policy-Type template . . . . . . . . . . . . . . . . . . . . .  8

   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9

   10.   References . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1  Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2  Informative References . . . . . . . . . . . . . . . . . .  9

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10

       Intellectual Property and Copyright Statements . . . . . . . . 11











Haberler, et al.        Expires December 28, 2006               [Page 2]


Internet-Draft         The Federation Policy-Type              June 2006


1.  Terminology

   This document uses the terminology as defined in
   draft-ietf-speermint-terminology-00 [1].

   The acronym VSP will stand for "VoIP Service Provider".

   Our definition of VSP encompasses  commercial service providers as
   well as enterprises and end user operating their own SIP [4] proxy.

2.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [3].

   The domain policy DDDS application [2] defines a generic method how a
   domain owner may announce the conditions to accept incoming
   communications.  This documents defines the policy-type for
   publishing federation membership.

   This document focuses on the use of federations for SIP peering.  The
   same mechanism may be applied to other application protocols as well,
   as described by the protocol field of the service parameter in the
   NAPTR records.

3.  Federations

   The proposed method is based upon the concept of a "Federation".  A
   federation is defined as follows:

      A Federation is a group of VoIP service providers which
      *  agree to accept calls from each other via SIP,
      *  agree on a set of administrative rules for these calls
         (settlement, abuse-handling, ...), and
      *  agree on rules for the technical details of the
         interconnection.

   The actual rules are private to the federation and need not be
   published.  Federation members are expected to know and abide by
   these rules.

   Federations are identified by URIs.  It is RECOMMENDED that
   federations use URLs as identifiers which point to documents
   describing the federation.

   For the purposes of the domain policy DDDS application, federation
   identifiers are opaque strings.  The only operations performed on



Haberler, et al.        Expires December 28, 2006               [Page 3]


Internet-Draft         The Federation Policy-Type              June 2006


   these identifiers are string comparisons.  If the identifier is in
   the form of an URL, the document referred to by that URL is never
   evaluated during the basic peer discovery process.

   The federation named "urn:ietf:rfc:3261" stands for the public
   Internet.  A SIP service provider who announces his membership in
   "urn:ietf:rfc:3261" will accept calls as defined in the generic SIP
   RFC [4].

   Examples:

   o  A group of VoIP service providers forms an association and agrees
      to accept calls from each other via the public Internet provided
      the TLS transport is used for SIP signalling and members present a
      valid X.509 cert signed by the association's certificate
      authority.
   o  A group of VoIP service providers build a Layer 3 network for VoIP
      peering ("walled garden", e.g. similar to the 3GPP GRX network).
      They agree to accept calls from all participants in that network
      and settle through a clearinghouse.
   o  A group of VoIP service providers agree to accept calls
      originating from within the same country.  They use firewall rules
      to block calls from abroad.
   o  Peering fabric based on SIP: A SIP hub acts as a forwarding proxy
      between participants.  Intra-federation calls are to be routed
      through the SIP hub.
   o  Peer to Peer SIP clouds: P2P SIP proposes an alternative
      resolution method.  The members of each such DHT can be seen as a
      federation where the technical rule stipulate the participation in
      a specific DHT ring.

4.  Federation based Routing

   This section outlines how the federations concept relates to the
   Speermint routing architecture.

4.1  Assumptions

   Many VSPs will prefer not to run open SIP proxies and accept calls
   from the public Internet.

   Some VSPs will establish private peerings between each other.

   Groups of VSPs will enter into mutual peering agreements.  In other
   cases, third parties might build such peering fabrics as a service.

   Both private peerings and such peering fabrics are federations as
   defined by this document.



Haberler, et al.        Expires December 28, 2006               [Page 4]


Internet-Draft         The Federation Policy-Type              June 2006


   VSPs might choose to join several federations if it suits their
   business strategy.  This set of federations defines the range of
   destination VSPs reachable with a direct SIP connection.

   VSPs which are members of multiple federations may choose to provide
   transit services to other VSPs.  Such "transit VSPs" act as bridges
   between federations.


4.2  Call Flows

   To visualize the possible call flows we use the following set of VSPs
   and federations:

                    +-----+
                   /  FED  \
                   \   1   /
                    +-----+
                   /   |   \
                  /    |    \
                 /     |     \
             +---+   +---+   +---+
             | A |   | B |   | C | Transit VSP
             +---+   +---+   +---+
                \     / \      /
                 \   /   \    /
                 +---+    +---+
                / FED \  / FED \
                \  2  /  \  3  /
                 +---+    +---+
                 /   \   /    \
                /     \ /      \
             +---+   +---+   +---+
             | X |   | Y |   | Z | Non-Transit VSP
             +---+   +---+   +---+

   X, Y, and Z are terminating VSPs which serve as SIP providers for
   end-customers.  A, B, and C are VSPs offering transit into a
   federation to members of other federations.

4.2.1  Direct Intra-federation calls

   Calls from customers of X to customers of Y can be passed directly
   according to rules of federation 2.  Transit is not required.

   Details how X passes traffic to Y are internal to federation 2 - it
   could be end-to-end or, for example, through a SIP hub.




Haberler, et al.        Expires December 28, 2006               [Page 5]


Internet-Draft         The Federation Policy-Type              June 2006


4.2.2  Single-transit Inter-federation calls

   Calls from X to Z need to traverse a transit VSP as X and Z do not
   share a common federation.  B shares federations with X and Z, thus
   it can bridge calls between X and Z. VSP X thus may elect to enlist
   the help of B to complete calls to Z.

   On a high level this call is the combination of two intra-federation
   call legs - one within FED2 from X to B, and one within FED3 from B
   to Z. If FED2 and FED3 share the same Layer 3 network, then the RTP
   stream may well be end to end (X to Z directly).  If not (e.g.  FED3
   employs a private network), then B needs to provide media relay
   service as well.

4.2.3  Multiple-Transit calls

   If B is not available, calls from X to Z need to traverse via FED2 to
   A, then via FED1 to C, and finally via FED3 to Z. Now there are three
   legs in the call.

4.3  Procedures

   The basic call flow is as follows (this is an extension to
   draft-mahy-speermint-direct-peering):

   1.  If number-based dialing is used, then the initiating VSP converts
       the dial-string to a fully qualified E.164 number and retrieves a
       SIP URI through User ENUM and/or Infrastructure ENUM.

   2.  The initiating VSP performs the Domain  Policy DDDS Application
       [2] and thus retrieves the set of federation of the target VSP.
       If source and destination VSP share a federation then the call is
       established according to its rules.

   3.  If no common federation is found, the initiating VSP may choose
       to enlist the help of a transit VSP.  The call to the transit VSP
       follows normal federation rules.  See the next section for
       details how a suitable transit VSP is selected.

   4.  For number-based dialing: if no path can be found through either
       a common federation or any transit VSP, then the originating VSP
       may fall back to PSTN delivery.  Thus, the PSTN may be viewed as
       just another "default" federation where all VSPs using E.164
       numbers and having PSTN connectivity are members.

4.4  Routing Architecture

   For the direct intra-federation call, it is sufficient to match the



Haberler, et al.        Expires December 28, 2006               [Page 6]


Internet-Draft         The Federation Policy-Type              June 2006


   federation memberships of the initiating and destination VSP.  This
   matching can be achieved through the domain policy DDDS application.
   While direct matching of federations enables direct peering, it does
   not solve the universal reachability problem.

   In the general case, a routing algorithm is needed: Once the source
   VSP does not share a common federation with the destination VSP the
   source VSP needs select a transit VSPs.  This transit VSP in turn
   needs to make a routing decision.

   The "next hop" selection is thus similar to other routing problems,
   thus the similar  approaches can be used.  In some way, topology
   information beyond the next hop needs to be communicated between
   VSPs.  Other than in IP (layer 3) routing, announcements need not
   exclusively be learned from adjacent nodes and can be published
   through other means since IP connectivity can be assumed.

   This document does not propose a routing protocol.  The following
   options are intended to stimulate discussions in the SPEERMINT
   working-group.

4.4.1  Static configuration

   For non-transit VSPs this is simple choice: everything that cannot be
   handed of to the destination network directly is relayed to a default
   transit provider.

4.4.2  Web based

   The mapping from destination domain to federation IDs is done by the
   Domain Policy DDDS.  If the federation URL points to a document (or a
   web-service) then the source VSP can retrieve further information
   about the destination's federation.

   Such information could identify transit VPSs serving that federation,
   and distinguished from VSPs that simply belong to the federation.
   Re-applying the Domain Policy DDDS leads to path discovery between
   source and destination VSP.

4.4.3  Route Announcements

   SIP messages between federation members could be used to distribute
   reachability information.  To use the above example:

   If  X buys transit from B then X might subscribe to a "topology"
   event package with B. Using NOTIFIES B may announce to X its
   reachable federations.




Haberler, et al.        Expires December 28, 2006               [Page 7]


Internet-Draft         The Federation Policy-Type              June 2006


   The same mechanisms can be used amongst transit VSPs (e.g. in
   federation 1) to exchange reachability information.  VSP A could
   learn through a NOTIFY from C that C is a member of FED3.


5.  Policy-Type template


      Policy Type: "fed"

      URI Scheme(s): Any URI is allowed.

      Functional Specification: The URI acts purely as an identifier
           of a federation.  If both the sender and the destination
           are members of the same federation then they can communicate
           using this federation's rules.

      Security considerations:

      Intended usage: COMMON

      Author: Otmar Lendl



6.  Examples

   The examples show the NAPTR records for some the VSPs from the
   diagram from section 4.2.  The VSPs shall use domains like vsp-
   X.example.com and federations use identifiers like
   "http://fed-1.example.org/".

   o  VSP X is only reachable through FED2, thus:

      $ORIGIN vsp-X.example.com
      @ IN NAPTR 10 50   "U"  "D2P+SIP:fed" (
                 "!^.*$!http://fed-2.example.org/!" . )


   o  VSP C is a member of both FED1 and FED3, thus:

      $ORIGIN vsp-C.example.com
      @ IN NAPTR 10 10   "U" "D2P+SIP:fed" (
                 "!^.*$!http://fed-1.example.org/!" . )
      @ IN NAPTR 20 10   "U" "D2P+SIP:fed" (
                 "!^.*$!http://fed-3.example.org/!" . )





Haberler, et al.        Expires December 28, 2006               [Page 8]


Internet-Draft         The Federation Policy-Type              June 2006


   o  The lower order value indicate that C prefers to receive calls via
      FED1.  B, who is also a member of FED1 and FED3, can choose to
      honor that preference and use FED1 when contacting C.

7.  Security Considerations

   The publishing of the access policy via the DNS RR described in this
   draft will reduce the amount of unwanted communication attempts, as
   all well-meaning clients will follow them, but these records cannot
   substitute measures to actually enforce the published policy.

8.  IANA Considerations

   This document registers the policy-type "fed" for the domain policy
   DDDS application.

9.  Acknowledgements

   The author would like to thank Alexander Mayrhofer, Henry Sinnreich,
   Eli Katz, Reinaldo Penno, Patrick Melampy, Daryl Malas and Richard
   Stastny for their contributions.

10.  References

10.1  Normative References

   [1]  Meyer, D., "SPEERMINT Terminology",
        draft-ietf-speermint-terminology-00 (work in progress),
        May 2006.

   [2]  Lendl, O., "The Domain Policy DDDS Application",
        draft-lendl-domain-policy-ddds-00 (work in progress),
        February 2006.

10.2  Informative References

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.









Haberler, et al.        Expires December 28, 2006               [Page 9]


Internet-Draft         The Federation Policy-Type              June 2006


Authors' Addresses

   Michael Haberler
   Internet Foundation Austria
   Waehringerstrasse 3/19
   Wien  A-1090
   Austria

   Phone: +43 664 4213465
   Email: mah@inode.at
   URI:   http://www.nic.at/ipa/


   Mike Hammer
   Cisco Systems
   13615 Dulles Technology Drive
   Herndon  VA 20171
   USA

   Phone: +1-703-484-3069
   Email: mhammer@cisco.com


   Otmar Lendl
   enum.at GmbH
   Karlsplatz 1/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 33
   Email: otmar.lendl@enum.at
   URI:   http://www.enum.at/



















Haberler, et al.        Expires December 28, 2006              [Page 10]


Internet-Draft         The Federation Policy-Type              June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Haberler, et al.        Expires December 28, 2006              [Page 11]