[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 5115

Internet Engineering Task Force                   Ken Carlberg
INTERNET DRAFT                                    G11
Sep 15, 2005                                      Piers O'Hanlon
                                                  UCL


                  TRIP Attribute for Resource Priority
               <draft-carlberg-trip-attribute-rp-00.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 Internet Society (2005).


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.





Carlberg & O'Hanlon              Expires March 15, 2005         [Page 1]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


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  [rfc1771]  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].

1.1  TRIP Protocol Messages

   The TRIP header has a fixed-size, and as shown in Figure 1 below,  is
   divided  into  two parts: a Length field for the entire TRIP message,
   and a Type field indicating which type of TRIP message is being sent.

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +--------------+----------------+---------------+
       |          Length               |      Type     |
       +--------------+----------------+---------------+

                    Figure 1: TRIP Header

   There are four types of messages defined for TRIP, these being:

       1 - OPEN, 2 - UPDATE, 3 - NOTIFICATION, 4 - KEEPALIVE

   The OPEN messages establishes a  peer-to-peer  TRIP  session  between
   Location  Servers.  During this establishment, an optional Capability
   Information  can  be  exchanged  between  peers.   This   information
   provides a measure of discovery in aspects such as the type of routes
   supported by both nodes.  KEEPALIVE messages are used to refresh  the
   TRIP  session  and  reaffirm  the  reachability  of  peering Location
   Servers.

   The NOTIFICATION message is sent when an error condition is detected.
   When   the   message  is  sent,  the  TRIP  transport  connection  is
   immediately closed.




Carlberg & O'Hanlon              Expires March 15, 2005         [Page 2]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


   UPDATE messages advertise TRIP routes.  These routes  may  exist  and
   thus  be reachable, or they may represent those routes that have been
   withdrawn and therefore are no longer reachable by a  given  Location
   Server and/or ITAD.

1.1  Attributes of UPDATE Messages

   In addition to the TRIP Header, an UPDATE message contains a list  of
   routing attributes as shown in Figure 1 below.  Note that there is no
   padding between Attributes.

     +------------------------------------------------+--...
     | 1'st Route Attribute | 2'nd Resource Attribute | ...
     +------------------------------------------------+--..

               Figure 2: List of Routing Attributes

   Each Routing Attribute has a  fixed-size  part  and  a  variable-size
   part.  The structure of a Routing Attribute is in the classic form of
   Type-Length-Value, where the "Type-Length"  is  fixed  size  and  the
   "Value" part is variable length.  This allows attributes to be highly
   flexible in their definition -- both now, and in the future.   Figure
   3 below shows the template structure of a Routing Attribute.

    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
   +---------------+---------------+--------------+----------------+
   |  Attr. Flags  |Attr. Type Code|         Attr. Length          |
   +---------------+---------------+--------------+----------------+
   |                   Attribute Value (variable)                  |
   +---------------+---------------+--------------+----------------+

               Figure 3: Routing Attribute Template

   [rfc3219]  defines  11  attributes,  ranging  from  ReachablecRoutes,
   WithdrawncRoutes,  to  Advertisement  Paths  (the  sequence  of ITADS
   through which "this" advertisement has  passed).   Future  attributes
   are assigned by IANA from RFCs.

   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.

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



Carlberg & O'Hanlon              Expires March 15, 2005         [Page 3]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


   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  from  the
   normal  user.  The form of this distinction varies and is outside the
   scope of this document.  [rfc3689], [rfc3690], and [rfcxxxx] provides
   additional   information   on  ETS  and  its  requirements  from  the
   perspective of the Internet Emergency Preparedness  (IEPREP)  working
   group of the IETF.

3.  SIP Resource-Priority Effort

   The  initial  discussions  in  the  IEPREP  list  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
   [draftRP] in the SIP working group, which defines a new field for SIP
   called Resource-Priority.  This new  field,  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.

   The contents or tokens of both the NameSpace  and  Value  are  copied
   from  the  "token-nodot"  value  of [rfc3265].  These tokens are case
   insensitive and follow the  syntax  specification  of  the  augmented
   Backus-Naur  Form  (BNF)  as  described  in  [rfc2234].   The  formal
   representation of the Resource-Priority field is shown below:

         Resource-Priority  = "Resource-Priority" HCOLON
                              r-value *(COMMA r-value)
         r-value            = namespace "." r-priority
         namespace          = token-nodot



Carlberg & O'Hanlon              Expires March 15, 2005         [Page 4]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


         r-priority         = token-nodot
         token-nodot        = 1*( alphanum / "-"  / "!" / "%" / "*"
                                     / "_" / "+" / "`" / "'" / "~" )

   Examples of the Resource-Priority field  and  its  contents  are  the
   following:

       1) Resource-Priority: q735.4
       2) Resource-Priority: wps.3, dsn.flash

   Note that in  the  second  example,  there  are  two  NameSpace.Value
   entries  separated  by  a  ",".   Multiple  entries  in the Resource-
   Priority field are allowed, but they  must  be  unique  --  duplicate
   NameSpace entries are not permitted in the same 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.

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



Carlberg & O'Hanlon              Expires March 15, 2005         [Page 5]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


   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 [DraftRP],
   with subsequent identifiers to be found in the  IANA  registry.   The
   syntax   of   the  ResourcePriority  attribute  is  copied  from  the
   "namespace" token syntax from [DraftRP], and is an alphanumeric value
   as shown below:

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


   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.




Carlberg & O'Hanlon              Expires March 15, 2005         [Page 6]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


    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 [DraftRP] 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.1  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 SHOULD  propagate
   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.





Carlberg & O'Hanlon              Expires March 15, 2005         [Page 7]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


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

   TBD


8.  References

8.1  Normative References

   [rfc2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, IETF, November 1997.

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

   [draftRP] Schulzrinne, H. and J. Polk, "Communications Resource
             Priority for the Session Initiation Protocol (SIP)",
             Work In Progress, IETF, July 2005.

8.2  Informative References

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



Carlberg & O'Hanlon              Expires March 15, 2005         [Page 8]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


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

   [rfc1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
             (BGP-4)", RFC 1771, IETF, March 1995.

   [rfc3265] Roach, A., "Session Initiation Protocol (SIP) - Specific
             Event Notification", RFC 3265, IETF, June 2002.

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

   [rfc3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
             IETF, February 2004.

   [rfc3668] Bradner, S., "Intellectual Property Rights in IETF
             Technology", RFC 3668, IETF, February 2004.

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


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

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.



Carlberg & O'Hanlon              Expires March 15, 2005         [Page 9]

Internet Drafts       Resource Priority Attribute           Sep 15, 2005


   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  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 Internet Society (2005).  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 March 15, 2005        [Page 10]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/