DRINKS%20Requirements%20Design%20Team%20Debrief

1
DRINKS Requirements Design Team Debrief

• IETF73, Minneapolis, MN.
• (Sumanth Channabasappa, on behalf of the design
  team.)

2
Introduction

• DRINKS requirements design team was formed at the
  last IETF
• Currently active participants Deborah Guyton,
  Gregory Schumacher, Jean-Francois Mule, Ken
  Cartwright, Manjul Maharishi, Penn Pfautz, Ray
  Bellis, Sumanth Channabasappa, WG Chairs (Richard
  Shockey, Alex Mayrhofer)
• The goal for this team is to specify the
  provisioning interface requirements to implement
  a registry for inter-Service Provider (SP)
  routing
• The requirements will not preclude intra-SP
  routing
• The design team started with use case proposals
  that identify the features and functionality for
  the provisioning interface
• The provisioning interface requirements will be
  distilled from the use cases

3
Status

• So far we have identified a bunch of candidate
  use cases
• We are in the process of finalizing the use
  cases for instance, we are aggregating and
  categorizing the use cases
• A snapshot of what we have is presented in
• http//tools.ietf.org/html/draft-channabasappa-dri
  nks-usecases-requirements-01
• This document is a work-in-progress we will
  normalize the terms (e.g., with SPEERMINT) and
  the content (e.g., use case descriptions) in
  future revisions

4
Overview

• Registry is the authoritative source for
  provisioned session establishment data (SED) and
  related information
• Local Data Repository is the data store component
  of an addressing server that provides resolution
  responses
• Registry is responsible for distributing SED and
  related information to the Local Data Repositories

Registry
1. Provision SED
2. Distribute SED
Local Data Repository
Local Data Repository
5
Existing Use Case Categories

• Provisioning data into a Registry
• Distribution of data into local data repositories
• Peering Relationships (Labeled LUF and LRF)
• SIP Service Provider
• Miscellaneous (i.e., use cases that are not
  categorized yet)
• Note We are in the process of re-categorizing as
  we finalize the use cases

6
Terminology (1/2)

• Public Identity
• A generic term that refers to a telephone number
  (TN), a range of TNs, an email address, or other
  identities as deemed appropriate, such as a
  globally routable URI of a user address (e.g.,
  mailtojohn.doe_at_example.net)
• Destination Group
• A set of global telephone numbers, TN ranges,
  dial codes, or other public identifiers that are
  grouped together to facilitate session setup and
  routing

7
Terminology (2/2)

• Data Recipient
• SP or SSP participating in the peering community
  for the purpose of provisioning or consuming SED
  related information.
• Data Recipient Group
• A group of Data Recipients that receive the same
  set (or subset) of SED related information.
• Routing Group
• A logical grouping of Resource Records A
  Destination Group may be associated with one or
  more Routing Groups based on its association with
  the Data Recipient Group.

8
Use CasesProvisioning Data into a Registry and
Local Data Repositories

• Provision public identities, destination groups,
  data recipient groups, and routing groups
• Specify an effective date time during the
  provisioning process
• Take a public identity out of service
• Assign a set of public identities to a different
  Destination Group, thereby changing their routing
• Move a Service Provider from one data recipient
  group to another

9
Use CasesPeering (LUF and LRF) and SSP

• Direct and Indirect Peering
• Small and Large SSPs

10
Use CasesMiscellaneous

• Massive Sunrise Provisioning
• Direct and Selective Peering
• Indirect Peering to Selected Destinations
• Peering Relationship Management
• Points of Egress
• Non-blocking transactions

11
Next Steps

• Finalize use cases - Dec/Jan
• Draft interface requirements - Jan/Feb
• Draft interface specification - IETF74