Telephony Routing over IP (TRIP) Attribute for Resource Priority
draft-carlberg-trip-attribute-rp-04

Internet Engineering Task Force                   Ken Carlberg
INTERNET DRAFT                                    G11
Nov 8, 2007                                       Piers O'Hanlon
                                                  UCL

    Telephony Routing over IP (TRIP) Attribute for Resource Priority
               <draft-carlberg-trip-attribute-rp-04.txt>

Status of this Memo

   By submitting this Internet-Draft, each author  represents  that  any
   applicable  patent  or  other  IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he  or  she  becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents  of  the  Internet  Engineering
   Task  Force  (IETF),  its  areas,  and its working groups.  Note that
   other groups May  also  distribute  working  documents  as  Internet-
   Drafts.

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

   The  list   of   current   Internet-Drafts   can   be   accessed   at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow  Directories  can  be  accessed  at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines a new attribute for the Telephony Routing  over
   IP  (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.

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 1]

Internet Drafts       Resource Priority Attribute       November 8, 2007

1.  Introduction

   An IP telephony gateway allows  nodes  on  an  IP  based  network  to
   communicate  with  other  entities  on the circuit switched telephone
   network.  The Telephony Routing over  IP  (TRIP)  protocol  [rfc3219]
   provides  a  way  for  nodes  on  the IP network to locate a suitable
   gateway through the use of Location Servers.  TRIP is a policy driven
   inter-administrative    domain    protocol    for   advertising   the
   reachability, negotiate capabilities, and  specify  attributes  about
   these gateways.

   The TRIP protocol is modeled after BGP-4  [rfc4271]  and  uses  path-
   vector  advertisements distributed in a hop-by-hop manner (resembling
   a  Bellman-Ford  routing  algorithm)  via  Location  Servers.   These
   Location  Servers  are grouped in administrative clusters known as an
   Internet Telephony Administrative Domains (ITAD).  A  more  extensive
   framework discussion on TRIP can be found in [rfc2871].

   This document defines a new attribute to  be  registered  with  IANA.
   The  purpose  of  this  new  attribute,  and the rationale behind its
   specification, is explained in the following sections.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  "SHALL  NOT",
   "SHOULD",  "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [rfc2119].

2.  Emergency Telecommunications Service

   Emergency Telecommunications Service is a broad term that  refers  to
   the   services   provided   by  systems  used  to  support  emergency
   communications.  One example of these systems is the U.S.  Government
   Emergency  Telecommunications  System  (GETS).  This system currently
   operates over the U.S. Public Switched Telephone Network (PSTN) as  a
   pay-per-use  system by authorized personnel.  It uses the T1.631-1993
   ANSI standard [ANSI] to signal the presence of the National  Security
   /  Emergency  Preparedness  code  point  in  an ISDN User Part (ISUP)
   Initial Address Message (IAM) for SS7.  A key aspect of GETS is  that
   a  signaling  standard  in  the  U.S.  PSTN  is  used  to  convey the
   activation/request of the GETS service.

   From a protocol perspective, other examples of  priority  (and  which
   can  be  argued  as  emergency/disaster  related)  standards  are the
   H.460.4 ITU [itu460] standard on Call Priority designation for  H.323
   calls,   and   the  I.255.3  [itu255]  ITU  standard  on  Multi-Level
   Precedence and Preemption Service.  The latter  has  been  integrated
   into   private  telephony  systems  like  AUTOVON.   In  both  cases,
   signaling  code-points  exist  to  distinguish  telephony  calls   by
   authenticated and prioritized end-user from the normal end-user.  The

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 2]

Internet Drafts       Resource Priority Attribute       November 8, 2007

   form of this distinction varies and is  outside  the  scope  of  this
   document.  [rfc3689] and [rfc3690] provides additional information on
   ETS and its requirements.

3.  SIP Resource-Priority Effort

   The  initial  discussions  in  the  IEPREP  list,  along   with   the
   presentation   at   the   Adelaide-IETF  [ADEL00],  led  to  strawman
   requirements to augment SIP to have the ability  to  prioritize  call
   signaling.   This  effort  was  then advanced formally in the SIPPING
   working group so that SIP would  be  able  to  prioritize  access  to
   circuit-switched  networks,  end  system,  and  proxy  resources  for
   emergency preparedness communication [rfc3487].

   The requirements in [rfc3487]  produced  the  corresponding  document
   [rfc4412]  in  the  SIP working group, which defines a new header for
   SIP called Resource-Priority.  This new header, which is optional, is
   divided  into two parts: a NameSpace and a Value.  The NameSpace part
   uniquely identifies a group of one or  more  priorities.   The  Value
   part identifies one of a set of priorities used for a SIP message.

3.1  Benefits

   There are three basic benefits  derived  from  the  addition  of  the
   Resource  Priority  header in SIP.  The first is an ability to signal
   the priority within a SIP message to other entities in an IP network.
   The  caveat  is  that  some  entities  may  not recognize/support the
   priority or namespace,  but  at  least  the  ability  to  signal  the
   priority  with  respect  to  resources  has been specified in the SIP
   protocol.

   The second benefit is that telephony related protocol/codepoints from
   other  standards  can have a corresponding mapping to SIP NameSpace &
   Value tokens its the Resource-Priority header.   Hence,  the  current
   NS/EP   codepoint   in   ANSI   standard  T1.631-1993  could  have  a
   corresponding NameSpace.Value token set for the IETF standards  body.
   And  as  a  result,  this  mapping  would  facilitate the transparent
   bridging of signals (i.e., code points) between standards defined  by
   various organizations -- be they private or public.

   The third benefit of the Resource Priority header, and its definition
   of  alphanumeric  tokens,  is  that  it  is  highly  versatile.   The
   NameSpace allows for wide  set  of  priorities  to  be  defined,  and
   updated  if the need arises by simply defining a new NameSpace token.
   Hence, there is no reliance on a single set of priorities applied for
   all cases.

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 3]

Internet Drafts       Resource Priority Attribute       November 8, 2007

3.2  Issue

   Having defined a means of signaling priority  through  gateways,  the
   follow  on  question  arises of how does one determine which gateways
   support a  given  NameSpace.   The  dissemination  of  this  type  of
   information  is  within  the  scope  of  TRIP.   However, the current
   specification of TRIP does not include a  component  that  advertises
   associations  of  gateways with specific NameSpaces.  To address this
   omission, the following section defines a  new  TRIP  attribute  that
   associates one or more NameSpaces with a gateway.

4.  New Attribute: ResourcePriority

   This section provides details on the  syntax  and  semantics  of  the
   ResourcePriority  TRIP attribute.  Its presentation reflects the form
   of existing attributes presented in Section 5 of [rfc3219].

   Attribute Flags, whose field is shown in Figure 3 above, are  set  to
   the following:

      Conditional Mandatory: False
      Required Flags: Not Well-Known, Independent Transitive
      Potential Flags: None
      TRIP Type Code: TBD  (proposed to be 12)

   There are no  dependencies  on  other  attributes,  thus  Conditional
   Mandatory is set to "False".

   Since the Resource-Priority field  in  SIP,  with  its  corresponding
   NameSpace  Token, is optional, the ResourcePriority Attribute in TRIP
   is also optional.  Hence, it is set to "Not Well-Known".

   The Independent Transitive condition indicates that the attribute  is
   to be forwarded amongst all ITADs.  The Location Server that does not
   recognize the attribute sets the Partial flag as well.

4.1  Syntax of ResourcePriority

   The ResourcePriority attribute contains one or more  NameSpace  token
   identifiers.  An initial set of identifiers are defined in [rfc4412],
   with subsequent identifiers to be found in the  IANA  registry.   The
   syntax   of   the  ResourcePriority  attribute  is  copied  from  the
   "namespace" token syntax  from  [rfc4412],  which  in  turn  imported
   "alphanum"  from  [rfc3261],  and  is  an alphanumeric value as shown
   below:

   namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
                   / "`" / "'" / "~" )

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 4]

Internet Drafts       Resource Priority Attribute       November 8, 2007

   Note that an augmented  version  of  Backus-Naur  From  is  found  in
   [4234].

   Since NameSpaces are arbitrary in length, each tuple  consists  of  a
   Length  value  with  a  NameSpace  value  as shown in Figure 4 below.
   There is no padding between tuples.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+--------------+----------------+
   |        NameSpace Length       |   NameSpace Value (variable)  |
   +---------------+---------------+--------------+----------------+

   It is important to note that the priority (i.e.,  "r-priority"  token
   syntax) from [rfc4412] is NOT used in the ResourcePriority attribute.
   This is because the objective of the attribute is  to  advertise  the
   NameSpace associated with a gateway and not the individual priorities
   within that NameSpace.

4.2  Additional TRIP Considerations

   Section 5.12 of TRIP lists a number of considerations that should  be
   addressed   when   defining   new   attributes.    The   first  three
   considerations (use of the attribute, its  flags,  and  syntax)  have
   been discussed above in this section.  The final three considerations
   are:

4.2.1  Route Origination

   The ResourcePriority attribute is not well-known.  If a route  has  a
   ResourcePriority  attribute  associated  with it, the Location Server
   (LS) MUST include that attribute in the advertisement it originates.

4.2.2  Route Aggregation

   Routes with differing  ResourcePriority  token  values  MUST  NOT  be
   aggregated.    Routes   with   the   same   token   values   in   the
   ResourcePriority  attribute  MAY   be   aggregated   and   the   same
   ResourcePriority attribute attached to the aggregated object.

4.2.3  Route Dissemination and Attribute Scope

   An LS MUST include the ResourcePriority attribute when  communicating
   with peer LSs within its own domain.

   If received from a peer LS in another domain, an LS   MUST  propagate

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 5]

Internet Drafts       Resource Priority Attribute       November 8, 2007

   the ResourcePriority attribute to other LSs within its domain.

   An LS MAY add the ResourcePriority attribute when propagating routing
   objects   to   an  LS  in  another  domain.   The  inclusion  of  the
   ResourcePriority  attribute  is  a  matter  of  local  administrative
   policy.

5  Security Considerations

   The document defines a new attribute for the TRIP protocol and has no
   direct  security considerations applied to it.  However, the security
   considerations for TRIP and its messages  remain  the  same  and  are
   articulated in Section 14 of [rfc3219].

6.  IANA Considerations

   As described in Section 4 above, one new "TRIP  attribute"  has  been
   defined.  Its name and code value are the following:

      Code                    Attribute Name
      ----                   ----------------
       TBD (suggest 12)      ResourcePriority

   These assignments are recorded in the following registry:
      http://www.iana.org/assignments/trip-parameters

7.  Acknowledgements

   The authors appreciate review and subsequent comments from James Polk
   and Henning Schulzrinne.

8.  References

8.1  Normative References

   [rfc2871] Rosenberg, J. and H. Schulzrinne, "A Framework for
             Telephony Routing over IP", RFC 2871, IETF, June 2000.

   [rfc3219] Rosenberg, J. et. al., "Telephony Routing over IP (TRIP)",
             RFC 3219, IETF, January 2002.

   [rfc4412] Schulzrinne, H. and J. Polk, "Communications Resource
             Priority for the Session Initiation Protocol (SIP)",
             RFC 4412, IETF, Feb 2006.

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 6]

Internet Drafts       Resource Priority Attribute       November 8, 2007

8.2  Informative References

   [ADEL00] IETF Proceedings (47'th), SIP Working Group, Adelaide,
            Australia, June 2000

   [ANSI] ANSI, "Signaling System No. 7(SS7): High Probability of
          Completion (HPC) Network Capability", ANSI T1.631, 1993.

   [itu460] ITU "Call Priority Designation for H.323 Calls", ITU
            Recommendation H.460.4, November, 2002.

   [itu255] ITU, "Multi-Level Precedence and Preemption Service, ITU,
            Recommendation, I.255.3, July, 1990.

   [rfc2119] Bradner, S., "Key Words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, IETF, march 1997.

   [rfc3261] Rosenberg, J., et.. al., "SIP: Session Initiation
             Protocol", RFC 3261, IETF, June 2002.

   [rfc3487] Schulzrinne, H., "Requirements for Resource Priority
             Mechanisms for the Session Initiation Protocol (SIP)",
             RFC 3487, IETF, February 2003.

   [rfc3689] Carlberg, K. and R. Atkinson, "General Requirements for
             Emergency Telecommunications Service (ETS)", RFC 3689,
             IETF, February 2004.

   [rfc3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements
             for Emergency Telecommunications Service (ETS)",
             RFC 3690, IETF, February 2004.

   [rfc4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 4234, IETF, October 2005

   [rfc4271] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
             (BGP-4)", RFC 4271, IETF, January 2006.

Author's Addresses

   Ken Carlberg                            Piers O'Hanlon
   G11                                     University College London
   123a Versailles Circle                  Gower Street
   Baltimore, MD                           London
   USA                                     UK

   carlberg@g11.org.uk                     p.ohanlon@cs.ucl.ac.uk

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 7]

Internet Drafts       Resource Priority Attribute       November 8, 2007

Intellectual Property Statement

   The IETF takes no position regarding the validity  or  scope  of  any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology  described  in
   this  document  or  the extent to which any license under such rights
   might or might not be available; nor does it represent  that  it  has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights  in  RFC  documents  can  be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures  made  to  the  IETF  Secretariat  and  any
   assurances  of  licenses  to  be  made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such   proprietary   rights   by   implementers   or  users  of  this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its  attention  any
   copyrights,  patents  or  patent  applications,  or other proprietary
   rights that may cover technology that may be  required  to  implement
   this  standard.   Please address the information to the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE  INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE  INFORMATION  HEREIN  WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The The IETF Trust (2007).  This document is subject to
   the rights, licenses and restrictions contained in BCP 78, and except
   as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function  is  currently  provided  by  the
   Internet Society.

Carlberg & O'Hanlon              Expires April 8, 2008          [Page 8]