[Dime] Re: [Tsvwg] Re: [Sip] Re: Draft Liaison response to SG13 on Emergency Telecommunications

[Magnus Westerlund <[e-mail]>]

Hi again,

I have received some more comments. So here is an updated version adding 
DIME documents and correcting origin of documents.


Submission
Date:		<tbd>, 2007

From: 		IETF Working groups TSVWG, NSIS, DIME, SIP and SIPPING

To:		Georges Sebek  <[e-mail]> ,
		Keith Knightson <[e-mail]>

Cc:		Magnus Westerlund <[e-mail]>,
Lars Eggert <[e-mail]>,
James Polk <[e-mail]>,
Martin Stiemerling <[e-mail]>,
John Loughney <[e-mail]>
Dean Willis <[e-mail]>,
Keith Drage <[e-mail]>,
Mary Barnes <[e-mail]>,
Gonzalo Camarillo <[e-mail]>,
Scott Bradner <[e-mail]>,
Kimberly King <[e-mail]>,
Scott Brim <[e-mail]>,
Hannes Tschofenig <[e-mail]>,
David Frascone <[e-mail]>

Response
Contact:	TSV WG ([e-mail])
		NSIS ([e-mail])
		SIPPING ([e-mail])
		SIP ([e-mail])
		DIME ([e-mail])
		
Purpose: 	Response to Liaison Request

Deadline:	None

Title: Response to liaison request from ITU-T Study Group 13 work on 
emergency telecommunications

This is a response to the liaison request made by Q.3/13 regarding 
emergency telecommunications (REF: NGN-GSI/DOC – 60 Rev.2). We would 
first like to apologize for failing to meet the deadline in responding. 
We do hope that the late answer still can be of some use.

The liaison request was made to the following working groups (WG): 
IEPREP, TSVWG, and NSIS. Since the request was sent the IEPREP WG has 
concluded. In addition to the WGs from which information was requested, 
we also think that work performed by the DIME, SIP and SIPPING WG may be 
of relevance.

Pursuant to ITU-T Study Group 13 request for information on relevant and 
related work in the IETF regarding emergency communications, we list 
below RFCs and works in progress that we feel may be of interest to your 
group.  Some of the completed work is Informational, and others are in 
the category of Standards Track.

Q.3/13 also requested that we keep you informed of any developments in 
regards to emergency telecommunications. In those regards we would like 
to make you aware that IETF mailing list participation and document 
information is free and open to anyone, allowing participants in Q.3/13 
to keep themselves informed of any developments. If Q.3/13 desire to get 
further information about specific ongoing work, then please send a 
liaison request to the responsible WG for those specific documents.

The following list is divided under the associated working groups from 
which the work has been done within the IETF.


SIP Working Group

RFC 4412

Title:
    Communications Resource Priority for the Session Initiation
    Protocol (SIP)

Abstract:
    This document defines two new Session Initiation Protocol (SIP)
    header fields for communicating resource priority, namely,
    "Resource-Priority" and "Accept-Resource-Priority".  The
    "Resource-Priority" header field can influence the behavior of SIP
    user agents (such as telephone gateways and IP telephones) and SIP
    proxies.  It does not directly influence the forwarding behavior of
    IP routers.

	The below two documents are proposed work items accepted to become IETF 
WG items are likely of interest as they update RFC 4412.

Work In Progress:   draft-polk-sip-rph-in-responses-00

Title:
Allowing SIP Resource Priority Header in SIP Responses

Abstract:
    The Session Initiation Protocol (SIP) Resource Priority Header
    (RPH), in its current form, is ignored in SIP responses.  This was a
    design choice during RFC 4412's development. This is now considered
    a bad design choice in certain scenarios.  This document corrects
    RFC 4412's communications model by optionally allowing a SIP server
    or user agent client to process the Resource-Priority Header in a
    response.

Work In Progress:   draft-polk-sip-rph-new-namespaces--00

Title:
New Session Initiation Protocol Resource-Priority Header Namespaces for 
the Defense Information Systems Agency

Abstract:
    This document creates additional Session Initiation Protocol
    Resource-Priority header namespaces, to be IANA registered.  This
    document intends to update RFC 4412, as a Proposed Standard document
    if published by the RFC-Editor.



SIPPING Working Group

RFC 4411

Title:
    Extending the Session Initiation Protocol (SIP)
    Reason Header for Preemption Events

Abstract:
   This document proposes an IANA Registration extension to the Session
    Initiation Protocol (SIP) Reason Header to be included in a BYE
    Method Request as a result of a session preemption event, either at a
    user agent (UA), or somewhere in the network involving a
    reservation-based protocol such as the Resource ReSerVation Protocol
    (RSVP) or Next Steps in Signaling (NSIS).  This document does not
    attempt to address routers failing in the packet path; instead, it
    addresses a deliberate tear down of a flow between UAs, and informs
    the terminated UA(s) with an indication of what occurred.

IEPREP Working Group

RFC 3487

Title:
    Requirements for Resource Priority Mechanisms for the
    Session Initiation Protocol (SIP)

Abstract:
    This document summarizes requirements for prioritizing access to
    circuit-switched network, end system and proxy resources for
    emergency preparedness communications using the Session Initiation
    Protocol (SIP).

RFC 3689

Title:
    General Requirements for
    Emergency Telecommunication Service (ETS)

Abstract:
    This document presents a list of general requirements in support of
    Emergency Telecommunications Service (ETS).  Solutions to these
    requirements are not presented in this document.  Additional
    requirements pertaining to specific applications, or types of
    applications, are to be specified in separate document(s).

RFC 3690

Title:
    IP Telephony Requirements for
    Emergency Telecommunication Service (ETS)

Abstract:
    This document presents a list of requirements in support of Emergency
    Telecommunications Service (ETS) within the context of IP telephony.
    It is an extension to the general requirements presented in RFC 3689.
    Solutions to these requirements are not presented in this document.

RFC 4190

Title:
    Framework for Supporting Emergency Telecommunications
    Service (ETS) in IP Telephony

Abstract:
    This document presents a framework for supporting authorized,
    emergency-related communication within the context of IP telephony.
    We present a series of objectives that reflect a general view of how
    authorized emergency service, in line with the Emergency
    Telecommunications Service (ETS), should be realized within today's
    IP architecture and service models.  From these objectives, we
    present a corresponding set of protocols and capabilities, which
    provide a more specific set of recommendations regarding existing
    IETF protocols.  Finally, we present two scenarios that act as
    guiding models for the objectives and functions listed in this
    document.  These models, coupled with an example of an existing
    service in the Public Switched Telephone Network (PSTN), contribute
    to a constrained solution space.

RFC 4375

Title:
    Emergency Telecommunications Services (ETS) Requirements
    for a Single Administrative Domain

Abstract:
    This document presents a list of requirements in support of Emergency
    Telecommunications Service (ETS) within a single administrative
    domain.  This document focuses on a specific set of administrative
    constraints and scope.  Solutions to these requirements are not
    presented in this document.


TSV Working Group

RFC 4542

Title:
    Implementing an Emergency Telecommunications Service (ETS)
    for Real-Time Services in the Internet Protocol Suite

Abstract:
    RFCs 3689 and 3690 detail requirements for an Emergency
    Telecommunications Service (ETS), of which an Internet Emergency
    Preparedness Service (IEPS) would be a part.  Some of these types of
    services require call preemption; others require call queuing or
    other mechanisms.  IEPS requires a Call Admission Control (CAC)
    procedure and a Per Hop Behavior (PHB) for the data that meet the
    needs of this architecture.  Such a CAC procedure and PHB is
    appropriate to any service that might use H.323 or SIP to set up
    real-time sessions.  The key requirement is to guarantee an elevated
    probability of call completion to an authorized user in time of
    crisis.

    This document primarily discusses supporting ETS in the context of
    the US Government and NATO, because it focuses on the Multi-Level
    Precedence and Preemption (MLPP) and Government Emergency
    Telecommunication Service (GETS) standards.  The architectures
    described here are applicable beyond these organizations.

Work In Progress:   draft-ietf-tsvwg-emergency-rsvp-03.txt

Title:
    Resource ReSerVation Protovol (RSVP) Extensions for
    Emergency Services

Abstract:
    An Emergency Telecommunications Service (ETS) requires the ability to
    provide an elevated probability of session establishment to an
    authorized user in times of network congestion (typically, during a
    crisis). When supported over the Internet Protocol suite, this may be
    facilitated through a network layer admission control solution, which
    supports prioritized access to resources (e.g., bandwidth). These
    resources may be explicitly set aside for emergency services, or they
    may be shared with other sessions.

   This document specifies RSVP extensions that can be used to support
    such an admission priority capability at the network layer. Note that
    these extensions represent one possible solution component in
    satisfying ETS requirements. Other solution components, or other
    solutions, are outside the scope of this document.

NSIS Working Group

Work In Progress: draft-ietf-nsis-qos-nslp-14.txt

Title:
NSLP for Quality-of-Service Signaling

Abstract:
This specification describes the NSIS Signaling Layer Protocol (NSLP) 
for signaling QoS reservations in the Internet.  It is in accordance 
with the framework and requirements developed in NSIS.  Together with 
GIST, it provides functionality similar to RSVP and extends it.  The QoS 
NSLP is independent of the underlying QoS specification or architecture 
and provides support for different reservation models. It is simplified 
by the elimination of support for multicast flows. This specification 
explains the overall protocol approach, design decisions made and 
provides examples.  It specifies object, message  formats and processing 
rules.

DIME Working Group

Work In Progress: draft-ietf-dime-diameter-qos-01.txt

Title:
   Diameter Quality of Service Application

Abstract:
   This document describes a Diameter application that performs
   Authentication, Authorization, and Accounting for Quality of Service
   (QoS) reservations.  This protocol is used by elements along the path
   of a given application flow to authenticate a reservation request,
   ensure that the reservation is authorized, and to account for
   resources consumed during the lifetime of the application flow.
   Clients that implement the Diameter QoS application contact an
   authorizing entity/application server that is located somewhere in
   the network, allowing for a wide variety of flexible deployment
   models.

Work In Progress: draft-ietf-dime-qos-parameters-00.txt

Title:
   Quality of Service Parameters for Usage with the AAA Framework

Abstract:
   This document defines a number of Quality of Service (QoS) parameters
   that can be reused for conveying QoS information within RADIUS and
   Diameter.

   The payloads used to carry these QoS parameters are opaque for the
   AAA client and the AAA server itself and interpreted by the
   respective Resource Management Function.

Work In Progress: draft-ietf-dime-qos-attributes-01.txt

Title:
   Quality of Service Attributes for Diameter and RADIUS

Abstract:
   This document extends the functionality of the Diameter Base protocol
   and other Diameter applications with respect to their ability to
   convey Quality of Service information.  The AVPs defined in this
   document are also available for Remote Authentication Dial In User
   Service (RADIUS).


Non-WG Documents

	Approved for publication: draft-carlberg-trip-attribute-rp-02.txt

	Title:
	  TRIP Attribute for Resource Priority
	
Abstract:
    This document defines a new attribute for  the  TRIP  protocol.   The
    attribute   associates   protocols/services   in  the  PSTN  offering
    authorized  prioritization  during  call  setup  that  are  reachable
    through  a TRIP gateway.  Current examples of preferential service in
    the PSTN are Government Emergency Telecommunications  Service  (GETS)
    in  the U.S. and Government Telephone Preference Scheme (GTPS) in the
    U.K.  The proposed attribute for TRIP is based on the NameSpace.Value
    tupple defined for the SIP resource Priority field.




Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

_______________________________________________
DiME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dime