[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Nits]
Versions: 00                                                            
Internet Engineering Task Force                                 IPTEL WG
Internet Draft                                               Matt Squire
draft-ietf-iptel-glp-00.txt                              Nortel Networks
February 16, 1999
Expires: August 1999

                      A Gateway Location Protocol


   This document is an Internet-Draft and is in  full  conformance  with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow  Directories  can  be  accessed  at

1 Abstract

   Given a gateway and a (possibly empty) list  of  gateway  attributes,
   the "gateway location problem" is to find a gateway serving the given
   phone number that satisfies the attribute set.  This problem has also
   been referred to as the "call routing problem" as the answer returned
   may not be an IP-PSTN gateway but an intermediate signaling server.

   Part  of  the  solution  to  this  problem  is  the  maintenance  and
   distribution  of  the call routing tables.  This document describes a
   protocol for maintaining a distributed call routing  database  across
   multiple  administrative domains.  The protocol uses the Server Cache
   Synchronization Protocol (SCSP) to maintain the distributed database.
   This  document  describes  the  problem  of  gateway  location  and a
   potential solution that uses SCSP as the foundation for  distributing
   the call routing tables.

2 Overview of the Gateway Location Problem

Squire                                                          [Page 1]

Internet Draft                    GLP                   16 February 1999

   A gateway is a device providing connectivity between the PSTN and  an
   IP  network.   A telephone call that originates from an IP device, or
   that passes through an IP network, and that terminates on  the  PSTN,
   must  traverse  a  gateway.   There  may  be multiple gateways in the
   network through which a particular call could egress the network.  An
   important  step  in  the  evolution of IP telephony is automating the
   choice of an egress gateway for a particular call.

   The general gateway location problem  is  described  in  the  Gateway
   Location Framework [GLP-FR], and the position of the Gateway Location
   Protocol (GLP) relative to other IP telephony protocols and  entities
   is  defined.   This  framework  is summarized here, but the reader is
   referred to [GLP-FR] for a fuller description.

   In the framework, End Users (EUs) are entities with  IP  connectivity
   and  with the ability to place phone calls to users on the PSTN.  EUs
   may be users with IP telephony equipment or may be gateways from  the
   PSTN  to  an  IP  network.   Gateways  are the devices that translate
   between an IP network and the PSTN.  Location Servers (LSs)  are  the
   logical  entities  that  maintain  knowledge  of  the  gateways,  and
   Signaling Servers (SSs) are the entities which  forward  and  process
   signaling  messages.   Common  signaling  protocols are SIP [SIP] and
   H.323 [H323].  Signaling servers forward (route)  signaling  messages
   while  location  servers  maintain  the  information  on  which these
   forwarding decisions are made.

   GLP is defined as an inter-domain protocol,  where  an  IP  Telephony
   Administrative   Domain  (ITAD)  is  a  collection  of  IP  telephony
   resources under the control of  a  single  administrative  authority.
   LSs  participate  in  the  GLP  to maintain this database of gateways
   across multiple ITADs.  Another protocol, the intra-domain  protocol,
   may  be  used  by  LSs  within  a  domain  to further distribute this
   information.  The use  of  possibly  different  inter-domain  and  an
   intra-domain  protocols is analogous to the use of the Border Gateway
   Protocol (BGP) [BGP] and the Open Shortest Path First  (OSPF)  [OSPF]
   protocol  to  maintain  routing  tables between and within autonomous
   systems (IP routing domains).  Note that just  as  BGP  can  be  used
   within  an  autonomous  system, GLP can be use within an ITAD.  Using
   GLP within an ITAD provides reliability and scaleability  for  inter-
   domain communications by permitting multiple border routers.

   LSs learn about the gateways within their domain through  an  out-of-
   band mechanism.  Another protocol, the front-end protocol, is used by
   EUs to access the LS database in order to route  a  call  toward  the
   PSTN.   The  GLP  places  no  restrictions on the front-end or intra-
   domain protocols.

Squire                                                          [Page 2]

Internet Draft                    GLP                   16 February 1999

3 Comparison of Call Routing and IP Routing

   To better understand the problem of call routing, we first compare it
   with the well-understood problem of IP routing.

   IP routing tables are made  up  of  a  collection  of  routing  table
   entries.   For basic IP routing, each entry consists of a destination
   address, an address mask, a next-hop router, and a path-length.   All
   packets  targeted  to a destination covered by the combination of the
   destination address and address mask are forwarded  to  the  next-hop
   router.  The cost to reach the destination is given by path-length.

   Whenever there are multiple entries that cover a single  destination,
   the  more  specific  entry  (with the longer address mask) is used to
   route the packet.  There are mechanisms defined for  aggregating  and
   forwarding  routing  information.   For  example,  when advertising a
   route entry received from  one  neighbor  to  another  neighbor,  the
   router   may   increment  the  path-length  before  transmitting  the
   advertisement.  Also, when a router receives  multiple  routes  to  a
   particular  destination,  it  may discard entries with a longer path-
   length as these represent non-optimal routes.

   Call routing is similar but has several important distinctions.   The
   call  routing  infrastructure  is overlayed on the IP infrastructure,
   but the two routing realms are independent.  Location Servers,  which
   maintain  the  call  routing  tables,  and  Signaling  Servers, which
   forward  the  signaling  messages,  are  distinct  logical   entities
   (however,  a  single  device  may  perform  both  functions).  The IP
   telephony data (the packetized voice) is not routed using  the  LS/SS
   combination.   It  is  forwarded as normal IP packets and need not be
   routed through any signaling server.  Peer LSs need not be physically

   Call routing tables are made up  of  a  collection  of  call  routing
   objects.   A  call  routing object is a more complex version of an IP
   routing table entry.  Like an IP routing table entry, a call  routing
   object  includes  a  set of destination addresses and a next hop.  In
   this case, the set of destination addresses is  given  by  upper  and
   lower  bound  telephone  numbers,  and  the  next-hop is the next-hop
   signaling server (which may in fact be a gateway).   In  IP  routing,
   the  cost  represents  a  path cost (ie a relative measurement of the
   distance/delay between two points).  In call routing, the cost  of  a
   route is an optional attribute of a call routing object, and the cost
   of a route is dependent on may variables other  than  the  path  (the
   cost  charged  by  a  gateway  to  service a call, the quality of the
   service given by the network and gateway, etc).

   A call routing object may  also  include  any  number  of  additional

Squire                                                          [Page 3]

Internet Draft                    GLP                   16 February 1999

   attributes.  These might include the signaling protocols supported by
   the next-hop SS for this destination, the telephony features provided
   for   this   destination,  the  speech  codecs  understood  for  this
   destination,   the   encryption   algorithms   supported   for   this
   destination,   etc.    The   set  of  attributes  is  open-ended  and
   destination specific.  As such, defining a standard set of rules  for
   aggregating and forwarding call-routing objects is itself a difficult

   In IP routing, given any destination address, there is a simple  rule
   for  determining  the  routing  table  entry  that should be applied.
   Namely, find the  routing  table  entry  with  the  longest  matching
   prefix.   Such  a rule does not exist in the context of call routing.
   Prefix length is not the most significant variable in determining the
   best   suited  routing  object.   Call  routing  objects  are  multi-
   attributed, as such there can certainly be more than one  entry  that
   applies to a particular destination.  For example, a particular phone
   number may be reachable via a SIP server at one destination or via  a
   H.323 server at another destination.  Multiple matching entries could
   be  used  by  a  server  to  load-balance  between  several  possible

   One can also examine the  scaleability  of  call  routing  versus  IP
   routing.  For the Internet, all routers must be interconnected.  Each
   routing table must contain an applicable  entry  for  every  Internet
   address.  The collection of SSs on the Internet need not be (and most
   likely will never be) connected.  A likely scenario is that a set  of
   IP telephony providers will combine resources to form a confederation
   whose signaling servers and location servers communicate.   Different
   confederations will most likely not share call routing data, implying
   a collection of independent call routing confederations.  So although
   a call routing table may contain an entry covering every phone number
   on  the  PSTN,  any  particular  LS/SS  only  propagates  information
   about/to gateways within its confederation.

4 GLP Model

   GLP is analogous to BGP in that  it  is  used  to  distribute  (call)
   routing  information  between  domains.   As such, BGP is used as the
   model for GLP.

   At its core, BGP is a combination of link-state  and  distance-vector
   routing protocols whose aggregation and filtering rules are partially
   specified by the protocol itself and partially specified by a set  of
   local  policies for that BGP speaker.  BGP speakers may have internal
   and external links to BGP speakers in its or other  domains.   A  BGP

Squire                                                          [Page 4]

Internet Draft                    GLP                   16 February 1999

   link is a communication between two peer BGP speakers.  Behavior over
   internal and external links is slightly different.  Within a  domain,
   all  BGP  speakers use a combination of a mesh or route reflectors to
   achieve complete connectivity.  BGP speakers maintain an inbound  and
   outbound  routing  table  for  each  link, as well as a local routing
   table used in their own routing decisions.   When  a  link  is  first
   established,  BGP  synchronizes each speaker's outbound routing table
   with its peer's inbound routing table.  After  this  synchronization,
   only updates traverse across the link.

   The Server Cache Synchronization Protocol (SCSP), on the other  hand,
   is  a  generalization  of  OSPF  in  that  it  accomplishes  database
   synchronization on multiple servers by flooding information  received
   from  one  neighbor  to  all  other  neighbors.   However, if an SCSP
   flooding domain is restricted to  a  pair  of  neighbors,  then  SCSP
   behaves  much  like  BGP.   Both  protocols  exchange  hello messages
   between peers, perform  an  entire  transfer  of  the  database  upon
   detecting a new peer, and only exchange incremental updates after the
   initial  synchronization.   GLP  applies  SCSP  to  the  inter-domain
   problem  of  gateway  location  by limiting the inter-domain flooding
   group to a pair of peer  speakers  from  adjacent  ITADs.   In  other
   words, the flooding aspects of SCSP are not used on inter-ITAD links.

   To this end, a Location Server belongs to a number of  Server  Groups
   (SGs).   Each  SG  corresponds  to  a  collection  of  servers  whose
   databases are to be synchronized.  When a SG spans domains, it likely
   consists  of  only  two  LSs  and provides bidirectional connectivity
   between the LSs.  This is analogous to two peer BGP speakers over  an
   external  BGP  link.   For internal links, however, the possibilities
   are more flexible.  Within a domain, a Server Group  may  consist  of
   multiple   LSs  interconnected  with  an  arbitrary  topology.   This
   provides a much more flexible and  robust  intra-domain  connectivity
   than BGP meshes and route reflectors.

   The set of SGs to which a particular LS belongs, the set  of  servers
   forming  a Server Group, and the topology of interconnection within a
   SG are all determined administratively.  Since GLP is defined  as  an
   inter-domain protocol, no neighbor discovery is provided.

   SCSP is used to maintain a distributed and synchronized database over
   all  servers  in  a  Server  Group.   This  database  consists of the
   information required to route calls across the network.  As  in  BGP,
   the  database  can be logically partitioned into inbound and outbound
   databases.  The LS has an internal Policy Information  Base  (LS-PIB)
   that  defines  how to compute the outbound databases given the set of
   inbound databases.  The LS also has a local database that it uses  to
   make  call  forwarding decisions.  The contents of the local database
   is also determined by applying  the  LS-PIB  policy  to  the  inbound

Squire                                                          [Page 5]

Internet Draft                    GLP                   16 February 1999


   The GLP model is depicted in Figure 1, where LSs LS-A1 through  LS-A3
   are  in one administrative domain, and LSs LS-B1 through LS-B2 are in
   another ITAD.  In this example, the SGs are  {LS-A1,  LS-A2,  LS-A3},
   {LS-A3,  LS-B1},  and  {LS-B1,  LS-B2}.   Note  that  the topology in
   administrative   domain   A   is   not   complete.    SCSP   provides
   synchronization across arbitrary connected topologies.

     | LS-A1               |
     |   gw-local          |
     |      |              |
     |    LS-PIB           |
     |      |              |
     |      |              |   |---------------------|
     | gw-in gw-out        |   | LS-A3               |
     |---------------------|   |         gw-local    |
            |                  |             |       |
           /                  |             |       |
          /   ----------------|  gw-in -- LS-PIB    |
         /                     | gw-out      |       |
     |----------------------   |             |       |
     | gw-in gw-out        |   |        gw-out gw-in |
     |      |              |   |---------------------|
     |      |              |                 |
     |    LS-PIB           |                 |
     |      |              |                 |
     |      |       LS-A2  |          |-----------------------|
     |    gw-local         |          | gw-in gw-out          |
     |---------------------|          |      |                |
                                      |    LS-PIB -- gw-local |
                                      |      |                |
                                      | gw-in gw-out    LS-B1 |
                                      | gw-in gw-out          |
                                      |      |                |
                                      |    LS-PIB -- gw-local |
                                      |                       |
                                      |                 LS-B2 |

                            Figure 1 GLP Model

Squire                                                          [Page 6]

Internet Draft                    GLP                   16 February 1999

   The form and function of the LS  policies  is  not  defined  in  this
   document.   We  believe  that  the  most appropriate policies will be
   developed  over  time  and  through  implementation  innovation   and
   experience.   The  multi-attributed  nature  of  a  gateway  makes it
   difficult to define a satisfactory set of  policies  for  aggregating
   and filtering the collection of gateways forwarded to each neighbor.


   The Server Cache Synchronization Protocol (SCSP)  [SCSP]  solves  the
   general  problem  of  server  synchronization  and cache replication.
   SCSP synchronizes the caches of a set  of  servers  of  a  particular
   protocol  bound  to  a  particular server group.  In the case of GLP,
   SCSP is used to synchronize the call routing database of all  servers
   within  a  SG.   The  SG  may consist of two servers (for example, an
   inter-ITAD SG may consist of one LS from each of two domains) or  may
   be more general (for example, when used between the border LSs within
   a particular ITAD).

   SCSP uses the combination of a Protocol ID (PID) and a  Server  Group
   ID  (SGID)  to  identify  both the protocol for which the servers are
   being synchronized as well as the instance of that protocol.  In  our
   case, the PID identifies the protocol as GLP.

   Editor's Note.  We need to get an SCSP PID for GLP.

   SCSP assumes a the underlying network  is  a  Non-Broadcast  Multiple
   Access  (NBMA)  network.  For GLP, the NMBA network is any IP network
   providing TCP connectivity.  GLP could  also  operate  directly  over
   other  NBMA  networks  (such  as ATM AAL5, Frame Relay, etc), but the
   specifics of such behavior is not detailed here.

 5.1 SCSP Operation

   SCSP  has  three  phases.   The  first  phase  serves  to   establish
   connectivity  between  directly  connected  neighbors.  This phase is
   known as the Hello Phase.  The second phase is  the  Cache  Alignment
   phase, where directly connected servers quickly exchange the contents
   of their entire database.  The third phase is the Cache State  Update
   phase, where servers only transmit updates of their local database to
   their directly connected peers, and servers flood  received  database
   elements  to other directly connected peers within the same SG.  Note
   that this flooding operation  permits  a  more  general  intra-domain
   topology  than  BGP  which requires a combination of meshes and route

Squire                                                          [Page 7]

Internet Draft                    GLP                   16 February 1999

  5.1.2 Hello Phase

   In the Hello Phase, directly connected LSs exchange hello messages in
   order to establish bidirectional connectivity between peers.

   After connectivity is established,  hello  messages  continue  to  be
   exchanged  in  order  to  indicate  the  status  of  the peer.  Hello
   messages have two fields which control the  frequency  of  the  hello
   messages  and  the  time  before  a  neighbor is declared inoperable.
   Hello messages are sent  every  HelloInterval  seconds.   A  peer  is
   considered   dead   if   no  hello  message  has  been  received  for
   HelloInterval*DeadFactor seconds.  For GLP, hello messages  must  not
   be  transmitted  more  than once per second.  The suggested value for
   the HelloInterval is 30 seconds.  The suggested value  of  DeadFactor
   is 3.

   Editor's Note.  One shortcoming of SCSP is that the Hello Protocol is
   not  particularly  extendible.   There  is  nothing  like  version or
   feature negotiation  during  the  Hello  Phase.   Is  version/feature
   negotiation required for GLP?

  5.1.2 Cache Alignment Phase

   During the  Cache  Alignment  phase,  peer  servers  synchronize  the
   contents  of  their  entire  database.   During Cache Alignment, peer
   servers first exchange  a  summary  of  their  database.   After  the
   summary  exchange,  a  server requests data elements from their peers
   based on that summary information.  Cache Alignment  ends  when  peer
   servers have synchronized their databases for the first time.

   After first aligning its GLP  database  with  a  peer,  an  LS  shall
   execute  its  local  policies  to  determine if any of its advertised
   databases, or  its  local  database,  have  changed.   Any  resulting
   changes to an advertised route must be synchronized with the affected

  5.1.3 Cache State Update Phase

   During the Cache Update phase, adjacent LSs exchange only changed  or
   updated data elements.  When something happens at an LS to change the
   set of advertised call  routing  elements  to  a  peer,  an  LS  must
   propagate this change to its neighbor.  The neighbor acknowledges the
   newly received elements.

   When an LS is informed  of  an  updated  or  new  call  routing  data

Squire                                                          [Page 8]

Internet Draft                    GLP                   16 February 1999

   element,  it  must execute its local policies to determine if the set
   of local or advertised call routes has been  changed.   If  so,  then
   these changes must be propagated to the affected neighbor(s).

 5.2 GLP Specific SCSP Fields

   SCSP has generic and protocol specific aspects.  This section details
   the GLP specific fields and formats for use within SCSP.

   GLP  runs  over  a  NBMA  network   of   TCP   connections.    During
   initialization, servers establish TCP connections to their configured
   set of peers.  By default, SCSP over TCP uses TCP  port  XXXX.   This
   port  value should be configurable at an LS.  It is a straightforward
   exercise to run GLP over other types of NBMA networks, or  to  extend
   SCSP/GLP  over a network with multicast ability.  However, due to the
   inter-domain aspects of GLP, multicast is not recommended.

   Editor's Note.  We need to get a SCSP TCP port assigned.

   Editor's Note.  It is not obvious that TCP is the only or  the  right
   choice  for  the  transport  layer.   RUTS?   An encrypted transport?
   Other possibilities?

   The scope of a SCSP flooding domain is controlled by the  combination
   of Server Group ID (SGID) and Protocol ID (PID).  For GLP, the PID is
   XXXX.  The assignment of the SGID for a specific set of servers is  a
   local decision.

   Editor's Note.  We need to get a SCSP GLP PID assigned.

   Servers within a SG of SCSP  must  have  unique  server  identifiers.
   These  identifiers  are  used to indicate the source and recipient of
   each SCSP message, as well as the originator of a data element within
   the  distributed database.  For GLP, this identifier is an IP address
   unique to the LS.  The identifier is 4 octets in length.

   Each data element within a SCSP database can  be  identified  by  the
   combination  of  the Originator ID (the server which sourced the data
   element) and the Cache Key.  The Cache Key is an identifier  for  the
   data  element  chosen  such that the combination of Originator ID and
   Cache  Key  uniquely  identifies  this  element.   Servers  use  this
   identification  method when determining if a received data element is
   a 'new' object or another version of an existing object.   The  Cache
   Key is variable length in SCSP.  For GLP, the length of the Cache Key
   is 4.  The Cache Key is a 4-octet field chosen by the originator of a
   data element such that the uniqueness condition is guaranteed.

Squire                                                          [Page 9]

Internet Draft                    GLP                   16 February 1999

   SCSP also defines a 'newness' criteria for database elements.  When a
   server  receives  a  data  element  from a peer, and that new element
   matches an existing element in both the Originator ID and Cache  Key,
   then  the  server  examines  the  Sequence  Number  of the element to
   determine which version of the element is  newer.   Sequence  Numbers
   can be used to refresh aging database elements.

   The format of the data elements synchronized by SCSP for GLP is given
   in Section 5.2.1.

  5.2.1 Generic GLP Data Object Format

   SCSP synchronizes individual database elements to all servers  within
   a  Server  Group.   In  SCSP,  a database element is represented as a
   Cache State Advertisement (CSA).  Each  CSA  contains  a  CSA  header
   followed by a protocol specific part containing the actual data.  The
   protocol specific part of a GLP CSA has the following generic format.

     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
    |  GLP Obj Type |   Reserved    |        GLP Object Length      |
    |                    GLP Object Data (variable)                 |

   The fields are defined as follows.

   GLP Obj Type.
     This field defines the type  of  GLP  object.   This  specification
     defines the following GLP Object Types.
       1 - GLPv1.0 Call Routing Object

   GLP Object Length.
     The Length of the GLP Object, from the start of the GLP Object Type
     field  to the end of the CSA data.  For alignment purposes, all GLP
     objects should be padded to have even length.

   CSA Data.
     The data specific to this instance of the object.   The  format  of
     the data depends on the object type.

  5.2.2 GLP Call Routing Object Format

Squire                                                         [Page 10]

Internet Draft                    GLP                   16 February 1999

   The GLP Call Routing Object (CRO) forms the basis for  internet  call
   routing.  The GLP CRO associates a range of telephone numbers with an
   IP address.  A CRO can be used to route signaling messages  to  phone
   numbers  that  lie  within the range specified by the lower and upper
   bound telephone numbers.  When forwarding a signaling message  for  a
   phone number in the specified range, a signaling server or user agent
   may forward the signaling message to the Next  Hop  Signaling  Server
   specified in the CRO.  The Next Hop Signaling Server may represent an
   actual gateway or  a  transit  signaling  server.   Whether  the  CRO
   represents  an  actual  gateway  or a transit SS cannot be determined
   from the CRO.

     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
    |  GLP Obj Type |   Reserved    |      GLP Object Length        |
    | Phone# LB Len | Phone# UB Len |      Num GLP Attributes       |
    |                           Lifetime                            |
    |                   Next Hop Signaling Server                   |
    |                  Phone# Lower Bound (variable)                |
    |                  Phone# Upper Bound (variable)                |
    |                    GLP Attributes (variable)                  |

   GLP Object Type.
     Equals 1.

   GLP Object Length.
     A CRO object has variable length but the length must be even.

   Phone Number Lower Bound Length.
     The length of the Lower Bound Phone Number field.

   Phone Number Upper Bound Length.
     The length of the Upper Bound Phone Number field.

   Number of GLP Attributes.
     The number of GLP attributes in this CRO.

     The number of seconds that this call-routing object is valid.  CROs

Squire                                                         [Page 11]

Internet Draft                    GLP                   16 February 1999

     must  be  aged  in  the  database  and  removed when their lifetime
     expires. Similarly, an originator must  refresh  CROs  before  they
     expire  in  a  peer.   A  CRO  can be refreshed by incrementing the
     Sequence Number of a CRO and synchronizing the updated CRO CSA with
     the peer.

   Next Hop Signaling Server.
     The IP address of the next hop signaling server that is  associated
     with this call routing object.  When using this call routing object
     to route a call, signaling messages are sent to this address.

   Editor's Note.  Should probably have a  more  general  concept  of  a
   protocol  address  (ie  have a protocol type and a protocol address).
   This would permit the same protocol to be used for routing calls over
   other networks (IPv6).

   Phone Number Lower Bound.
     The lower bound of the telephone number range defined by this  CRO.
     The sytax of this field is:
       phone-number-bound = +1*phone-digit phone-digit      = DIGIT
     This format is similar to the format for a global telephone  number
     as  defined  in  SIP  [4]  without  visual separators.  This format
     facilitates efficient comparison with the internationalized  format
     of a phone number.

   Editor's Note.  This representation does  not  permot  'local'  phone
   number formats.  Local formats seem dangerous when one the concept of
   local can be different for the client and server.

   Phone Number Upper Bound.
     The upper bound of the telephone number range defined by this  CRO.
     The  lower and upper bounds may refer to phone numbers in different
     country codes and  have  different  lengths.   A  phone  number  is
     covered by a particular CRO if
       lb <= p <= ub
     where p is the international version of the phone  number  and  the
     comparison  is  performed  using a string comparison function.  For
       +1919 <= +19199929048 <= +1919993

   Editor's Note.  We could also make the phone  numbers  and  next  hop
   server  into  attributes  (ie  have  the type, length, value format).
   Preferences anyone?

   GLP Attributes.
     The collection of attributes  associated  with  this  call  routing
     object.   For  alignment  purposes,  this field starts on the first
     even-octet boundary after the previous field.

Squire                                                         [Page 12]

Internet Draft                    GLP                   16 February 1999

  5.2.3 Generic GLP Attribute Format

   A CRO may contain any number of GLP Attributes.   Attributes  provide
   additional  information  about  the  call  routing  object.  Each GLP
   Attribute has the following generic format.

     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
    |      GLP Attribute Type       |     GLP Attribute Length      |
    |                 GLP Attribute Data (variable)                 |

   GLP Attribute Type.
     GLP Attributes provide additional information that can be  used  to
     restrict  the  call routing path applicable to a specific signaling
     sequence.  The  following  attribute  types  are  defined  in  this
          1 - Supported Signaling Protocols
          2 - Pricing
          3 - Gateway Provider
          4 - Next Hop Provider
          5 - Supported Codecs
          6 - Capacity
          7 - Time-to-live

   GLP Attribute Length.
     The length of this attribute from the start of the type field.  The
     length must be even.

   GLP Attribute Data.
     The data specific to this attribute.   The  data  format  for  each
     attribute is given in the following sections. Supported Signaling Protocol Attribute

   The Supported Signaling Protocol Attribute gives a signaling protocol
   supported  for  the CRO address range by the CRO next hop.  There can
   be multiple instances of this attribute in a CRO CSA when a next  hop
   can  be contacted for the same phone numbers using multiple signaling

     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

Squire                                                         [Page 13]

Internet Draft                    GLP                   16 February 1999

    |     GLP Attribute Type=1      |     GLP Attribute Length      |
    |          TCP/UDP Port         |  IP Protocol  | SigProtoIdLen |
    |             Signaling Protocol Identifier (variable)          |
    |      Additional Signaling Protocol Parameters (variable)      |

   GLP Attribute Type.
     Equals 1.

   GLP Attribute Length.
     Variable, even length.

   TCP/UDP Port.
     The TCP/UDP port that should be used to contact the  next-hop  when
     using the specified signaling protocol.

   IP Protocol.
     Indicates whether TCP (0x06) or UDP (x11) should be used to contact
     the next hop when using this signaling protocol.

   Signaling Protocol Identifier Length.
     The length of the Signaling Protocol Identifier field.

   Signaling Protocol Identifier.
     Identifies a signaling protocol that can be used to  contact  phone
     numbers  in  the  CRO's phone number range using the specified next
     hop.  The Signaling Protocol Identifier format is:
           sig-proto-id = "SIP" | "H323"

   Editor's Note.  Is there a standard method  of  expressing  signaling
   protocols  like  SIP  or  H.323 within a message?  Couldn't find them
   registered with IANA.

   Additional Signaling Protocol Parameters.
     This field can be used to specify additional  signaling  parameters
     needed  to  establish a connection using this signaling protocol to
     the specified next hop.  This attribute should contain  only  those
     signaling parameters required to establish a connection that cannot
     be expressed by any other GLP attribute.  Many signaling parameters
     can  be negotiated during the signaling process.  It is recommended
     that negotiable signaling  parameters  are  not  included  in  this
     attribute.   Limiting  the  number of signaling parameters improves
     scaleability  of  the  protocol.   The  format  of  this  field  is
     dependent on the signaling protocol.

Squire                                                         [Page 14]

Internet Draft                    GLP                   16 February 1999

   Editor's Note.   The  goal  of  this  last  field  is  to  allow  the
   expression  of any attributes that need to be given in order to allow
   the signaling to work.  Since signaling protocols  are  evolving,  we
   can't  cover everything in attributes.  This gives a back door to get
   needed  information  into  the  database.   If   this   approach   is
   acceptable,  then we need to define the formats of this field for SIP
   & H.323. Pricing Attribute

   The purpose of the Pricing Attribute is to provide information on how
   much a call to a phone number in the CRO's telephone range would cost
   a user.  The pricing attribute is sub-typed to yield several  methods
   of expressing the pricing details.

   The End Users must recognize the pricing attribute cannot be taken as
   a  guarantee  of  a particular service for a particular price.  Other
   factors may influence the actual amount  a  user  is  charged  for  a
   service.  Pricing structures may have too many variables to guarantee
   the accuracy of this data to the end user.  For example, the cost  of
   a  call  through a gateway may depend upon the source of the call (ie
   are you a customer of ISP-X?).  The cost may  also  depend  upon  the
   negotiated media capabilities.  Such variables complicate the pricing
   structures.  Other protocols (AAA, OTP, RSVP, etc) must  perform  the
   authentication,  negotiation,  accounting,  etc. required to actually
   negotiate and authorize the  final  charge  for  the  phone  service.
   There can be at most one Pricing Attribute in a CRO.

     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
    |     GLP Attribute Type=2      |     GLP Attribute Length      |
    |L| Pricing Attribute Subtype   |   Pricing Attribute Data Len  |
    |  Pricing Attr Originator Len  |            Reserved           |
    |                 Pricing Attribute Data (variable)             |
    |              Pricing Attribute Originator (variable)          |
    |               Pricing Attribute Signature (variable)          |

   GLP Attribute Type.
     Equals 2.

Squire                                                         [Page 15]

Internet Draft                    GLP                   16 February 1999

   GLP Attribute Length.
     Variable, even length.

   Pricing Attribute Subtype.
     The subtype may have either local significance or be  a  registered
     subtype  with IANA.  Local subtypes have the L-flag set, while IANA
     registered subtypes have the L-flag cleared.  The  purpose  of  the
     local  subtypes is so that within a ITAD, or within a confederation
     of ITADs, a pricing structure can be expressed in method  that  can
     be  automatically  interpreted  by a program (such as the LS policy
     decision process) to better automate the choice of next  hop.   The
     format of the data section differs for each subtype.

     The set of currently defined subtypes is:
            1 - Text
            2 - URL

   Editor's Note.  Any other suggestions on how to do pricing?

   Pricing Attribute Data Length.
     The length of the Pricing Attribute Data Field.  Must be even.

   Pricing Attribute Originator Length.
     The length of the Pricing Attribute Data Field.  Must be even.

   Pricing Attribute Data.
     The formats for the Pricing Attribute Data are given in  subsequent

   Pricing Attribute Originator.
     The originator of the Pricing Attribute.  A LS should not propagate
     a CRO if the originator of the pricing attribute is not trusted.

   Editor's Note.  Any suggestions on how to  handle  representation  of
   the  originator?   Company name?  Web page? Contact information? Some
   ITAD numeric representation?

   Pricing Attribute Signature.
     A digital signature that  can  be  used  to  authenticate  the  the
     validity   of   the   pricing  data.   In  the  event  of  a  false
     advertisement, the source of the false advertisement can be traced.
     The  pricing  attribute  signature  is  calculated  over the entire
     Pricing Attribute.  The pricing  attribute  may  be  signed  before
     being  advertised  by  an  LS.  If an LS does not alter the Pricing
     attribute data, it must not alter the originator or the  signature.
     If an LS does modify the Pricing attribute data, it must put itself
     as the originator and may sign the message as well.

Squire                                                         [Page 16]

Internet Draft                    GLP                   16 February 1999 Text

   This Pricing Attribute subtype contains a textual  description  of  a
   pricing   strategy.    The  intent  of  this  subtype  is  that  this
   description can be displayed to an end user.  The  character  set  is
   ISO 10646 using UTF-8 encoding [UTF8].

   Editor's Note.  If we want this, do we need to worry  about  language
   concerns?   I'd prefer to let language concerns be handled by the URL
   sub-type and let this sub-type be simple character representations. URL

   This Princing Attribute sub-type contains a URL from which additional
   pricing  data  may  be retrieved.  The intent of this subtype is that
   the URL may contain data that can be displayed to  the  end  user  or
   used by some automated selection process.  A pricing structure may be
   given  in  multiple  languages  using  an  HTTP  URL   and   language
   negotiation  as specified in HTTP [HTTP1.1].  URL formats are defined
   in [URL]. Gateway Provider

   The Gateway Provider attribute specifies  the  owner/provider  of  an
   egress  gateway to the PSTN indicated by this CRO.  The provider of a
   gateway may be used when selecting how to route  a  particular  call.
   There may be multiple Gateway Provider attributes in a CRO.

     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
    |     GLP Attribute Type=3      |     GLP Attribute Length      |
    |                  Gateway Provider (variable)                  |

   GLP Attribute Type.
     Equals 3.

   GLP Attribute Length.
     Variable, even length.

   Gateway Provider.
     The Gateway Provider field  specifies  the  owner/provider  of  the

Squire                                                         [Page 17]

Internet Draft                    GLP                   16 February 1999

     egress gateway for this CRO.

   Editor's Note.  We are now presented with  the  question  of  how  to
   represent  an  Internet  telephony  service  provider.   Two  obvious
   possibilities are using a numeric representation along the lines of a
   BGP  AS,  or  using  a  string representation along the lines of DNS.
   Could we use DNS names or do we need a new type  of  name?   Maybe  a
   URL? Next Hop Provider

   The next hop provider attribute specifies the owner/provider  of  the
   next  hop  SS  specified  by  this  CRO.   Like  the Gateway Provider
   attribute, the Next Hop Provider may be used  when  deciding  how  to
   route  a  particular call.  A single Next Hop Provider attribute must
   be in every CRO.

     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
    |     GLP Attribute Type=4      |     GLP Attribute Length      |
    |                       Next Hop Provider                       |

   GLP Attribute Type.
     Equals 4.

   GLP Attribute Length.
     Variable, even length.

   Next Hop Provider.
     The Next Hop Provider field specifies  the  owner/provider  of  the
     provider  of  the  next  hop signaling server listed in the CRO.  A
     single Next Hop Provider attribute must exist in every CRO.

   Editor's Note.  Again have to worry how to represent providers. Supported Codec

   This attribute is used to specify the codecs that are supported by an
   egress  gateway  that  can  be  reached via the next hop in this CRO.
   There may be multiple Supported Codec attributes in a CRO.

Squire                                                         [Page 18]

Internet Draft                    GLP                   16 February 1999

     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
    |     GLP Attribute Type=5      |     GLP Attribute Length      |
    |                   Supported Codec (variable)                  |

   GLP Attribute Type.
     Equals 5.

   GLP Attribute Length.
     Variable, even length.

   Supported Codec.
     Specifies an algorithm for the encoding and decoding of  packetized
     voice.   The  set  of  registered codec names is maintained by IANA
     [RFC1890].  Non-registered codecs are indicated  by  preceding  the
     name with "X-".  The format for the Supported Codecs field is:
            supported-codec  ; see [RFC1890] Capacity

   Gateways may have varying capabilities with regard to the  number  of
   phone calls that can be simultaneously processed.   The capacity of a
   gateway may be limited by link speed, memory, the number of circuits,
   etc.  The Capacity Attribute allows administrators to assign gateways
   a metric representative of their capacity.  The Capacity Attribute is
   a  relative  metric  to be used across a confederation of ITADs.  The
   determination of the capacity of a gateway as  communicated  by  this
   attribute  is  an  administrative matter.  The unitless nature of the
   Capacity Attribute makes it impossible to compare the capacity of two
   gateways   in  different  Internet  telephony  confederations.   This
   attribute can be used to load-balance connections between  a  set  of
   satisfactory  next-hops.   Note  that this metric is NOT a path cost,
   but a relative measurement of the capacity of the egress  gateway(s).
   This  attribute  is not intended to indicate any aspects of the real-
   time load on the gateway(s).   This  attribute  may  be  modified  by
   intermediate  LSs  when  performing aggregation or filtering of CROs.
   Only one Capacity Attribute is permitted in a CRO.

   The format of the Capacity attribute is given below.

     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
    |     GLP Attribute Type=6      |    GLP Attribute Length=8     |

Squire                                                         [Page 19]

Internet Draft                    GLP                   16 February 1999

    |                            Capacity                           |

   GLP Attribute Type.
     Equals 6.

   GLP Attribute Length.
     Equals 8.

     A relative measurement of the capacity  of  the  egress  gateway(s)
     represented  by  the  call routing object.  Represented as a 32-bit
     unsigned integer.  A larger value in the Capacity field  represents
     a  CRO  with  more  egress  gateway  capacity.   The  capacity of a
     gateway(s) is a relative value and cannot be  used  for  comparison
     between different Internet telephony confederations.

   Editor's Note.  We could define some unit(s) for the capacity metric.
   For  example,  bandwidth,  maximum  circuits, etc.  Defining multiple
   units complicates the comparison of two capacities  (ie  is  10  Mbps
   greater  than 20 circuits?), but makes the measurement more concrete.
   Suggestions? Time-To-Live

   The TTL attribute is used to  prevent  loop  detection.   A  LS  must
   decrement  the  TTL  of a CRO that it advertises to a peer in another
   administrative domain.  When aggregating multiple inbound CROs into a
   single outbound CRO, the aggregated CRO must have a TTL less than all
   of the CROs that served as input for the outbound CRO.  CROs  with  a
   TTL of zero must be ignored on receipt and should not be transmitted.
   Each CRO must contain a single TTL attribute.

   The format for the TTL Attribute is:

     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
    |     GLP Attribute Type=7      |    GLP Attribute Length = 8   |
    |                              TTL                              |

   GLP Attribute Type.
     Equals 7.

Squire                                                         [Page 20]

Internet Draft                    GLP                   16 February 1999

   GLP Attribute Length.
     Equals 8.

     The number of intermediate  LSs  through  which  this  CRO  may  be
     forwarded.   The default value for CROs originated within the local
     ITAD is XXXX (?).

   Editor's Note.  Might be better to use  a  loop  detection  algorithm
   more like BGP where we record the route of every entry.  Preferences?

   Editor's Note.  SCSP  doesn't  have  any  error  indication  defined.
   Should  we try to define one, or just have the application layer deal
   with errors.

   Editor's Note.  Instead of including all of the attributes  with  the
   call  routing  information  in  a  single  object,  we could put each
   attribute into its own object.  This would  allow  attributes  to  be
   updated  independently of the base call routing data (ie every update
   wouldn't have to include the entire  CRO),  but  would  require  more
   objects and the correlation of the objects.

6 Security Considerations

   SCSP has an Authentication Extension that can be appended to any SCSP
   message.   When  included  in  a  SCSP  message,  the  Authentication
   Extension provides  integrity  and  authentication  between  directly
   connected  peers.   It  is  recommended  that  GLP  speakers  use the
   Authentication Extension of SCSP to validate incoming GLP messages.

   LSs may also wish to provide confidentiality  for  their  transmitted
   data.   To  achieve confidentiality, peer LSs may communicate over an
   encrypted TCP connection.

7 IANA Considerations

     - scsp pid         - tcp port for scsp?
     - signaling protocols
     - internet telephony admin domains
     - other?

Squire                                                         [Page 21]

Internet Draft                    GLP                   16 February 1999

8 Conclusions

9 References

   [GLP-FR] J. Rosenberg and H. Schulzrinne, A Framework for  a  Gateway
   Location  Protocol,  Internet Draft, Internet Engineering Task Force,
   Work in Progress, 1999

   [BGP4] Y. Rekhter and T. Li, A border  gateway  protocol  4  (BGP-4),
   Request for Comments (Draft Standard) 1771, Internet Engineering Task
   Force, Mar. 1995.  (Obsoletes RFC1654).


   [SIP] SIP

   [H323] H323


   [HTTP1.1] HTTP 1.1

   [UTF8] ISO 10646 in UTF8 (rfc 2279)

   [RFC1890] RTP codec names & payload types

   [URL] URL formats

   [ISO4217] ISO 4217 (currency codes?)

Author's Address

   Matt Squire
   Nortel Networks
   4309 Emporer Blvd
   Suite 200
   Durham, NC 27703

   Phone: (919) 992-9048


Squire                                                         [Page 22]