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]
