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 . 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 , 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 tuples are the same. For the purpose of aggregating AdvertisementPath attributes we model each ITAD within the AdvertisementPath attribute as a tuple , 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 , 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 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]