[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-drinks-spprov) 00 01 02 03 04 05 06 07 08 09 10 11 12 draft-ietf-drinks-spp-framework

DRINKS                                                         J-F. Mule
Internet-Draft                                                 CableLabs
Intended status: Standards Track                           K. Cartwright
Expires: January 13, 2012                                            TNS
                                                                  S. Ali
                                                                 NeuStar
                                                            A. Mayrhofer
                                                            enum.at GmbH
                                                           July 12, 2011


                 Session Peering Provisioning Protocol
                      draft-ietf-drinks-spprov-09

Abstract

   This document defines a protocol for provisioning session
   establishment data into Session Data Registries and SIP Service
   Provider data stores.  The provisioned data is typically used by
   various network elements for session peering.

   This document describes the Session Peering Provisioning Protocol
   used by clients to provision registries.  The document provides a set
   of guiding principles for the design of this protocol including
   extensibility and independent transport definitions, a basic data
   model and an XML Schema Document.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 13, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Mule, et al.            Expires January 13, 2012                [Page 1]


Internet-Draft             draft-drinks-spprov                 July 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Protocol High Level Design . . . . . . . . . . . . . . . . . .  9
     3.1.  Protocol Layering  . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Protocol Data Model  . . . . . . . . . . . . . . . . . . . 10
   4.  Transport Protocol Requirements  . . . . . . . . . . . . . . . 14
     4.1.  Connection Oriented  . . . . . . . . . . . . . . . . . . . 14
     4.2.  Request and Response Model . . . . . . . . . . . . . . . . 14
     4.3.  Connection Lifetime  . . . . . . . . . . . . . . . . . . . 14
     4.4.  Time value . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.5.  Authentication . . . . . . . . . . . . . . . . . . . . . . 15
     4.6.  Authorization  . . . . . . . . . . . . . . . . . . . . . . 15
     4.7.  Confidentiality and Integrity  . . . . . . . . . . . . . . 15
     4.8.  Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15
     4.9.  Request and Response Sizes . . . . . . . . . . . . . . . . 15
     4.10. Request and Response Correlation . . . . . . . . . . . . . 16
     4.11. Request Acknowledgement  . . . . . . . . . . . . . . . . . 16
     4.12. Mandatory Transport  . . . . . . . . . . . . . . . . . . . 16
   5.  Base Protocol Data Structures  . . . . . . . . . . . . . . . . 17
     5.1.  Request and Response Structures  . . . . . . . . . . . . . 17
       5.1.1.  Update Request and Response Structures . . . . . . . . 17
       5.1.2.  Query Request and Response Structures  . . . . . . . . 20
     5.2.  Response Codes and Messages  . . . . . . . . . . . . . . . 23
     5.3.  Basic Object Type and Organization Identifiers . . . . . . 25
   6.  Protocol Commands  . . . . . . . . . . . . . . . . . . . . . . 26
     6.1.  Add Destination Group Operation  . . . . . . . . . . . . . 26
     6.2.  Get Destination Groups Operation . . . . . . . . . . . . . 27
     6.3.  Add Public Identifier Operation  . . . . . . . . . . . . . 28
     6.4.  Get Public Identifiers Operation . . . . . . . . . . . . . 33
     6.5.  Add Route Group Operation  . . . . . . . . . . . . . . . . 33
     6.6.  Get Route Groups Operation . . . . . . . . . . . . . . . . 38
     6.7.  Add Route Record Operation . . . . . . . . . . . . . . . . 39
     6.8.  Get Route Records Operation  . . . . . . . . . . . . . . . 43
     6.9.  Add Route Group Offer Operation  . . . . . . . . . . . . . 44
     6.10. Accept Route Group Offer Operation . . . . . . . . . . . . 46



Mule, et al.            Expires January 13, 2012                [Page 2]


Internet-Draft             draft-drinks-spprov                 July 2011


     6.11. Reject Route Group Offer Operation . . . . . . . . . . . . 47
     6.12. Get Route Group Offers Operation . . . . . . . . . . . . . 48
     6.13. Egress Route Operations  . . . . . . . . . . . . . . . . . 50
     6.14. Delete Operation . . . . . . . . . . . . . . . . . . . . . 52
   7.  SPPP Examples  . . . . . . . . . . . . . . . . . . . . . . . . 54
     7.1.  Add Destination Group  . . . . . . . . . . . . . . . . . . 54
     7.2.  Add Route Records  . . . . . . . . . . . . . . . . . . . . 55
     7.3.  Add Route Records -- URIType . . . . . . . . . . . . . . . 56
     7.4.  Add Route Group  . . . . . . . . . . . . . . . . . . . . . 57
     7.5.  Add Public Identity -- Successful COR claim  . . . . . . . 58
     7.6.  Add LRN  . . . . . . . . . . . . . . . . . . . . . . . . . 60
     7.7.  Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 61
     7.8.  Add TN Prefix  . . . . . . . . . . . . . . . . . . . . . . 62
     7.9.  Enable Peering -- Route Group Offer  . . . . . . . . . . . 63
     7.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 64
     7.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 65
     7.12. Get Destination Group  . . . . . . . . . . . . . . . . . . 66
     7.13. Get Public Identity  . . . . . . . . . . . . . . . . . . . 67
     7.14. Get Route Group Request  . . . . . . . . . . . . . . . . . 68
     7.15. Get Route Group Offers Request . . . . . . . . . . . . . . 70
     7.16. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 71
     7.17. Delete Destination Group . . . . . . . . . . . . . . . . . 72
     7.18. Delete Public Identity . . . . . . . . . . . . . . . . . . 73
     7.19. Delete Route Group Request . . . . . . . . . . . . . . . . 74
     7.20. Delete Route Group Offers Request  . . . . . . . . . . . . 75
     7.21. Delete Egress Route  . . . . . . . . . . . . . . . . . . . 75
   8.  XML Considerations . . . . . . . . . . . . . . . . . . . . . . 77
     8.1.  Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 77
     8.2.  Versioning and Character Encoding  . . . . . . . . . . . . 77
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 78
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 79
   11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 80
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 93
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 94
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 94
     13.2. Informative References . . . . . . . . . . . . . . . . . . 94
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96














Mule, et al.            Expires January 13, 2012                [Page 3]


Internet-Draft             draft-drinks-spprov                 July 2011


1.  Introduction

   Service providers and enterprises use registries to make session
   routing decisions for Voice over IP, SMS and MMS traffic exchanges.
   This document is narrowly focused on the provisioning protocol for
   these registries.  This protocol prescribes a way for an entity to
   provision session-related data into a registry.  The data being
   provisioned can be optionally shared with other participating peering
   entities.  The requirements and use cases driving this protocol have
   been documented in [I-D.ietf-drinks-usecases-requirements].  The
   reader is expected to be familiar with the terminology defined in the
   previously mentioned document.

   Three types of provisioning flows have been described in the use case
   document: client to registry provisioning, registry to local data
   repository and registry to registry.  This document addresses client
   to registry aspect to fulfill the need to provision Session
   Establishment Data (SED).  The protocol that supports flow of
   messages to facilitate client to registry provisioning is referred to
   as Session Peering Provisioning Protocol (SPPP).

   Please note that the role of the "client" and the "server" only
   applies to the connection, and those roles are not related in any way
   to the type of entity that participates in a protocol exchange.  For
   example, a registry might also include a "client" when such a
   registry initiates a connection (for example, for data distribution
   to SSP).
























Mule, et al.            Expires January 13, 2012                [Page 4]


Internet-Draft             draft-drinks-spprov                 July 2011


    *--------*               *------------*               *------------*
    |        | (1). Client   |            | (3).Registry  |            |
    | Client | ------------> |  Registry  |<------------->|  Registry  |
    |        |   to Registry |            |  to Registry  |            |
    *--------*               *------------*               *------------*
                                  /  \                          \
                                 /    \                          \
                                /      \                          \
                               /        \                          v
                              /          \                         ...
                             /            \
                            / (2). Distrib \
                           / Registry data  \
                          /  to local data   \
                         V      store         V
                        +----------+       +----------+
                        |Local Data|       |Local Data|
                        |Repository|       |Repository|
                        +----------+       +----------+


                     Three Registry Provisioning Flows

                                 Figure 1

   The data provisioned for session establishment is typically used by
   various downstream SIP signaling systems to route a call to the next
   hop associated with the called domain.  These systems typically use a
   local data store ("Local Data Repository") as their source of session
   routing information.  More specifically, the SED data is the set of
   parameters that the outgoing signaling path border elements (SBEs)
   need to initiate the session.  See [RFC5486] for more details.

   A "terminating" SIP Service Provider (SSP) provisions SED into the
   registry to be selectively shared with other peer SSPs.
   Subsequently, a registry may distribute the provisioned data into
   local data repositories used for look-up queries (identifier -> URI)
   or for lookup and location resolution (identifier -> URI -> ingress
   SBE of terminating SSP).  In some cases, the registry may
   additionally offer a central query resolution service (not shown in
   the above figure).

   A key requirement for the SPPP protocol is to be able to accommodate
   two basic deployment scenarios:

   1.  A resolution system returns a Look-Up Function (LUF) that
       comprises of the target domain to assist in call routing (as
       described in [RFC5486]).  In this case, the querying entity may



Mule, et al.            Expires January 13, 2012                [Page 5]


Internet-Draft             draft-drinks-spprov                 July 2011


       use other means to perform the Location Routing Function (LRF)
       which in turn helps determine the actual location of