[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                                     IETF
Internet Draft                                                  iptel WG
draft-ietf-iptel-glp-attribs-00.txt   J. Rosenberg, H. Salama, M. Squire
June 25, 1999                    Bell Labs/Cisco Systems/Nortel Networks
Expires: December, 1999


               Attributes for a Gateway Location Protocol

STATUS OF THIS MEMO

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

1 Abstract

   The Gateway Location Protocol (GLP) provides a mechanism for
   distributing and maintaining call routing tables between multiple
   internet telephony providers.  GLP is currently under development by
   the iptel WG.

   There have been multiple GLP proposals submitted to the IPTEL working
   group.  These proposals, although differing in some areas, have much
   common ground.  Specifically, the proposals each try to adapt many of
   the concepts from BGP for GLP, and have common themes in the areas of
   routing objects, route attributes, and route processing.  This draft
   offers recommendations based on the common areas in the current GLP
   proposals, covering the routing objects, route attributes, and route
   processing for GLP.  This draft represents a consensus among the
   multiple GLP proposals under consideration by the WG.

   Issues of transport and data synchronization are not considered in



Rosenberg,Salama,Squire                                         [Page 1]


Internet Draft               GLP Attributes                 25 June 1999


   this draft.  The data objects and their processing are considered
   independent of the transport and synchronization mechanisms.


2 GLP Overview and Background

   The Gateway Location Protocol (GLP) provides a mechanism for
   distributing and maintaining call routing tables between multiple
   internet telephony providers.  GLP is currently under development by
   the iptel WG.  An in-depth overview of GLP can be found in [1], but
   the framework is sketched here for convenience.

   There are several proposals for GLP under consideration by the iptel
   working group [2,3].  After discussions among the participants, it
   was clear that the proposals had a similar basic framework and view
   of the data objects that need to be distributed by GLP.  This draft
   addresses the definition and processing of the routing objects for
   GLP.

   GLP is 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.  Location Servers (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) [4] and the Open Shortest Path First (OSPF) [5] 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 scalability for inter-domain
   communications by permitting multiple border routers.  The general
   GLP model is depicted in Figure 1.

















Rosenberg,Salama,Squire                                         [Page 2]


Internet Draft               GLP Attributes                 25 June 1999



              ITAD1                                ITAD2
         -----------------                ------------------
        |                  |             |                  |
        |  ----            |             |           ----   |
        | | GW |           |             |          | EU |  |
        |  ----  -  ----   |             |  ----  /  ----   |
        |          | LS | ---------------- | LS |           |
        |  ----     ----   |             /  ----  -  ----   |
        | | GW | /         |            /|          | EU |  |
        |  ----            |           / |           ----   |
        |                  |          /  |                  |
         ------------------          /    ------------------
                                    /
                                   /
                        --------- /----------
                       |         |           |
                       |        ----         |
                       |       | LS |        |
                       |     /  ---- |       |
                       |  ----   ||   ----   |
                       | | GW |  ||  | EU |  |
                       |  ----   ||   ----   |
                       |  ----   ||   ----   |
                       | | GW | /  - | EU |  |
                       |  ----        ----   |
                       |                     |
                        ---------------------
                                 ITAD3


                       Figure 1.  General GLP Model

   A Location Server has access to a database of gateways, called the
   Gateway Information Base (GIB).  This database of gateways is
   constructed by combining the set of locally available gateways and
   the set of remote gateways (learned through GLP) based on policy.
   The LS also exports a set of gateways to its peer LSs in other ITADs.
   The set of exported gateways is constructed from the set of local
   gateways and the set of remote gateways (learned through GLP) based
   on policy.  As such, policy plays a central role in the LS operation.
   The internal model of a Location Server is shown in Figure 2.









Rosenberg,Salama,Squire                                         [Page 3]


Internet Draft               GLP Attributes                 25 June 1999



                          |
                          |Intra-domain protocol
                          |
                        Local
                       Gateways


   GLP-->  Gateways     POLICY     Gateways -->GLP
             IN                     Out
                          |
                          |
                       Gateway
                   Information Base


                 Figure 2.  Internal Location Server Model

   The gateway database contains a number of call routing objects.  The
   call routing objects received from other LSs via GLP serve as input
   to LS route processing, and the call routing objects advertised to
   other LSs and used for local routing decisions are the output of the
   LS route processing.  The LS route processing functions  include
   route origination, route selection, aggregation, and route
   dissemination.

   GLP is an application layer routing protocol for telephony signaling
   over IP networks.  Given a phone number (and possibly a set of
   attributes), an LS is capable of determining the next-hop signaling
   server to which signaling messages for that phone number should be
   forwarded.  This next-hop could be a terminating IP entity, an IP-
   PSTN gateway, or another signaling server.  The GLP attributes
   presented in this draft are concentrated on the signaling path and
   its properties.  The application of GLP for controlling aspects of
   the media path is an area for future investigation.

   An LS may represent a set of gateways in its administrative domain.
   An LS may have to inject new call routing objects into GLP for these
   gateways.  There are many potential methods for an LS to learn of the
   call routing objects that it should originate.  The methods include a
   front-end protocol, an intra-domain protocol, and static
   configuration.  The method by which an LS learns of new gateway
   information within its domain is outside the scope of GLP.  The
   process of injecting new gateway information into GLP, and
   determining the proper set of attributes for that information, is
   also known as route origination.

   An LS maintains the collection of call routing objects received from



Rosenberg,Salama,Squire                                         [Page 4]


Internet Draft               GLP Attributes                 25 June 1999


   other LSs via GLP.  An LS performs route selection on the set of
   received call routing objects.  Route selection is the process by
   which an LS chooses the routing objects out of this set to advertise
   to other LSs, and to use for local routing decisions.  The attributes
   of the candidate call routing objects are used by policy mechanisms
   within the LS to select certain routes for use and advertisement.

   Aggregation is a method of information reduction.  LSs may combine
   multiple call routing objects into a single call routing object in
   order to reduce the size of the database.  The ability to combine
   call routing objects, and the resultant call routing object, is
   dependent on the attributes of the component routing objects.

   An LS advertises selected routing objects to peer LSs.  The
   attributes included in advertised routing objects may not match the
   attributes that were included in the received routing object.  LSs
   may add, remove, or modify attributes before advertising a specific
   route.   Route dissemination is when an LS advertises selected call
   routing objects to its peers.


3 Overview of GLP Attributes

   Each call routing object consists of a number of attributes.  The
   primary attributes in any call routing object are the
   DestinationPhoneNumbers and NextHopSignalingServer attributes.  These
   attributes define a set of phone numbers and an address to which
   signaling messages destined for a phone number in that set should be
   sent.  These are analogous to the IP address prefix and a next-hop
   router in IP routing.

 3.1 TLV encoding

   Attributes are transported in a type-length-value encoding.  There is
   a flags field in the attribute that guides the processing of the
   attribute when the attribute is unrecognized.  Recognized attributes
   are processed according to their recognized definition.

 3.2 Attribute Types

   The following sections describe an initial set of attribute types
   recommended for GLP.  These attributes are defined in more detail in
   Section 4.

  3.2.1 DestinationPhoneNumbers

   This attribute defines the set of phone numbers described by the call
   routing object.  Each call routing object represents a limited range



Rosenberg,Salama,Squire                                         [Page 5]


Internet Draft               GLP Attributes                 25 June 1999


   of phone numbers as specified by an phone number prefix.

  3.2.2 NextHopSignalingServer

   This attribute gives the IP address of the entity to which signaling
   messages should be sent.  Unless further refined by the
   SignalingProtocols attribute, messages for any signaling protocol
   should be forwarded to this address.  Note that this is NOT the
   address to which the media (voice, video, etc.) should be
   transmitted.  Unlike BGP4 [4], the next-hop signaling server need not
   share a subnet with the LS, nor must an LS advertise only one of its
   own IP addresses as the next-hop.  An LS may advertise a next-hop
   with which it is not physically adjacent.

  3.2.3 AdvertisementPath

   The AdvertisementPath is analogous to the AS_PATH in BGP4 [4].  The
   attribute records the sequence of domains through which this object
   has passed.  The attribute is used to detect when the routing object
   is looping.  This attribute does NOT reflect the path through which
   signaling messages would traverse.  Since the next-hop need not be
   modified by each LS, the actual signaling path to the destination may
   not have to traverse every domain in the AdvertisementPath.

  3.2.4 GatewayCapacity

   All gateways are not created equal.  Some are large, capable of
   supporting hundreds or even thousands of simultaneous calls.  Others,
   such as residential gateways, may only support one or two calls.  The
   GatewayCapacity attribute may be used in route selection to select
   only those gateways with sufficient capacity.  The GatewayCapacity
   attribute might also be used to support a form of load balancing
   across gateways based on their relative capacities.

  3.2.5 SignalingProtocols

   GLP is designed to be independent of the signaling protocol used to
   establish multi-media sessions.  However, not all gateways and
   signaling servers will support all flavors of all signaling
   protocols.  The inclusion of the SignalingProtocols attribute is a
   refinement on the NextHopSignalingServer attribute to indicate that
   the next-hop is only valid for a certain set of signaling protocols.
   If this attribute is not present, it may be assumed that the next-hop
   can be used for any signaling protocol.

  3.2.6 Pricing

   The initiator of a voice session over the PSTN network may incur a



Rosenberg,Salama,Squire                                         [Page 6]


Internet Draft               GLP Attributes                 25 June 1999


   monetary charge for the PSTN services.  This attribute is used to
   advertise the charge for establishing and maintaining a session to
   the DestinationPhoneNumbers.  This cost generally reflects only those
   charges occurred after the egress gateway (ie on the PSTN network).
   Due to the complexity of the various pricing structures in use on the
   PSTN, this attribute is subtyped to yield a detailed pricing
   structure.  New pricing subtypes may be registered with ICANN using
   the procedures described in Section 7.  It is expected that the
   market requirements will drive the definition and implementation of
   new pricing structures.

  3.2.7 LastModifiedBy

   Call routing objects may be modified or propagated unchanged by an
   LS.  An LS may modify a routing object due to aggregation, it may
   filter an unknown attribute, it may add an attribute, or it may
   change the value of an existing attribute.  An LS that modifies
   certain attributes may include the LastModifiedBy attribute to
   indicate that this LS is the verifiable source of these attributes.
   The attributes that are covered by the LastModifiedBy attribute are
   identified by the LastModifiedByFlag as defined in Section 3.3.

  3.2.8 NumSignalingHops

   This attribute records the maximum and minimum number of signaling
   hops that a signaling message would have to be forwarded when using
   this routing object.  When an LS inserts a new NextHopSignalingServer
   for a call routing object, it increments the minimum and maximum
   number of signaling hops.   When an LS aggregates multiple routing
   objects into a single object, it recalculates the maximum and minimum
   number of signaling hops based on the aggregated routing objects.
   This attribute can be used to select a path with a shorter signaling
   path to the egress gateway.  Note that the media path is independent
   of the signaling path, and that this attribute does not describe
   anything about the media path.

  3.2.9 AtomicAggregate

   If an LS, when presented with a set of overlapping routes from a peer
   LS, selects the a specific route without selecting the more specific
   route, then the LS includes the AtomicAggregate attribute with the
   routing object.  An LS receiving a routing object with an
   AtomicAggregate attribute must not make make the set of destinations
   more specific when advertising it to other LSs.  The AtomicAggregate
   attribute indicates that a routing object may have traversed domains
   not listed in the AdvertisementPath.

  3.2.10 LocalPreference



Rosenberg,Salama,Squire                                         [Page 7]


Internet Draft               GLP Attributes                 25 June 1999


   The LocalPreference attribute is used to inform other LSs *within the
   same domain* of the local LSs preference for a given call routing
   object.  Other LSs within the same ITAD can use this attribute in
   their route selection process.  This attribute has no significance
   between domains.

  3.2.11 MultiExitDisc

   Two internet telephony administrative domains may be connected via
   more than one pair of LSs.  The MultiExitDisc attribute is used by an
   LS to express a preference for one link between the domains over
   another link.  The use of the MultiExitDisc attribute is controlled
   by local policy.

 3.3 Attribute Order

   An LS should order the attributes in any routing object numerically
   to facilitate faster operation.

 3.4 Mandatory Attributes

   Certain attributes are mandatory, ie they must be in every call
   routing object.  The DestinationPhoneNumbers attribute is an example
   of a mandatory attribute.  Mandatory attributes are identified in
   their definition.   Call routing objects that do not include all
   mandatory attributes are discarded.

 3.5 Attribute Flags

   It is clear that the set of attributes for GLP will evolve over time.
   Hence it is essential that mechanisms be provided to handle
   attributes with unrecognized types.  The handling of unrecognized
   attributes is controlled via the flags field of the attribute.
   Recognized attributes should be processed according to their specific
   definition.

   The following flags are recommended for GLP:

     Optional.  If set, the attribute is optional.  If not set, the
          attribute is well-known.  Every well-known attribute must be
          understood in order to process a routing object.

     Partial.  If set, indicates that the information in the attribute
          is partial.  Otherwise, the attribute is complete.  Partial
          attributes have not been processed by every LS along the
          relevant parts of the AdvertisementPath.

     IndependentTransitive.  If set, the attribute is an independent



Rosenberg,Salama,Squire                                         [Page 8]


Internet Draft               GLP Attributes                 25 June 1999


          transitive attribute.  IndependentTransitive attributes can be
          propagated by an LS even if they don't recognize the type.

     DependentTransitive.  If set, the attribute is an dependent transi-
          tive attribute.  DependentTransitive attributes can be pro-
          pagated by an LS even if they don't recognize the type only if
          the LS does not change the next-hop.

     LastModifiedByFlag.  If set, this attribute is covered by the Last-
          ModifiedBy attribute.  The source of this attribute can be
          authenticated by parsing the contents of the LastModifiedBy
          attribute.

   The transitivity flags only apply to optional attributes.  The tran-
   sitivity flags are ignored for well-known attributes.

  3.4.1 Attribute Flags and Route Selection

   The Optional flag determines whether an entire call routing object
   received from a peer should be processed or discarded.  If an LS
   receives a well-known attribute with an unrecognized type, then it
   must ignore the entire routing object.  If an LS receives an optional
   attribute with an unrecognized type, then it should process the rout-
   ing object according to the other flags.

   If a recognized attribute is received for which the flags are not
   properly set, that attribute should be ignored and not propagated.

   Any recognized attribute can be used as input to the route selection
   process, although the utility of some attributes in route selection
   is minimal.

  3.4.2 Attribute Flags and Route Dissemination

   GLP provides for two variations of transitivity due to the fact that
   intermediate LSs need not modify the NextHopSignalingServer when pro-
   pagating call routing objects.  Attributes may be non-transitive,
   dependent transitive, or independent transitive.  An attribute cannot
   be both dependent and independent transitive.  An attribute with both
   transitivity flags set should be ignored.

   Unrecognized *independent* transitive attributes may be propagated by
   any intermediate LS.  Unrecognized *dependent* transitive attributes
   may only be propagated if the LS is NOT changing the next-hop (given
   by the NextHopSignalingServer attribute).  The transitivity varia-
   tions permit some attributes to be carried end-to-end (independent
   transitive), some to be carried between adjacent next-hop signaling
   servers (dependent transitive), and other to be restricted to peer



Rosenberg,Salama,Squire                                         [Page 9]


Internet Draft               GLP Attributes                 25 June 1999


   LSs (non-transitive).

   An LS that passes an unrecognized transitive attribute to a peer must
   set the Partial flag on that attribute.  Any LS along a path may
   insert a transitive attribute into a call routing object.  If any LS
   except the originating LS inserts a new transitive attribute into a
   call routing object, then it must set the Partial flag on that attri-
   bute.  The Partial flag indicates that not every LS along the
   relevant path has processed and understood the attribute.  For
   independent transitive attributes, the "relevant path" is the path
   given in the AdvertisementPath attribute, while for dependent transi-
   tive attributes, it is only those domains that have passed this
   object since the NextHopSignalingServer was last modified.  The Par-
   tial flag in an independent transitive attribute must not be unset by
   any other LS along the path.  The Partial flag in a dependent transi-
   tive attribute must be reset whenever the next-hop is changed.

   The rules governing the addition of new non-transitive attributes are
   defined independently for each new non-transitive attribute.

   Any attribute may be updated by an LS in the path.

  3.4.3 Attribute Flags and Route Aggregation

   Each attribute defines how it is to be handled during route aggrega-
   tion.

   The rules governing the handling of unknown attributes are guided by
   the Attribute Flags.  Unrecognized transitive attributes are dropped.

   There should be no unrecognized non-transitive attributes during
   aggregation because non-transitive attributes must be processed by
   the local LS in order to be propagated.


     Editor's Note.  There are several options available to handle
     unrecognized transitive attributes during aggregation.  We can
     (a) drop them, (b) propagate them if they are binary
     equivalent, (c) define a set of aggregation operations and
     have these indicated by a flag(s) in the attribute (ie addi-
     tion, union, drop if !equal, etc.), (d) other suggestions?



4 Details of GLP Attributes

   This section provides a detailed description for each of the recom-
   mended attributes of GLP.  The processing of the attribute is



Rosenberg,Salama,Squire                                        [Page 10]


Internet Draft               GLP Attributes                 25 June 1999


   addressed in each of the following stages of route processing:  route
   origination, route selection, aggregation, and route dissemination.

 4.1 DestinationPhoneNumbers

   Mandatory: True.
   Flags: Well-known.

   The DestinationPhoneNumbers attribute describes the phone numbers
   that are covered by this call routing object.  If a phone number is
   covered by this call routing object, then this object can be used to
   reach that phone number.  Note that certain phone numbers or ranges
   may not exist on the PSTN, even though they are covered by this set.
   Black-holes (i.e., ranges of non-existant PSTN numbers) should not be
   advertised within GLP.

  4.1.1 Syntax of DestinationPhoneNumbers

   Phone numbers are represented by a string of digits giving a phone
   number prefix.  All phone numbers starting with this prefix are
   covered by this call routing object.

   The syntax for the phone number prefix is:
     phone-number-bound = +1*phone-digit
     phone-digit        = DIGIT
     DIGIT              = '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'

   This format is similar to the format for a global telephone number as
   defined in SIP [4] without visual separators.  This format facili-
   tates efficient comparison when using GLP to route SIP or H323, both
   of which use character based representations of phone numbers.


     Editor's Note.  This section is purposefully left somewhat
     vague due to the fact that one of the GLP proposals under con-
     sideration [2] uses an existing BGP extension to carry the
     this information and the next-hop, while the other proposal
     [3] would use new extensions for both.


  4.1.2 Route Origination and DestinationPhoneNumbers

   A gateway that can reach all valid numbers in the area code +1919
   should advertise +1919 as the DestinationPhoneNumbers, even though
   there may be more specific prefixes that do not actually exist on the
   PSTN.

   Destination phone numbers are injected into GLP by a method outside



Rosenberg,Salama,Squire                                        [Page 11]


Internet Draft               GLP Attributes                 25 June 1999


   the scope of GLP.  Possible methods include the front-end protocol,
   and intra-domain protocol, or static configuration.  The originating
   LS must include the DestinationPhoneNumbers in every call routing
   object.

  4.1.3 Route Selection and DestinationPhoneNumbers

   The destination phone numbers are a necessary criteria for route
   selection.

  4.1.4 Aggregation and DestinationPhoneNumbers

   To aggregate multiple call routing objects, the set of Destination-
   PhoneNumbers must combine to form a less specific set.  For example,
   the prefixes +19190, +19191, +19192, +19193, +19194, +19195, +19196,
   +19197, +19198, and +19199 could be aggregated to form the prefix
   +1919.

   In general, it takes ten (10) prefixes of length n to aggregate into
   a prefix of length n-1.  However, if an LS is aware that a prefix is
   an invalid PSTN prefix, then fewer more specific prefixes may be
   required.  For example, if the prefix +19191 is known not to exist,
   then an LS can aggregate to +1919 without +19191.  A prefix
   representing an invalid set of PSTN destinations is sometimes
   referred to as a "black-hole".   The method by which an LS is aware
   of black-holes is not within the scope of GLP.  It is recommended
   that an LS not explicitly advertise black-holes.


     Editor's Note.  We debated whether an LS should advertise
     black-holes within GLP, but came to the consensus that expli-
     cit black-hole advertisements should not be in GLP.  It seems
     unimportant whether signaling to an invalid number fails at
     the ingress, egress, or such an LS.  Knowledge of black-holes
     helps aggregation, but the best option seemed to be keeping
     the distribution of this knowledge outside of GLP.  Note that
     an LS cannot be prevented from advertising something it knows
     to be a black-hole.

     Editor's Note.  We were unable to reach consensus on the issue
     of "scope".  Using scope to geographically limit the distribu-
     tion of 800 numbers seemed like a bad idea, but there seems to
     be a need to map some non-unique numbers into a globally
     unique number space.  The disagreement over scope centered on
     whether one should apply this concept to just 800-type
     numbers, or to any private numbering space.  One camp believed
     that private numbers should not be advertised between domains,
     that the definition of private implied intra-domain only.  The



Rosenberg,Salama,Squire                                        [Page 12]


Internet Draft               GLP Attributes                 25 June 1999


     other camp believed that a confederation of providers may com-
     bine to provide a "VPN-like" service for handling private
     numbering spaces across domains, and hence that private
     numbers should be mapped into something globally unique and be
     carried between domains.  Comments?


  4.1.5 Route Dissemination and DestinationPhoneNumbers

   The DestinationPhoneNumbers attribute should be propagated to peers
   unchanged except by aggregation.


     Editor's Note.  The following alternative representation to
     prefixes was suggested.  Each digit position is represented by
     a 10-bit bitmask.  If digit position i has bit j set, then the
     digit j can appear in position i.  As an example, to
     [0100000000] represents all numbers starting with 1, and
     [0100000000, 0111111110] represents all numbers starting with
     11, 12, 13, ..., or 18.  This representation is very flexible
     with regards to aggregation, but its unclear how, given a
     phone number, one finds the 'most specific' match in an effi-
     cient manner.


 4.2 NextHopSignalingServer

   Mandatory: True.
   Flags: Well-known.

   The NextHopSignalingServer gives the address to which signaling mes-
   sages should be forwarded when routing a call using this object.

  4.2.1 NextHopSignalingServer Syntax

   For generality, the address of the next-hop signaling server may be
   of various types (IPv4, IPv6, etc).  The NextHopSignalingServer
   attribute includes an address type identifier, address length,  and a
   next-hop address.  The type of address is given by an Address Family
   Identifier as defined in RFC1700 [6].


     Editor's Note.  This section is purposefully left somewhat
     vague due to the fact that one of the GLP proposals under con-
     sideration [2] uses an existing BGP extension to carry the
     this information and the destination phone numbers, while the
     other proposal [3] would use new extensions for both.




Rosenberg,Salama,Squire                                        [Page 13]


Internet Draft               GLP Attributes                 25 June 1999


  4.2.2 Route Origination and NextHopSignalingServer

   When an LS originates a call routing object into GLP, it must include
   a NextHopSignalingServer within its domain.  The NextHopSignaling-
   Server could be an address of the egress gateway or of a signaling
   proxy.

  4.2.3 Route Selection and NextHopSignalingServer

   LS policy may prefer certain next-hops over others.


     Editor's Note:  Is it necessary to include the domain of the
     next-hop for policy applications?  Ie, is it a viable policy
     to prefer the next hop to be in domain X?  It may be possible
     to get the domain of the next-hop from the LastModifiedBy
     attribute, but this needs to be verified.  The SignalingPath
     attribute (Section 5.5) is another possible way to get this
     information.


  4.2.4 Aggregation and NextHopSignalingServer

   When aggregating multiple routing objects into a single routing
   object, an LS must insert a new signaling server from within its
   domain as the new NextHopSignalingServer.

  4.2.5 Route Dissemination and NextHopSignalingServer

   When propagating routing objects to peers, an LS may choose to insert
   an address of a signaling proxy within its domain as the new next-
   hop, or it may leave the next-hop unchanged.  Inserting a new address
   as the next-hop will cause the signaling messages to be sent to that
   address, and will provide finer control over the signaling path.
   Leaving the next-hop unchanged will yield a more efficient signaling
   path (ie fewer hops).  It is a local policy decision of the LS to
   decide whether to propagate or change the NextHopSignalingServer.

 4.3 AdvertisementPath

   Mandatory: True.
   Flags:  Well-known.

   The AdvertisementPath attribute is analogous to the AS_PATH attribute
   in BGP.  The attributes differ in that BGP's AS_PATH also reflects
   the path to the destination.  In GLP, the next-hop need not be modi-
   fied by every domain along the path, so the AdvertisementPath may
   include many more hops than the actual signaling path to the



Rosenberg,Salama,Squire                                        [Page 14]


Internet Draft               GLP Attributes                 25 June 1999


   destination.  The NumSignalingHops attribute reflects the number of
   signaling hops to the destination.

   This attribute identifies the ITADs through which routing information
   carried in an advertisement has passed.

  4.3.1 AdvertisementPath Syntax

   AdvertisementPath is a variable length attribute that is composed of
   a sequence of ITAD path segments. Each ITAD path segment is
   represented by a triple <path segment type, path segment length, path
   segment value>.

   The path segment type is a 1-octet long field with the following
   values defined:

     ValueSegment Type

     1. AP_SET: unordered set of ITADs a route in the advertisement mes-
        sage has traversed

     2. AP_SEQUENCE: ordered set of ITADs a route in the advertisement
        message has traversed


   The path segment length is a 1-octet long field containing  the
   number of ITADs in the path segment value field.

   The path segment value field contains one or more ITAD numbers, each
   encoded as a 2-octets long field.  ITAD numbers uniquely identify an
   Internet Telephony Administrative Domain, and must be obtained from
   IANA.  See Section 7.3 for procedures to obtain an ITAD number from
   IANA.

  4.3.2 Route Origination and AdvertisementPath

   When an LS originates a route then:

     a) The originating LS shall include its own ITAD number in the
     AdvertisementPath attribute of all advertisements sent to LSs
     located in neighboring ITADs.  In this case, the ITAD number of the
     originating LS's ITAD will be the only entry in the Adver-
     tisementPath attribute.

     b) The originating LS shall include an empty AdvertisementPath
     attribute in all advertisements sent to LSs located in its own
     ITAD.  An empty AdvertisementPath attribute is one whose length
     field contains the value zero.



Rosenberg,Salama,Squire                                        [Page 15]


Internet Draft               GLP Attributes                 25 June 1999


  4.3.3 Route Selection and AdvertisementPath

   The AdvertisementPath may be used for route selection. Possible cri-
   teria to be used are the number of hops on the advertisement path and
   the presence or absence of particular ITADs on the advertisement
   path.

  4.3.4 Aggregation and AdvertisementPath

   If routes to be aggregated have identical AdvertisementPath attri-
   butes, then the aggregated route has the same AdvertisementPath
   attribute as each individual route.

   For the purpose of aggregating AdvertisementPath attributes of two
   routes, we model each ITAD as a tuple <type, value>, where "type"
   identifies a type of the path segment the ITAD belongs to (e.g.
   AP_SEQUENCE, AP_SET), and "value" is the ITAD number.  Two ITADs are
   said to be the same if their corresponding <type, value> tuples are
   the same.

   For the purpose of aggregating AdvertisementPath attributes we model
   each ITAD within the AdvertisementPath attribute as a tuple <type,
   value>, where "type" identifies a type of the path segment the ITAD
   belongs to (e.g. AP_SEQUENCE, AP_SET), and "value" is the ITAD
   number.  If the routes to be aggregated have different Adver-
   tisementPath attributes, then the aggregated AdvertisementPath attri-
   bute shall satisfy all of the following conditions:

     - All tuples of the type AP_SEQUENCE in the aggregated Adver-
     tisementPath shall appear in all of the AdvertisementPath in the
     initial set of routes to be aggregated.

     - All tuples of the type AP_SET in the aggregated AdvertisementPath
     shall appear in at least one of the AdvertisementPath in the ini-
     tial set (they may appear as either AP_SET or AP_SEQUENCE types).

     - For any tuple X of the type AP_SEQUENCE in the aggregated Adver-
     tisementPath which precedes tuple Y in the aggregated Adver-
     tisementPath, X precedes Y in each AdvertisementPath in the initial
     set which contains Y, regardless of the type of Y.

     - No tuple with the same value shall appear more than once in the
     aggregated AdvertisementPath, regardless of the tuple's type.

   An implementation may choose any algorithm which conforms to these
   rules.  At a minimum a conformant implementation shall be able to
   perform the following algorithm that meets all of the above condi-
   tions:



Rosenberg,Salama,Squire                                        [Page 16]


Internet Draft               GLP Attributes                 25 June 1999


     - determine the longest leading sequence of tuples (as defined
     above) common to all the AdvertisementPath attributes of the routes
     to be aggregated. Make this sequence the leading sequence of the
     aggregated AdvertisementPath attribute.

     - set the type of the rest of the tuples from the AdvertisementPath
     attributes of the routes to be aggregated to AP_SET, and append
     them to the aggregated AdvertisementPath attribute.

     - if the aggregated AdvertisementPath has more than one tuple with
     the same value (regardless of tuple's type), eliminate all, but one
     such tuple by deleting tuples of the type AP_SET from the aggre-
     gated AdvertisementPath attribute.

   An implementation which chooses to provide a path aggregation algo-
   rithm which retains significant amounts of advertisement path infor-
   mation may wish to use the following procedure:

   For the purpose of aggregating AdvertisementPath attributes of two
   routes, we model each ITAD as a tuple <type, value>, where "type"
   identifies a type of the path segment the ITAD belongs to (e.g.
   AP_SEQUENCE, AP_SET), and "value" is the ITAD number.  Two ITADs are
   said to be the same if their corresponding <type, value> tuples are
   the same.

   The algorithm to aggregate two AdvertisementPath attributes works as
   follows:

     a) Identify the same ITADs (as defined above) within each Adver-
     tisementPath attribute that are in the same relative order within
     both AdvertisementPath attributes.  Two ITADs, X and Y, are said to
     be in the same order if either:
       - X precedes Y in both AdvertisementPath attributes, or
       - Y precedes X in both AdvertisementPath attributes.

     b) The aggregated AdvertisementPath attribute consists of ITADs
     identified in (a) in exactly the same order as they appear in the
     AdvertisementPath attributes to be aggregated. If two consecutive
     ITADs identified in (a) do not immediately follow each other in
     both of the AdvertisementPath attributes to be aggregated, then the
     intervening ITADs (ITADs that are between the two consecutive ITADs
     that are the same) in both attributes are combined into an AP_SET
     path segment that consists of the intervening ITADs from both
     AdvertisementPath attributes; this segment is then placed in
     between the two consecutive ITADs identified in (a) of the aggre-
     gated attribute. If two consecutive ITADs identified in (a) immedi-
     ately follow each other in one attribute, but do not follow in
     another, then the intervening ITADs of the latter are combined into



Rosenberg,Salama,Squire                                        [Page 17]


Internet Draft               GLP Attributes                 25 June 1999


     an AP_SET path segment; this segment is then placed in between the
     two consecutive ITADs identified in (a) of the aggregated attri-
     bute.

   If as a result of the above procedure a given ITAD number appears
   more than once within the aggregated AdvertisementPath attribute,
   all, but the last instance (rightmost occurrence) of that ITAD number
   should be removed from the aggregated AdvertisementPath attribute.


  4.3.5 Route Dissemination and AdvertisementPath

   When an LS propagates a route which it has learned from another LS,
   it shall modify the route's AdvertisementPath attribute based on the
   location of the LS to which the route will be sent:


     a) When a given LS advertises the route to another LS located in
        its own ITAD, the advertising LS shall not modify the Adver-
        tisementPath attribute associated with the route.

     b) When a given LS advertises the route to an LS located in a
        neighboring ITAD, then the advertising LS shall update the
        AdvertisementPath attribute as follows:

        1) if the first path segment of the AdvertisementPath is of type
           AP_SEQUENCE, the local system shall prepend its own ITAD
           number as the last element of the sequence (put it in the
           leftmost position).

        2) if the first path segment of the AdvertisementPath is of type
           AP_SET, the local system shall prepend a new path segment of
           type AP_SEQUENCE to the AdvertisementPath, including its own
           ITAD number in that segment.



 4.4 GatewayCapacity

   Mandatory: True.
   Flags: Well-known.

   The gateway capacity attribute is used to characterize the number of
   calls a gateway is capable of handling. In reality, a gateway's capa-
   city is dependent on many things, including the rates of its
   telephony interfaces (PRI, T1, T3), the rate of its IP interfaces
   (10Base-T, 100Base-T, T1), the number of codecs it can simultaneously
   support, the amount of memory and processing it has for handling



Rosenberg,Salama,Squire                                        [Page 18]


Internet Draft               GLP Attributes                 25 June 1999


   signaling, and local policy. Rather than breaking capacity into a
   complex function of all these factors, it is represented by a single
   metric - gateway capacity - in units of calls.

   The purpose of the metric is twofold.  First, it provides a useful
   input to route selection.  Secondly, it can serve as a means for load
   balancing.

   Its use as a tool for route selection is readily understood.  When
   presented with two routes which can reach the same phone prefixes, an
   LS might prefer to select the route with the larger capacity, and
   propagate that one.  The capacity metric can be used to drive more
   complex logic, limited only by the expressiveness of the policy at
   the LS.

   The capacity metric can also be used as a means for load balancing.
   Consider LS A, which has two routes to the same prefix P. The first
   route has a gateway capacity of 10, and the second route has a gate-
   way capacity of 20. LS A aggregates these two, and propagates a route
   with capacity 30 (see Section 4.4.5 for more details on aggregating
   this attribute).  When signaling messages arrive, the LS must decide
   which route to use.  Since the first gateway has twice the capacity
   of the second, it can send 2/3 of its calls to the first, and 1/3 to
   the second.  It can do so in a round-robin fashion, or through
   weighted hash functions on the call identifiers for each call.


     Editor's Note.  The exact methods for load-balancing require
     more work, but we believe load-balancing to be a valuable and
     important feature for GLP.


   Note, however, that the capacity attribute SHOULD NOT be treated as a
   guarantee on available capacity (i.e., that an LS can always initiate
   calls through a route so long as the number of calls is below the
   capacity), nor should it be treated as an absolute limit on capacity
   (i.e., that if an LS sends a call to a gateway, but there are already
   as many calls as indicated by the capacity, the next is rejected).
   Such guarantees can only be made through static division of capacity
   between peers, which is wasteful and difficult to administer. Furth-
   ermore, the aggregation procedures below are inexact, and the result-
   ing capacities can not carry the same guarantees as the original.

   For this reason, if a gateway has capacity C, it is acceptable for
   the originating gateway to advertise this gateway to two different
   peers, both with the capacity C.

  4.4.1 Capacity Syntax



Rosenberg,Salama,Squire                                        [Page 19]


Internet Draft               GLP Attributes                 25 June 1999


   The gateway capacity is an unsigned 32 bit quantity.

  4.4.2 Route Origination and Capacity

   The capacity attribute is mandatory in originated routes. It is set
   to the actual call capacity of the gateway, determined at the discre-
   tion of the administrator.

  4.4.3 Route Selection and Capacity

   The capacity attribute MAY be used as an input to route selection, as
   discussed above.

  4.4.4 Aggregation and Capacity

   Aggregation of the capacity attribute is non-trivial. The most
   simple-minded approach is to add the capacity attributes of two
   routes when aggregating. This approach is sensible when the prefixes
   are the same. However, when they are not, this approach makes less
   sense.  Consider two routes, A and B. Route A is to the prefix
   15551212 only, with capacity 100. Route B is to the prefix 1, with
   capacity 1.  Aggregating the prefixes is easy - the resulting aggre-
   gate prefix is 1.  However, the capacity is not really 101. Nearly
   all of the calls in this prefix will be routed to B, which only has
   capacity 1. As such, the process of aggregating capacity needs to
   take into consideration the relative size of phone prefixes being
   aggregated.

   The difficulty is that the call capacity in the aggregate is no
   longer uniform across the prefix space. As such, the meaning of capa-
   city must be redefined in such a way as to make sense for aggregates.
   The following definition appears sensible:

     Calls are made randomly and uniformly within the space of the
     prefix advertised by the route. The capacity C of the route is
     one less than the expected number of calls that can occur
     before the route runs out of space. The route runs out of
     space for a set of calls when it is impossible to distribute
     the calls to the component gateways in such a way that all
     calls can go through.

   Lets say an aggregate is composed of two non-overlapping prefixes p1
   and p2, of sizes w1 and w2 numbers respectively, and with capacities
   c1 and c2 respectively.  Here, size refers to the number of phone
   numbers covered by the prefix.  As calls are made to the aggregate,
   the calls fall within prefixes p1 and p2 with certain probabilities.
   So, if there are N calls, a certain number, on average, full within
   p1 (and thus go to the first gateway), and another number, on



Rosenberg,Salama,Squire                                        [Page 20]


Internet Draft               GLP Attributes                 25 June 1999


   average, fall within p2 (and thus go to the second gateway). The
   capacity of the aggregate is the number of calls N which cause either
   the first gateway or the second gateway to run out of room, on aver-
   age.

   Specifically, the probability of a call being within p1 is w1/(w1 +
   w2), and the probability of call being within p2 is w2/(w1+2). When
   there are N calls, there will be, on average, N*w1/(w1+w2) to the
   first prefix, and N*w2/(w1+w2) to the second prefix. The capacities
   of these prefixes are c1 and c2 respectively. Thus, the first prefix
   is exhausted, on average, when N = c1*(w1+w2)/w1, and the second pre-
   fix when N = c2*(w1+w2)/w2. The capacity of the aggregate (c3) is the
   minimum of these. So:

     c3 = min(c1*(w1+w2)/w1, c2(w1+w2)/w2)

   When w1 << w2, c3 = c2, and when w2 << w1, c3=c1. This is intuitive.
   The capacity of the aggregate is closest to the capacity of its larg-
   est component. When w1=w2 and c1=c2, c3=c1+c2, which is also intui-
   tive.

   When the prefixes overlap, the result is different. Assume prefix p2
   is completely within prefix p1. In this case:

     c3 = min(c1*w1/(w1-w2), (c1+c2)*w1/w2)

   Note that in this case, the primary attribute being aggregated is the
   Capacity attribute, not on the DestinationPhoneNumbers attribute.

   So how are w1 and w2 computed? In the case of IP addresses, a prefix
   of M bits contains 2^(32-M) addresses. This is because IP addresses
   are a fixed length of 32 bits. However, phone number prefixes are of
   variable length. Fortunately, the exact size of the prefix does not
   matter. In all of the computations above, it is only the relative
   sizes that are important. So, assume that phone numbers prefixes can
   have at most K digits. In that case, a prefix with d digits is of
   size 10^(K-d). So, with w1 = 10^(K-d1) and w2 = 10^(K-d2), the first
   of the above two equations becomes:

     c3 = min(c1*(10^(K-d1)+10^(K-d2))/10^(K-d1),
              c2*(10^(K-d1)+10^(K-d2))/10^(K-d2))

   Factoring out the 10^K term:

     c3 = min(c1*(10^-d1 + 10^-d2)/10^-d1,
              c2*(10^-d1 + 10^-d2)/10^-d2)        (Eq. 1)

   This means that the actual size of the prefix does not matter, as far



Rosenberg,Salama,Squire                                        [Page 21]


Internet Draft               GLP Attributes                 25 June 1999


   as capacity computations are concerned. Only the relative sizes are
   important. Performing the same computation for the second capacity
   expression:

     c3 = min(c1*(10^-d1)/(10^-d1 - 10^-d2),
              (c1+c2)*10^-d1/10^-d2)              (Eq. 2)

   When performing aggregation of capacity metrics, Eq. 1 SHOULD be used
   when the prefixes being aggregated do not overlap, and Eq. 2 SHOULD
   be used when the second prefix is completely encompassed within the
   first.  If an LS has more precise information about the size of a
   prefix or the probability distribution of calls, it MAY use alternate
   means to compute the aggregated capacity.  These equations should be
   applied iteratively when the set being aggregated contains more than
   two prefixes.

  4.4.5 Route Dissemination and Capacity

   The capacity attribute represents the call handling capacity of the
   gateway itself. This says nothing about the capacity of the media
   path or of the capacity of the signaling path. However, an intermedi-
   ate LS MAY modify the gateway capacity if it modifies the next hop,
   to reflect any known restrictions in capacity from the signaling and
   or media paths. An LS MAY increase or decrease the capacity, but it
   is RECOMMENDED that an LS only decrease it. If an LS propagates a
   route but does not modify the next hop, it SHOULD NOT modify the
   capacity.

 4.5 SignalingProtocols

   Mandatory: False.
   Flags: Optional, DependentTransitive.

   The signaling protocols attribute specifies the signaling protocols
   and key signaling protocol parameters that are understood by the next
   hop signaling server. It is always re-originated by an LS which modi-
   fies the next hop, to reflect the capabilities of that next hop.

   The attribute contains both the basic protocol (currently, codepoints
   exist for SIP, H.323/Q.931 and H.323/RAS; others can be registered
   with ICANN), and parameters of that protocol necessary to determine
   interoperability or required for signaling exchange. Specifically,
   this includes transport protocols (TCP or UDP), port numbers, and
   ISUP-variants. The ISUP-variants component is present since some sig-
   naling protocols, such as SIP, can carry ISUP messages in their
   bodies. These ISUP messages are analyzed, processed, and potentially
   translated by intermediate  signaling servers. As such, it is impor-
   tant to know what ISUP variants, if any, are supported by a signaling



Rosenberg,Salama,Squire                                        [Page 22]


Internet Draft               GLP Attributes                 25 June 1999


   server.

  4.5.1 SignalingProtocols Syntax

   The signaling protocols attribute is a set of TLV objects. The type
   field is one byte, length is two bytes, and value has the length
   specified by the length field. Some objects may appear more than
   once.  Whether this is allowed, and the meaning when this happens,
   depends on the type.


     Editor's Note:  We should probably make each signalling proto-
     col into its own attribute because much of the related infor-
     mation is specific to one particular signalling protocol.  For
     example, the UDP port numbers will likely be different if a
     single server supports both SIP & H323.


   4.5.1.1 Base Protocol

   The base protocol object is variable length, as indicated by the
   length field. In indicates the base signaling protocols supported.
   Each protocol is indicate by a single byte. Thus, if three signaling
   protocols are supported, the length of the object is three bytes.
   Currently defined values are:


       0: SIP
       1: H323/Q.931
       2: H323/RAS


   Others can be registered with IANA as needed.

   4.5.1.2 Transport Protocol

   The transport protocol object is variable length, as indicated by the
   length field. In indicates the base transport protocols supported.
   Each protocol is indicate by a single byte. Thus, if two transport
   protocols are supported, the length of the object is two bytes.
   Currently defined values are:

       0: UDP
       1: TCP


   Others may be defined in future versions of GLP as needed.




Rosenberg,Salama,Squire                                        [Page 23]


Internet Draft               GLP Attributes                 25 June 1999


   4.5.1.3 ISUP flavors supported

   The ISUP flavors protocol object is variable length, as indicated by
   the length field. It contains a number of ISUP flavors, each of which
   is a NULL terminated string. These strings are the ISUP flavor type
   names registered with IANA.


     Editors Note: This registry doesn't exist right now, but its
     not really a GLP specific thing. So, its not clear whether
     registration procedures should be established here or else-
     where.


   4.5.1.4 Port Number

   The port number object is a single, 16 bit quantity. It represents
   the port number to use for the signaling. If not specified, the
   default port for the signaling protocol is used.

  4.5.2 Route Origination and SignalingProtocols

   Routing objects MAY be originated with a signaling types attribute.
   If not present, it is assumed that the signaling protocol is deter-
   mined out of bands by some other means (i.e., a closed network of GLP
   peers may be a strictly H.323 or SIP network), and all other parame-
   ters take their defaults.

  4.5.3 Route Selection and SignalingProtocols

   Signaling types MAY be used as an input to route selection. Possible
   criteria include the base protocol itself and ISUP variants under-
   stood.

  4.5.4 Route Aggregation and SignalingProtocols

   The signaling type attribute is never aggregated. When the next hop
   signaling server changes (as it must when aggregation occurs), the
   signaling protocol attribute MUST be changed to reflect the capabili-
   ties of the local signaling server.

  4.5.5 Route Dissemination and SignalingProtocols

   When the next hop is unchanged, the LS MUST NOT modify the signaling
   type attribute. When the LS changes the next hop signaling attribute,
   it MUST modify the signaling types attribute to reflect the capabili-
   ties of the new path.  An LS must have knowledge of the signaling
   capabilities of the next-hop when inserting a SignalingProtocols



Rosenberg,Salama,Squire                                        [Page 24]


Internet Draft               GLP Attributes                 25 June 1999


   attribute into a routing object with that next-hop.  When advertising
   a signaling protocol as being supported by a next-hop, the LS must
   also ensure that the signaling protocol is supported by the entire
   path.  As an example, an LS must not insert a SignalingProtocols
   attribute advertising SIP is supported by the next-hop unless the
   next-hop supports SIP AND either
     - the inbound routing object also advertised SIP, or
     - the next-hop is known to support translation from SIP into a sig-
     naling protocol supported by the previous hop.

 4.6 Pricing

   Mandatory: False.
   Flags: Well-known.

   The pricing attribute conveys information about the cost of terminat-
   ing calls at a gateway.  The pricing reflects the cost of the PSTN
   component of the call only.  The actual cost of a completing a call
   to a gateway might include costs for media transport, but these are
   outside the scope of this attribute.

   When the cost attribute is sent in a route from A to B, it indicates
   the amount that A will charge B for calls along the route.  As such,
   the pricing attribute is non-transitive - it has significance only
   between peers.  This is in line with the GLP model overall, since two
   LS's communicate only when their administrators have established
   administrative agreements with each other.

   Since pricing is at the discretion of the provider, GLP does not res-
   trict the pricing models that can be used. It provides a common set
   of pricing mechanisms. Additional ones can be registered with ICANN
   and used, as needed. The common pricing mechanisms provided are:
     * connect charge plus per minute rate

  4.6.1 Pricing Syntax

   The capacity attribute contains a 16 bit sub-type field and a vari-
   able length value. The sub-type field indicates the specific type of
   cost. Several sub-types are defined here. Others can be registered
   with ICANN. The value depends on the sub-type.

   4.6.1.1 Subtype 0: connect charge plus per minute rate

   The value field contains a 32 bit currency value, a 32 bit floating
   point connect charge value, and a 32 bit floating point per minute
   rate value.

   Currency values can be registered with ICANN. Some common types are



Rosenberg,Salama,Squire                                        [Page 25]


Internet Draft               GLP Attributes                 25 June 1999


   provided here. They include:
     0: US Dollar
     1: Japanese Yen
     2: British Pound
     3: Euro
     4: German Deutchmark
     5: French Franc
   Procedures for registering additional currency types are given in
   section 7.4.

   The currency value has the same syntax and semantics as described
   above. The connect charge value indicates the number of units of the
   currency charged for each call completed. The per minute rate value
   indicates the number of units of the currency charged per minute in
   addition to the connect rate.


     Editor's Note.  We believe currency codes are already
     used/defined in other IETF documents (OTP?).  We should use
     the same currency codes if possible.  Registering new codes is
     only required if we have to define them.

     Editor's Note.  We need to specify a floating point represen-
     tation.

     Editor's Note.  We probably need to provide a time unit as
     well because different plans have different time units (ie the
     rate gets incremented every 6 seconds, every minute, etc).  We
     should look at ITU SG16 Annex G for a good example.


  4.6.2 Route Origination and Pricing

   Routes originating by an LS may contain a Pricing attribute.  It is a
   local policy issue whether the Pricing attribute is included in ori-
   ginated call routing objects, and what the Pricing attribute con-
   tains.

  4.6.3 Route Selection and Pricing

   Route selection is definitely driven by the Pricing attribute. An LS
   may decide to prefer routes that are cheaper, for example.

  4.6.4 Aggregation and Pricing

   The Pricing attribute is never aggregated. It is always re-originated
   at each LS. This is because it represents a charging agreement
   between the sending LS and the receiving LS. The Pricing attribute



Rosenberg,Salama,Squire                                        [Page 26]


Internet Draft               GLP Attributes                 25 June 1999


   re-originated at each LS may bear no resemblance at all to the Pric-
   ing attribute received by that LS for the same route, or it may be
   identical.

  4.6.5 Route Dissemination and Pricing

   When an LS disseminates a route, it must re-originate the pricing
   attribute as if it had created the route itself.


     Editor's Note:  Should we relax these rules a bit? Can an LS
     propagate the pricing attribute if it doesn't change the next
     hop? This would allow the LastModifiedBy attribute to contain
     a signature for the pricing attribute as well.  Should a LS be
     allowed to alter the Pricing attribute if it is not altering
     the next-hop?  In this case, its not on the signalling path,
     so how would payment be received?

     Editor's Note.  There a some possible methods for handling
     aggregation and route propagation of the Pricing attribute
     that might be worth investigation.   The attribute itself
     might indicate its processing.  For example, it could refer-
     ence a Java applet, or could be written in a well-known
     language like TCL or XML so that the data itself defines its
     properties.  This possibility would definitely need more
     investigation.

     Editor's Note.  It would seem beneficial if the Pricing attri-
     bute subtypes could be negotiated during peer session estab-
     lishment, so that an LS uses a pricing language understood by
     its peer.


 4.7 LastModifiedBy

   Mandatory: False.
   Flags: Well-known.

   The LastModifiedBy attribute provides information about the last LS
   that modified certain attributes of an advertisement. It also con-
   tains information to authenticate these attributes.

   GLP will provide a mechanism for hop-by-hop authentication between
   GLP peers.  Peer-to-peer authentication is independent of the data
   elements.

   Some GLP attributes are for GLP's internal use, e.g. LocalPreference,
   AtomicAggregate, and MultiExitDisc.  For these, hop-by-hop



Rosenberg,Salama,Squire                                        [Page 27]


Internet Draft               GLP Attributes                 25 June 1999


   authentication is sufficient.  However, attributes that are passed to
   the application in response to a call routing query probably require
   end-to-end authentication, or at least authentication since the last
   point of modification. For example, end-to-end authentication is not
   possible after route aggregation.  In this case, authentication from
   the point of aggregation is the best possible.  It is a local policy
   decision to determine whether authentication of received attributes
   is necessary.  It is also a local policy decision to determine
   whether to add or propagate the LastModifiedBy attribute, and which
   attributes should be covered by the authentication.  The attributes
   requiring authentication since the last modification point will prob-
   ably include:
     - DestinationPhoneNumbers
     - NextHopSignalingServer
     - SignalingProtocols
     - GatewayCapacity
     - Pricing
     - LastModifiedBy

   When computing the authentication data, an LS must consider only
   those attributes with the LastModifiedByFlag set, and must consider
   these in numerical order.

  4.7.1 LastModifiedBy Syntax

   The LastModifiedBy attribute is a variable length attribute. It con-
   sists of:
     (1) Type of LS identifier, 1 byte
     (2) Length of LS identifier, 1 byte
     (3) ITAD number of LS, 2 bytes (similar to BGP ASes)
     (4) LS identifier, variable
     (5) Authentication data, variable

   The detailed format of these fields are TBD.


     Editor's Note.  The intent of this attribute is to allow an LS
     to 'sign' certain attributes.  Receivers must be able to ver-
     ify this signature, so some type of identification of the pro-
     vider must be provided.  This might be an IPv4 address, an
     IPv6 address, a DNS name, etc.  The LS-type above should
     define what kind of identifier is provided (IPv, IPv6, DNS,
     etc.), and the identifier should carry that value.


  4.7.2 Route Origination and LastModifiedBy

   When an LS originates a call routing object into GLP, it may include



Rosenberg,Salama,Squire                                        [Page 28]


Internet Draft               GLP Attributes                 25 June 1999


   the LastModifiedBy attribute. If the LastModifiedBy attribute is
   included, the the LastmodifiedByFlag must be set for all attributes
   included in the LastModifiedBy authentication.

  4.7.3 Route Selection and LastModifiedBy

   The LS identifier and the ITAD number field of the LastModifiedBy
   attribute may be used a route selection criteria.

  4.7.4 Aggregation and LastModifiedBy

   The aggregating LS may choose to include the LastModifiedBy attribute
   in an aggregated object.  The aggregating LS may select those attri-
   butes covered by the inserted LastModifiedBy attribute, and must set
   the LastModifiedBy flags accordingly.

  4.7.5 Route Dissemination and LastModifiedBy

   The values of the LastModifiedBy attribute must be recalculated
   before disseminating the route whenever:
     * The LastModifiedByFlag of an attribute changes, or
     * an attribute for which the LastModifiedByFlag is set changes.

 4.8 NumSignalingHops

   Mandatory: False.
   Flags: Optional, DependentTransitive.

   The NumSignalingHops attribute records the number of signaling hops
   between the local LS and the destination.  The primary purpose of
   this attribute is as a criteria for route selection.


     Editor's Note.  As an alternative to NumSignalingHops, a Sig-
     nalingPath attribute was considered.  The SignalingPath attri-
     bute would be much like the AdvertisementPath, except it would
     only be updated when the next-hop changed.  Thus, it would
     record the signaling path to the destination.  It was not
     clear whether the SignalingPath attribute would be more useful
     than simply counting the number of hops, so for simplicity we
     went with the NumSignalingHops attribute.  Would a Signaling-
     Path attribute be useful enough in policy to justify the added
     complexity?


  4.8.1 NumSignalingHops Syntax

   The NumSignalingHops attribute contains two unsigned 16-bit numeric



Rosenberg,Salama,Squire                                        [Page 29]


Internet Draft               GLP Attributes                 25 June 1999


   values, the minNumSignalingHops and maxNumSignalingHops.  Due to
   aggregation, a single call routing object may represent paths of
   varying lengths.  The minimum and maximum give bounds on the lengths
   of these paths.

  4.8.2 Route Origination and NumSignalingHops

   When a LS originates a route into GLP, it may include the NumSig-
   nalingHops attribute with the minNumSignalingHops and maxNumSig-
   nalingHops set to zero (0).

  4.8.3 Route Selection and NumSignalingHops

   This attribute may be used in route selection to select routes with
   shorter signaling paths.

  4.8.4 Aggregation and NumSignalingHops

   When aggregating multiple routing objects into a single call routing
   object, an LS may choose to propagate the NumSignalingHops attribute.
   If it chooses to do so, the LS must propagate the minimum of the min-
   NumSignalingHops and the maximum of the maxNumSignalingHops in the
   NumSignalingHops attribute of the aggregated object.

  4.8.5 Route Dissemination and NumSignalingHops

   Intermediate LSs that alter the NextHopSignalingServer must increment
   the minimum and maximum values before propagating the NumSig-
   nalingHops attribute.  Intermediate LSs that do not modify the Nex-
   tHopSignalingServer attribute should not modify this attribute.

 4.9 AtomicAggregate

   Mandatory: False.
   Flags: Well-known.

   The AtomicAggregate attribute indicates that a routing object may
   have traversed domains not listed in the AdvertisementPath.  If an
   LS, when presented with a set of overlapping routes from a peer LS,
   selects the less specific (ie more phone number destinations) route
   without selecting the more specific route, then the LS includes the
   AtomicAggregate attribute with the routing object.

  4.9.1 AtomicAggregate Syntax

   This attribute has length zero (0).

  4.9.2 Route Origination and AtomicAggregate



Rosenberg,Salama,Squire                                        [Page 30]


Internet Draft               GLP Attributes                 25 June 1999


   Call routing objects are never originated with the AtomicAggregate
   attribute.

  4.9.3 Route Selection and AtomicAggregate

   The AtomicAggregate attribute may be used in route selection - it
   indicates that the AdvertisementPath may be incomplete.

  4.9.4 Aggregation and AtomicAggregate

   If any of the call routing objects to aggregate has the AtomicAggre-
   gate attribute, so should the resultant aggregated object.

  4.9.5 Route Dissemination and AtomicAggregate

   If an LS, when presented with a set of overlapping routes from a peer
   LS, selects the less specific (ie more phone number destinations)
   route without selecting the more specific route, then the LS includes
   the AtomicAggregate attribute with the routing object (if its not
   already present).

   An LS receiving a routing object with an AtomicAggregate attribute
   must not make the set of destinations more specific when advertising
   it to other LSs, and must not remove the attribute when propagating
   this object to a peer LS.

 4.10 LocalPreference

   Mandatory: False.
   Flags: Well-known.

   The LocalPreference attribute is used intra-domain only, it indicates
   the local LS's preference for the routing object to other LSs within
   the same domain.  This attribute should not be included when communi-
   cating to an LS in another domain.

  4.10.1 LocalPreference Syntax

   The LocalPreference attribute is a 4-octet unsigned numeric value.  A
   higher value indicates a higher preference.

  4.10.2 Route Origination and LocalPreference

   Call routing objects should not be originated with the LocalPrefer-
   ence attribute.

  4.10.3 Route Selection and LocalPreference




Rosenberg,Salama,Squire                                        [Page 31]


Internet Draft               GLP Attributes                 25 June 1999


   The LocalPreference attribute allows one LS in a domain to calculate
   a preference for a route, and to communicate this preference to other
   LSs in the domain.  During route selection, a LS may determine its
   own preference for a call routing object, or it may use the
   LocalPreference attribute as its preference (if included).

  4.10.4 Aggregation and LocalPreference

   The LocalPreference attribute is not affected by aggregation.  The
   inclusion of this attribute must follow the rules in Section 4.10.5.

  4.10.5 Route Dissemination and LocalPreference

   An LS must include the LocalPreference attribute when communicating
   with peer LSs within its own domain.  An LS must not include the
   LocalPreference attribute when communicating with LSs in other
   domains.  LocalPreference attributes received from inter-domain peers
   must be ignored.

 4.11 MultiExitDisc

   Mandatory: False.
   Flags: Optional, non-transitive.

   When two ITADs are connected by more than one set of peers, the Mul-
   tiExitDisc attribute may be used to specify preferences for routing
   objects received over one of those links over the others.  The Mul-
   tiExitDisc parameter is used in route selection.

  4.11.1 MultiExitDisc Syntax

   The MultiExitDisc attribute carries a 4-octet unsigned numeric value.
   A lower value represents a more preferred routing object.

  4.11.2 Route Origination and MultiExitDisc

   Call routing objects should not be originated with the MultiExitDisc
   attribute.

  4.11.3 Route Selection and MultiExitDisc

   The MultiExitDisc attribute is used to express a preference when
   there are multiple links between two domains.  If all other factors
   are equal, then a routing object with a lower MultiExitDisc attribute
   should be preferred over a routing object with a higher MultiExitDisc
   attribute.

  4.11.4 Aggregation and MultiExitDisc



Rosenberg,Salama,Squire                                        [Page 32]


Internet Draft               GLP Attributes                 25 June 1999


   Call routing objects with differing MultiExitDisc parameters must not
   be aggregated.  Call routing objects with the same value in the Mul-
   tiExitDisc attribute may be aggregated and the same MultiExitDisc
   attribute attached to the aggregated object.

  4.11.5 Route Dissemination and MultiExitDisc

   If received over from a peer LS in another domain, a LS may propagate
   the MultiExitDisc to other LSs within its domain.  The MultiExitDisc
   attribute should not be propagated to LSs in other domains.

   An LS may add the MultiExitDisc attribute when propagating routing
   objects to an LS in another domain.  The inclusion of the MultiExit-
   Disc attribute is a matter of policy, as is the value of the attri-
   bute.


5 Recommended Non-Attributes

   In addition to the attributes mentioned in Section 4, many other
   attributes were under consideration for inclusion into GLP.  In this
   section, we briefly mention these attributes, and why they weren't
   recommended for GLP in this draft.

   Some of the criteria used to select recommended attributes were:

    (a) If a value can be determined via signaling protocols, then it
        was not recommended.

    (b) If there were no good suggestions on how to aggregate it, it was
        not recommended.

 5.1 Origin

   BGP4 has an Origin attribute, which indicates whether the route ori-
   ginated from within the originating AS, or via a different exterior
   routing protocol.  With GLP, there are no other existing routing pro-
   tocols, either interior or exterior, so Origin has no current func-
   tion in GLP.

 5.2 CodecsSupported

   The CodecsSupported attribute was considered to indicate the codes
   supported for the media path by the egress gateway(s).

   The codec to use for an RTP session can often be negotiated during
   signaling.  For this reason, in addition to an effort to "keep it
   simple, stupid" (KISS), CodecsSupported is not recommended.



Rosenberg,Salama,Squire                                        [Page 33]


Internet Draft               GLP Attributes                 25 June 1999


 5.3 EncryptionAlgsSupported

   Like CodecsSupported, the EncryptionAlgsSupported was considered to
   indicate the encryption algorithms supported by the egress gateway.

   This attribute is not recommended for the same reasons as the
   CodecsSupported attribute.

 5.4 TelephonyFeaturesSupported

   Like CodecsSupported, the TelephonyFeaturesSupported was considered
   to indicate the telephony features supported by the egress gateway.
   Potential telephony features considered were multi-party conferencing
   and video conferencing.

   This attribute is not recommended for the same reasons as the
   CodecsSupported attribute.

 5.5 SignalingPath

   The SignalingPath attribute was considered to record the signaling
   hops in the same way that the AdvertisementPath records the domains
   that the routing object has traversed.  This attribute was targeted
   at route selection so that the administrator may choose shorter sig-
   naling paths or choose paths that go through certain domains.

   In an effort to simplify, the NumSignalingHops attribute is recom-
   mended instead.  If the SignalingPath attribute can be demonstrated
   to be more useful than the NumSignalingHops attribute, then Sig-
   nalingPath may replace NumSignalingHops.

 5.6 SignalingPathCapacity

   The GatewayCapacity attribute indicates the relative size of egress
   gateways.  The SignalingPathCapacity was suggested as an analog to
   the GatewayCapacity so that the signaling path could also be taken
   into consideration in route selection and load balancing.

   In general, the capacity of a signaling path is going to be limited
   by that of the egress gateways, so the usefulness of this metric was
   not demonstrated.  Also, LSs could modify the GatewayCapacity attri-
   bute so that the signaling path is taken into account.

 5.7 MediaPathCapacity

   The MediaPathCapacity attribute was considered as another potential
   analog of GatewayCapacity, providing a metric on the size of the data
   path to the egress.



Rosenberg,Salama,Squire                                        [Page 34]


Internet Draft               GLP Attributes                 25 June 1999


   This metric is only possible if the media path is tied to the signal-
   ing path.  In general, this is not true because the media may go
   directly to the egress gateway even if the signaling goes to a proxy
   server.  So this attribute was not recommended.

 5.8 GatewayProvider, NextHopProvider, Aggregator

   These attributes were intended to identify (perhaps in an authenti-
   cated manner) certain important domains along the advertised path,
   sometimes in an authenticated manner.

   Most of the function of these attributes is provided by the LastModi-
   fiedBy attribute, so these attributes were not recommended.

 5.9 Lifetime

   The Lifetime attribute was considered so that gateways could adver-
   tise the times at which certain routing objects are valid.  For exam-
   ple, a gateway could indicate that a certain route (and the associ-
   ated price, etc) is only valid between the hours of 10:00 pm and 6:00
   am.

   Explicitly adding and removing routing objects seemed preferable to
   giving attributes Lifetimes, which would have required periodically
   sweeping the call routing table to remove and insert expired entries.

 5.10 Time-To-Live

   The Time-To-Live attribute was considered to limit the number of hops
   that a routing object may propagate.  If LS peering relationships had
   some geographic significance, then the TTL attribute could be used to
   limit how far the information propagates.  Such an attribute might be
   useful for certain "800" type services.

   Without a clearly demonstrated benefit for the TTL attribute, it was
   decided to not recommend this attribute for now.  However, the rela-
   tive simplicity in supporting the attribute makes the attribute a
   good candidate to bring back of a clear need can be demonstrated.

6 Security Considerations

   Peer-to-peer security (between adjacent LSs) is assumed to be pro-
   vided by the transport protocol.

   Security between LSs that are not adjacent is provided in two ways.
   First, the transitivity of the peer relationship provides some level
   of security.  Second, the LastModifiedBy attribute can be used to
   sign a set of attributes, so that the receivers of the attributes can



Rosenberg,Salama,Squire                                        [Page 35]


Internet Draft               GLP Attributes                 25 June 1999


   verify the authenticity of certain attributes.

7 IANA Considerations

   This section discusses IANA registration procedures for parameters
   defined in GLP.

 7.1 IANA Considerations for registering new GLP attributes

   When registering new GLP attributes, the following information must
   be provided to IANA:


    1   Name of registering organization: company name, university,
        organization name.

    2.  Name of principal contact: Name of the individual that is the
        primary contact point for questions and comments regarding the
        attribute.

    3.  Email address of principal contact.

    4.  Phone number of principal contact.

    5.  Name of attribute: A short, descriptive name describing the
        attribute. For example - "supported codecs".

    6.  Attribute Number: The numeric identifier for the attribute. This
        must not conflict with attribute numbers already defined in GLP
        or already registered.

    7.  Description: Several sentences or paragraphs describing the pur-
        pose of the attribute. Sufficient detail must be provided to
        allow an implementor to determine whether or not the attribute
        is needed in their implementation, and if so, what its value
        should be.

    8.  Flags: The values for the attribute flags.

    9.  Originating considerations: Information useful for originating
        this attribute. Specifically, under what conditions it should be
        originated.

   10.  Selection considerations: Information useful in using the attri-
        bute for route selection.

   11.  Aggregation considerations: Clear rules on how the attribute is
        aggregated.



Rosenberg,Salama,Squire                                        [Page 36]


Internet Draft               GLP Attributes                 25 June 1999


   12.  Dissemination considerations: Information useful when dissem-
        inating the attribute.


   This information parallels that provided here in Section 4 for each
   attribute.

 7.2 Registering new pricing attribute sub-types with IANA

   When registering new pricing sub-types with IANA, the following
   information must be provided:


    1.  Name of registering organization: company name, university, or
        organization name.

    2.  Name of principal contact: Name of the individual that is the
        primary contact point for questions and comments regarding the
        sub-type.

    3.  Email address of principal contact.

    4.  Phone number of principal contact.

    5.  Name of sub-type: A short, descriptive name describing the pric-
        ing sub-type. For example - ``per minute with peak''

    6.  Subtype Number: The numeric identifier for the sub-type. This
        must not conflict with sub-type numbers already defined in GLP
        or already registered.

    7.  Description: Several sentences or paragraphs describing the
        meaning of the sub-type.

    8.  Syntax of the value: The detailed syntax and semantics for the
        value component of the pricing element must be provided.

    9.  Example: An example of a correctly formatted pricing attribute
        of this sub-type must be provided.

 7.3 Registering new ITAD Numbers with IANA

   When registering new ITAD numbers with IANA, the following informa-
   tion must be provided:


    1.  Name of registering organization: company name, university, or
        organization name. This name must be unique.



Rosenberg,Salama,Squire                                        [Page 37]


Internet Draft               GLP Attributes                 25 June 1999


    2.  Name of principal contact: Name of the individual that is the
        primary contact point for questions and comments regarding the
        sub-type.

    3.  Email address of principal contact.

    4.  Phone number of principal contact.

     Editors Note: How is registration of AS's in BGP handled?
     RFC1771 has no IANA considerations section.


 7.4 Registering new Currency Types with IANA

   When registering new Currency types with IANA, the following informa-
   tion must be provided:


    1.  Name of country: Name of country where currency is used

    2.  Name of currency: Name of the currency

    3.  Currency type number: An unused and unregistered type number for
        this currency.

8 Open Issues

   In this section, we capture the open issues as identified throughout
   the document by Editor's Notes.  This section just collects these
   notes, no new information is provided.

 8.1 Aggregation Rules for Transitive Attributes

   From Section 3.4.3:

     Editor's Note.  There are several options available to handle
     unrecognized transitive attributes during aggregation.  We can
     (a) drop them, (b) propagate them if they are binary
     equivalent, (c) define a set of aggregation operations and
     have these indicated by a flag(s) in the attribute (ie addi-
     tion, union, drop if !equal, etc.), (d) other suggestions?


 8.2 Black-holes

   From Section 4.1.4:

     Editor's Note.  We debated whether an LS should advertise



Rosenberg,Salama,Squire                                        [Page 38]


Internet Draft               GLP Attributes                 25 June 1999


     black-holes within GLP, but came to the consensus that expli-
     cit black-hole advertisements should not be in GLP.  It seems
     unimportant whether signaling to an invalid number fails at
     the ingress, egress, or such an LS.  Knowledge of black-holes
     helps aggregation, but the best option seemed to be keeping
     the distribution of this knowledge outside of GLP.  Note that
     an LS cannot be prevented from advertising something it knows
     to be a black-hole.


 8.3 Scope

   From Section 4.1.4:

     Editor's Note.  We were unable to reach consensus on the issue
     of "scope".  Using scope to geographically limit the distribu-
     tion of 800 numbers seemed like a bad idea, but there seems to
     be a need to map some non-unique numbers into a globally
     unique number space.  The disagreement over scope centered on
     whether one should apply this concept to just 800-type
     numbers, or to any private numbering space.  One camp believed
     that private numbers should not be advertised between domains
     - that the definition of private implied intra-domain only.
     The other camp believed that a confederation of providers may
     combine to provide a "VPN-like" service for handling private
     numbering spaces across domains, and hence that private
     numbers should be mapped into something globally unique and be
     carried between domains.  Comments?


 8.4 Phone number representation using bitmasks

   From Section 4.1.5:

     Editor's Note.  The following alternative representation to
     prefixes was suggested.  Each digit position is represented by
     a 10-bit bitmask.  If digit position i has bit j set, then the
     digit j can appear in position i.  As an example, to
     [0100000000] represents all numbers starting with 1, and
     [0100000000, 0111111110] represents all numbers starting with
     11, 12, 13, ..., or 18.  This representation is very flexible
     with regards to aggregation, but its unclear how, given a
     phone number, one finds the 'most specific' match.


 8.5 Domain of NextHopSignalingServer

   From Section 4.2.3:



Rosenberg,Salama,Squire                                        [Page 39]


Internet Draft               GLP Attributes                 25 June 1999


     Editor's Note:  Is it necessary to include the domain of the
     next-hop for policy applications?  Ie, is it a viable policy
     to prefer the next hop to be in domain X?  It may be possible
     to get the domain of the next-hop from the LastModifiedBy
     attribute, but this needs to be verified.  The SignalingPath
     attribute would represent another way to get this information.


 8.6 Load-balancing on capacity

   From Section 4.4:

     Editor's Note.  The exact methods for load-balancing require
     more work, but we believe load-balancing to be a valuable and
     important feature for GLP.


 8.7 Separation of Signalling Protocols

   From Section 4.5.1 on SignallingProtocols syntax:

     Editor's Note:  We should probably make each signalling proto-
     col into its own attribute because much of the related infor-
     mation is specific to one particular signalling protocol.  For
     example, the UDP port numbers will likely be different if a
     single server supports both SIP & H323.


 8.8 Pricing

   From Section 4.6.1 on the syntax of the Pricing attribute:

     Editor's Note.  We believe currency codes are already
     used/defined in other IETF documents (OTP?).  We should use
     the same currency codes if possible.  Registering new codes is
     only required if we have to define them.

     Editor's Note.  We need to specify a floating point represen-
     tation.

     Editor's Note.  We probably need to provide a time unit as
     well because different plans have different time units (ie the
     rate gets incremented every 6 seconds, every minute, etc).  We
     should look at ITU SG16 Annex G for a good example.


   From Section 4.6.5 on disseminating the Pricing attribute.




Rosenberg,Salama,Squire                                        [Page 40]


Internet Draft               GLP Attributes                 25 June 1999


     Editor's Note:  Should we relax these rules a bit? Can an LS
     propagate the pricing attribute if it doesn't change the next
     hop? This would allow the LastModifiedBy attribute to contain
     a signature for the pricing attribute as well.

     Editor's Note.  There a some possible methods for handling
     aggregation and route propagation of the Pricing attribute
     that might be worth investigation.   The attribute itself
     might indicate its processing.  For example, it could refer-
     ence a Java applet, or could be written in a well-known
     language like TCL or XML so that the data itself defines its
     properties.  This possibility would definitely need more
     investigation.

     Editor's Note.  It would seem beneficial if the Pricing attri-
     bute subtypes could be negotiatiated during peer session
     establishment, so that an LS uses a pricing language under-
     stood by its peer.


 8.9 Authentication via LastModifiedBy

   The following issue discusses the syntax of the LastModifiedBy attri-
   bute:


     Editor's Note.  The intent of this attribute is to allow an LS
     to 'sign' certain attributes.  Receivers must be able to ver-
     ify this signature, so some type of identification of the pro-
     vider must be provided.  This might be an IPv4 address, an
     IPv6 address, a DNS name, etc.  The LS-type above should
     define what kind of identifier is provided (IPv, IPv6, DNS,
     etc.), and the identifier should carry that value.



 8.10 Number of hops versus path

   The following note is in Section 4.8:


     Editor's Note.  As an alternative to NumSignalingHops, a Sig-
     nalingPath attribute was considered.  The SignalingPath attri-
     bute would be much like the AdvertisementPath, except it would
     only be updated when the next-hop changed.  Thus, it would
     record the signaling path to the destination.  It was not
     clear whether the SignalingPath attribute would be more useful
     than simply counting the number of hops, so for simplicity we



Rosenberg,Salama,Squire                                        [Page 41]


Internet Draft               GLP Attributes                 25 June 1999


     went with the NumSignalingHops attribute.  Would a Signaling-
     Path attribute be useful enough in policy to justify the added
     complexity?



9 Conclusions

   This draft recommends a set of attributes for initial consideration
   for GLP.  These attributes is independent of the transport and syn-
   chronization issues that also have to be decided.

   This attribute set is intended as the final set, but merely as the
   starting point for further discussions.  The function and suggested
   implementation of each attribute should be reviewed by the IPTEL WG
   community.


10 References

   [1] J. Rosenberg and H. Schulzrinne, "A Framework for a Gateway Loca-
   tion Protocol," Internet Draft, Internet Engineering Task Force, Work
   in Progress, June 1999.

   [2] D. Hampton, D. Oran, H. Salama, and D. Shah, "The IP Telephony
   Border Gateway Protocol Architecture," Internet Draft, Internet
   Engineering Task Force, February 1999.

   [3] M. Squire, "A Gateway Location Protocol," Internet Draft, Inter-
   net Engineering Task Force, Work in Progress, February 1999.

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

   [5] J. Moy, "OSPF Version 2," Request For Comments (Draft Standard)
   2328, Internet Engineering Task Force, April 1998.

   [6] J. Reynolds and J. Postel, "Assigned Numbers," Request For Com-
   ments (Draft Standard) 1700, Internet Engineering Task Force, October
   1994.



Author's Address

   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories



Rosenberg,Salama,Squire                                        [Page 42]


Internet Draft               GLP Attributes                 25 June 1999


   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   RM 4C-526
   email: jdrosen@bell-labs.com

   Hussein Salama
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA 95134
   hsalama@cisco.com

   Matt Squire
   Nortel Networks
   4309 Emporer Blvd
   Suite 200
   Durham, NC 27703
   msquire@nortelnetworks.com


































Rosenberg,Salama,Squire                                        [Page 43]