[secdir] [New-work] WG Review: Multiple AoR reachabiliTy InformatioN Indication (MARTINI)

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, December 15, 2009.

Multiple AoR reachabiliTy InformatioN Indication (MARTINI)
-----------------------------------------------------------------------
Current Status: Proposed Working Group
Last Modified: 2009-12-08

Chair(s):
TBD

Real-time Applications and Infrastructure Area Director(s):
Robert Sparks <rjsparks@nostrum.com>
Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
Cullen Jennings <fluffy@cisco.com>

Technical Advisor(s):

Mailing Lists:
General Discussion: martini@ietf.org
To Subscribe: martini-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/martini/index.html

Description of Working Group

The MARTINI working group is chartered to specify a means by which an
entity that is authoritative for SIP URIs can dynamically register
reachability information for multiple Addresses of Record ("AORs") with a
service provider.

The SIP protocol [RFC 3261 and its extensions] supports multiple means of
obtaining the connection information necessary to deliver out-of-dialog
SIP requests to their intended targets. When a SIP Proxy needs to send a
request to a target AOR within its domain, it can use a location service
to obtain the registered contact URI, together with any associated path
information [RFC 3327], and build a route set to reach the target UA(s).
The SIP REGISTER method can be used to register contact URIs and path
information. SIP-outbound [RFC 5626] enhances this mechanism to cater for
UAs behind NATs and firewalls. When a SIP UA or Proxy needs to send a
request to a target for which it is not authoritative, the UA/Proxy can
use RFC3263 procedures for using DNS to resolve the next-hop connection
information.

In practice, many small and medium-sized businesses use a SIP-PBX that is
authoritative for tens or hundreds of SIP AoRs. This SIP-PBX acts as a
registrar/proxy for these AoRs for clients hosted by the SIP-PBX. UAs
register with the SIP-PBX on behalf of the AoRs concerned. A SIP Service
Provider (SSP) provides SIP peering/trunking capability to the SIP PBX.
The SIP-PBX must be reachable from the SSP so that the SSP can route
inbound SIP requests for the AoRs addressed to the SIP PBX, routing these
requests to the SIP-PBX itself for onward delivery to registered UAs.

Experience has shown that existing mechanisms are not always sufficient
to support SIP-PBXs for small/medium businesses. Since a single SSP may
support multiple thousands of such SMB SIP-PBX's, it is impractical and
cost-prohibitive to manually provision their IP addresses in every SIP
node along paths to those SIP-PBXs. Furthermore, IP addresses can be
dynamically assigned and therefore can potentially change relatively
frequently.

In current deployments, dynamic reachability mechanisms based on the SIP
REGISTER method are commonly used. Effectively, a single REGISTER request
registers the AoR of the SIP-PBX, so that any out-of-dialog request
targeted at a SIP URI for which the SIP-PBX is authoritative can be
delivered from the SSP to the SIP-PBX. However, implementations of this
mechanism vary in details, leading to interoperability issues between
SIP-PBXs and SSPs, and the need for equipment to support different
variants.

The task of this working group is to to standardize a multiple-AoR
registration mechanism for SIP that can be widely deployed by service
providers at large scale. The solution will support AoRs with E.164
addresses at a minimum, although support for other classes of AoRs may be
included.

The solution will utilize existing SIP mechanisms to the extent possible,
although it is anticipated that small protocol extensions are likely to be
required, and hence a standards track (rather than BCP) deliverable is
expected. The solution will accommodate existing SIP extensions relating
to registration (e.g., Path, Service-Route [RFC 3608] and SIP-outbound) by
ensuring that they are not precluded from use in the context of multiple
AoR registrations. The solution will incorporate a compatibility mechanism
to ensure a deterministic outcome when interworking with entities that do
not support multiple AoR registration.

The working group will coordinate with SIP Forum and other industry
groups on requirements and will coordinate its work with other IETF
working groups including DRINKS and SIPCORE.

Goals and Milestones
Dec 2009 Solicit solution-space drafts
Jan 2010 Interim meeting
Jan 2010 Adopt Working Group draft
Feb 2010 First Working Group Last Call
Mar 2010 Second Working Group Last Call
Apr 2010 Multiple AoR Registration specification to IESG (PS)
Jul 2010 Close or recharter working group
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir