Peppermint BoF A Provisioning Protocol for ENUM-SIP Addressing Servers

1
Peppermint BoFA Provisioning Protocol for
ENUM-SIP Addressing Servers

• draft-mule-peppermint-espp-protocol-01
• IETF 71 - Wednesday March 12 2008
• Presented by Sean Kent - skent_at_verisign.com
• Authors
• Ken Cartwright - kcartwright_at_verisign.com
• Stephen Dimig - Stephen.Dimig_at_tekelec.com
• Mark Teodoro - mark.teodoro_at_neustar.com
• Jean-François Mulé - jfm_at_cablelabs.com

2
Agenda

• Guiding Design Principals
• Logical Structure - Data Model
• General Protocol Concepts

3
Guiding Design Principals

• Simultaneously receive data from various
  sources/clients
• Internal back-office systems, External peers
  and/or federation registries
• Support large addressing space
• Same order of magnitude as Public Switched
  Telephone Network (PSTN)
• Optimize bandwidth and storage requirements
• Minimize affects of ongoing operations. For
  example modification to serving equipment
  attributes reduced to single distribution
  operation, rather than millions of public
  identity records with embedded service data.
• Macro data operations, add/delete all or large
  quantities of data thru one/fewest operations
• "Document Literal Wrapped" style of designing
  SOAP based APIs
• Web services integration with back-office systems
• Enhances maintainability, comprehension,
  portability, and, to a certain extent,
  performance.
• Operationally friendly
• Route descriptors, e.g. Location Routing Number
  (LRN)

4
Logical Structure - Data Model

• Allows for more natural modeling of relationships
  between entities that comprise the logical
  topology.
• Telephone numbers and other types of public user
  identities grouped in logical or geographical
  areas (Service Areas).
• Associated with routes describing how traffic
  traverses nodes of topology.
• Enterprise ID, IANA Private Enterprise Number,
  used to scope/create view on the peering
  enterprises SIP-ENUM Server
• Indirect linkage, Routes linked to Service Areas
  establish link between set of public identities
  and serving equipment (NAPTR), significantly
  improves the scalability and manageability of
  data.

5
Logical Structure - Data Model

• Allow for communication of subscriber-specific
  attributes
• Direct association between NAPTR and Public User
  Identifier (PUI)
• Add Public User Identity (PUI)
• Optional direct association with one or more
  NAPTRs, more data distribution intensive, permits
  subscriber-specific service attributes. E.g.
  subscribers name or other personalization.
• Optional association with a private identity
  provides ability to create "related" set of
  public identities.

6
General Protocol Concepts

• Real-time Provisioning Operations
• Low volume data distribution
• For example capacity expansions (adding an SBE
  to existing inter-connection) and day-to-day
  repetitive task of adding/deleting subscribers
• Real-time operations atomic, all aspects fail or
  all succeed.
• File-based Provisioning Operations
• High volume data distribution
• For example sunrise/bootstrapping and large
  registry operations such as the initial peering
  between two large address spaces.
• Protocol compliant batched operations
• Usage is policy driven, out of scope of protocol
  definition
• Additionally, process of retrieving file and
  delivering file to proper location is a matter of
  policy and procedure outside scope of protocol
  definition.

7
Thank You.QA
8
Technical Structure - SOAP/XML

• "Document Literal Wrapped" style of designing
  SOAP based APIs
• Enhances maintainability, comprehension,
  portability, and, to a certain extent,
  performance.
• Implicit extensibility supported thru XSD and
  WSDL definitions, extended without breaking
  backward compatibility.
• Explicit extensibility, each object type contains
  an additional attribute called "ext", which is of
  type ExtAnyType
• Key SOAP operations supported by ESPP
• Add Enterprise, NAPTR, Route, Service Area, Pubic
  Identities, Location Routing Numbers, TN Range
• Also optional Private Identity associating Public
  Identities
• Equivalent Delete, Get operations as well as
  batching of operations
• Get services operation determine operations and
  protocol versions supported by server.

9
Real-time Provisioning Operations

• Basic Request/Query Object
• client ID, a transaction ID, minor version of
  protocol,
• no transaction ID necessary for query operations
• Authentication
• HTTP Digest based authentication
• Transaction ID
• Synchronization out of order, retries,
  roll-back
• Maintained in persistent storage
• Sent with each update request
• Incremented once all database changes have been
  synchronized to persistent storage
• Basic Response Object
• Response code (int) and human readable message
  (string)
• Real-time operations atomic, all aspects fail or
  all succeed.
• Object ID and Enterprise ID
• uniquely identifies object instance within an
  ESPP Server

10
Key Aspects of Protocol Operations

• Add Route
• Indirect linkage, Routes linked to Service Areas
  establish link between set of public identities
  and serving equipment, significantly improves the
  scalability and manageability of data.
• Modification to serving equipment attributes
  reduced to single distribution operation, rather
  than millions of public identity records with
  embedded service data.
• Toggle-able boolean value that sets the Route in
  service or out of service further reduces number
  of distribution operations. E.g. times of mtc
• Add Service Areas
• Limitation on maximum number of service areas
  policy decision and not limited by protocol.
• Add PUI
• Optional association with a private identity
  provides ability to create "related" set of
  public identities.
• Optional direct association with one or more
  NAPTRs, more data distribution intensive, permits
  subscriber-specific service attributes. E.g.
  subscribers name or other personalization.

11
File-based Provisioning Operations

• High volume data distribution
• For example sunrise/bootstrapping and large
  registry operations such as the initial peering
  between two large address spaces.
• Usage is policy driven, out of scope of protocol
  definition
• Additionally, process of retrieving file and
  delivering file to proper location is a matter of
  policy and procedure outside scope of protocol
  definition.
• ESPP compliant batched operations
• File header specifies some basic information
  about where and when batch update file(s) were
  generated
• Nature of contained operations, e.g. is the file
  is for a full resync?
• In some instances it may be necessary to segment
  across two or more files.
• Use of Real-Time ESPP Transaction ID
• Insurers data consistency.
• Necessitates disablement of real-time propagation
  while the file-based provisioning process is
  active.