Internet Engineering Task Force IPTEL WG Internet Draft Matt Squire draft-ietf-iptel-glp-00.txt Nortel Networks February 16, 1999 Expires: August 1999 A Gateway Location Protocol 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 Given a gateway and a (possibly empty) list of gateway attributes, the "gateway location problem" is to find a gateway serving the given phone number that satisfies the attribute set. This problem has also been referred to as the "call routing problem" as the answer returned may not be an IP-PSTN gateway but an intermediate signaling server. Part of the solution to this problem is the maintenance and distribution of the call routing tables. This document describes a protocol for maintaining a distributed call routing database across multiple administrative domains. The protocol uses the Server Cache Synchronization Protocol (SCSP) to maintain the distributed database. This document describes the problem of gateway location and a potential solution that uses SCSP as the foundation for distributing the call routing tables. 2 Overview of the Gateway Location Problem Squire [Page 1]
Internet Draft GLP 16 February 1999 A gateway is a device providing connectivity between the PSTN and an IP network. A telephone call that originates from an IP device, or that passes through an IP network, and that terminates on the PSTN, must traverse a gateway. There may be multiple gateways in the network through which a particular call could egress the network. An important step in the evolution of IP telephony is automating the choice of an egress gateway for a particular call. The general gateway location problem is described in the Gateway Location Framework [GLP-FR], and the position of the Gateway Location Protocol (GLP) relative to other IP telephony protocols and entities is defined. This framework is summarized here, but the reader is referred to [GLP-FR] for a fuller description. In the framework, End Users (EUs) are entities with IP connectivity and with the ability to place phone calls to users on the PSTN. EUs may be users with IP telephony equipment or may be gateways from the PSTN to an IP network. Gateways are the devices that translate between an IP network and the PSTN. Location Servers (LSs) are the logical entities that maintain knowledge of the gateways, and Signaling Servers (SSs) are the entities which forward and process signaling messages. Common signaling protocols are SIP [SIP] and H.323 [H323]. Signaling servers forward (route) signaling messages while location servers maintain the information on which these forwarding decisions are made. GLP is defined as an inter-domain protocol, where an IP Telephony Administrative Domain (ITAD) is a collection of IP telephony resources under the control of a single administrative authority. LSs participate in the GLP to maintain this database of gateways across multiple ITADs. Another protocol, the intra-domain protocol, may be used by LSs within a domain to further distribute this information. The use of possibly different inter-domain and an intra-domain protocols is analogous to the use of the Border Gateway Protocol (BGP) [BGP] and the Open Shortest Path First (OSPF) [OSPF] protocol to maintain routing tables between and within autonomous systems (IP routing domains). Note that just as BGP can be used within an autonomous system, GLP can be use within an ITAD. Using GLP within an ITAD provides reliability and scaleability for inter- domain communications by permitting multiple border routers. LSs learn about the gateways within their domain through an out-of- band mechanism. Another protocol, the front-end protocol, is used by EUs to access the LS database in order to route a call toward the PSTN. The GLP places no restrictions on the front-end or intra- domain protocols. Squire [Page 2]
Internet Draft GLP 16 February 1999 3 Comparison of Call Routing and IP Routing To better understand the problem of call routing, we first compare it with the well-understood problem of IP routing. IP routing tables are made up of a collection of routing table entries. For basic IP routing, each entry consists of a destination address, an address mask, a next-hop router, and a path-length. All packets targeted to a destination covered by the combination of the destination address and address mask are forwarded to the next-hop router. The cost to reach the destination is given by path-length. Whenever there are multiple entries that cover a single destination, the more specific entry (with the longer address mask) is used to route the packet. There are mechanisms defined for aggregating and forwarding routing information. For example, when advertising a route entry received from one neighbor to another neighbor, the router may increment the path-length before transmitting the advertisement. Also, when a router receives multiple routes to a particular destination, it may discard entries with a longer path- length as these represent non-optimal routes. Call routing is similar but has several important distinctions. The call routing infrastructure is overlayed on the IP infrastructure, but the two routing realms are independent. Location Servers, which maintain the call routing tables, and Signaling Servers, which forward the signaling messages, are distinct logical entities (however, a single device may perform both functions). The IP telephony data (the packetized voice) is not routed using the LS/SS combination. It is forwarded as normal IP packets and need not be routed through any signaling server. Peer LSs need not be physically adjacent. Call routing tables are made up of a collection of call routing objects. A call routing object is a more complex version of an IP routing table entry. Like an IP routing table entry, a call routing object includes a set of destination addresses and a next hop. In this case, the set of destination addresses is given by upper and lower bound telephone numbers, and the next-hop is the next-hop signaling server (which may in fact be a gateway). In IP routing, the cost represents a path cost (ie a relative measurement of the distance/delay between two points). In call routing, the cost of a route is an optional attribute of a call routing object, and the cost of a route is dependent on may variables other than the path (the cost charged by a gateway to service a call, the quality of the service given by the network and gateway, etc). A call routing object may also include any number of additional Squire [Page 3]
Internet Draft GLP 16 February 1999 attributes. These might include the signaling protocols supported by the next-hop SS for this destination, the telephony features provided for this destination, the speech codecs understood for this destination, the encryption algorithms supported for this destination, etc. The set of attributes is open-ended and destination specific. As such, defining a standard set of rules for aggregating and forwarding call-routing objects is itself a difficult problem. In IP routing, given any destination address, there is a simple rule for determining the routing table entry that should be applied. Namely, find the routing table entry with the longest matching prefix. Such a rule does not exist in the context of call routing. Prefix length is not the most significant variable in determining the best suited routing object. Call routing objects are multi- attributed, as such there can certainly be more than one entry that applies to a particular destination. For example, a particular phone number may be reachable via a SIP server at one destination or via a H.323 server at another destination. Multiple matching entries could be used by a server to load-balance between several possible destinations. One can also examine the scaleability of call routing versus IP routing. For the Internet, all routers must be interconnected. Each routing table must contain an applicable entry for every Internet address. The collection of SSs on the Internet need not be (and most likely will never be) connected. A likely scenario is that a set of IP telephony providers will combine resources to form a confederation whose signaling servers and location servers communicate. Different confederations will most likely not share call routing data, implying a collection of independent call routing confederations. So although a call routing table may contain an entry covering every phone number on the PSTN, any particular LS/SS only propagates information about/to gateways within its confederation. 4 GLP Model GLP is analogous to BGP in that it is used to distribute (call) routing information between domains. As such, BGP is used as the model for GLP. At its core, BGP is a combination of link-state and distance-vector routing protocols whose aggregation and filtering rules are partially specified by the protocol itself and partially specified by a set of local policies for that BGP speaker. BGP speakers may have internal and external links to BGP speakers in its or other domains. A BGP Squire [Page 4]
Internet Draft GLP 16 February 1999 link is a communication between two peer BGP speakers. Behavior over internal and external links is slightly different. Within a domain, all BGP speakers use a combination of a mesh or route reflectors to achieve complete connectivity. BGP speakers maintain an inbound and outbound routing table for each link, as well as a local routing table used in their own routing decisions. When a link is first established, BGP synchronizes each speaker's outbound routing table with its peer's inbound routing table. After this synchronization, only updates traverse across the link. The Server Cache Synchronization Protocol (SCSP), on the other hand, is a generalization of OSPF in that it accomplishes database synchronization on multiple servers by flooding information received from one neighbor to all other neighbors. However, if an SCSP flooding domain is restricted to a pair of neighbors, then SCSP behaves much like BGP. Both protocols exchange hello messages between peers, perform an entire transfer of the database upon detecting a new peer, and only exchange incremental updates after the initial synchronization. GLP applies SCSP to the inter-domain problem of gateway location by limiting the inter-domain flooding group to a pair of peer speakers from adjacent ITADs. In other words, the flooding aspects of SCSP are not used on inter-ITAD links. To this end, a Location Server belongs to a number of Server Groups (SGs). Each SG corresponds to a collection of servers whose databases are to be synchronized. When a SG spans domains, it likely consists of only two LSs and provides bidirectional connectivity between the LSs. This is analogous to two peer BGP speakers over an external BGP link. For internal links, however, the possibilities are more flexible. Within a domain, a Server Group may consist of multiple LSs interconnected with an arbitrary topology. This provides a much more flexible and robust intra-domain connectivity than BGP meshes and route reflectors. The set of SGs to which a particular LS belongs, the set of servers forming a Server Group, and the topology of interconnection within a SG are all determined administratively. Since GLP is defined as an inter-domain protocol, no neighbor discovery is provided. SCSP is used to maintain a distributed and synchronized database over all servers in a Server Group. This database consists of the information required to route calls across the network. As in BGP, the database can be logically partitioned into inbound and outbound databases. The LS has an internal Policy Information Base (LS-PIB) that defines how to compute the outbound databases given the set of inbound databases. The LS also has a local database that it uses to make call forwarding decisions. The contents of the local database is also determined by applying the LS-PIB policy to the inbound Squire [Page 5]
Internet Draft GLP 16 February 1999 databases. The GLP model is depicted in Figure 1, where LSs LS-A1 through LS-A3 are in one administrative domain, and LSs LS-B1 through LS-B2 are in another ITAD. In this example, the SGs are {LS-A1, LS-A2, LS-A3}, {LS-A3, LS-B1}, and {LS-B1, LS-B2}. Note that the topology in administrative domain A is not complete. SCSP provides synchronization across arbitrary connected topologies. |---------------------- | LS-A1 | | gw-local | | | | | LS-PIB | | | | | | | |---------------------| | gw-in gw-out | | LS-A3 | |---------------------| | gw-local | | | | | / | | | / ----------------| gw-in -- LS-PIB | / | gw-out | | |---------------------- | | | | gw-in gw-out | | gw-out gw-in | | | | |---------------------| | | | | | LS-PIB | | | | | | | | LS-A2 | |-----------------------| | gw-local | | gw-in gw-out | |---------------------| | | | | LS-PIB -- gw-local | | | | | gw-in gw-out LS-B1 | |-----------------------| | |-----------------------| | gw-in gw-out | | | | | LS-PIB -- gw-local | | | | LS-B2 | |-----------------------| Figure 1 GLP Model Squire [Page 6]
Internet Draft GLP 16 February 1999 The form and function of the LS policies is not defined in this document. We believe that the most appropriate policies will be developed over time and through implementation innovation and experience. The multi-attributed nature of a gateway makes it difficult to define a satisfactory set of policies for aggregating and filtering the collection of gateways forwarded to each neighbor. 5 SCSP The Server Cache Synchronization Protocol (SCSP) [SCSP] solves the general problem of server synchronization and cache replication. SCSP synchronizes the caches of a set of servers of a particular protocol bound to a particular server group. In the case of GLP, SCSP is used to synchronize the call routing database of all servers within a SG. The SG may consist of two servers (for example, an inter-ITAD SG may consist of one LS from each of two domains) or may be more general (for example, when used between the border LSs within a particular ITAD). SCSP uses the combination of a Protocol ID (PID) and a Server Group ID (SGID) to identify both the protocol for which the servers are being synchronized as well as the instance of that protocol. In our case, the PID identifies the protocol as GLP. Editor's Note. We need to get an SCSP PID for GLP. SCSP assumes a the underlying network is a Non-Broadcast Multiple Access (NBMA) network. For GLP, the NMBA network is any IP network providing TCP connectivity. GLP could also operate directly over other NBMA networks (such as ATM AAL5, Frame Relay, etc), but the specifics of such behavior is not detailed here. 5.1 SCSP Operation SCSP has three phases. The first phase serves to establish connectivity between directly connected neighbors. This phase is known as the Hello Phase. The second phase is the Cache Alignment phase, where directly connected servers quickly exchange the contents of their entire database. The third phase is the Cache State Update phase, where servers only transmit updates of their local database to their directly connected peers, and servers flood received database elements to other directly connected peers within the same SG. Note that this flooding operation permits a more general intra-domain topology than BGP which requires a combination of meshes and route reflectors. Squire [Page 7]
Internet Draft GLP 16 February 1999 5.1.2 Hello Phase In the Hello Phase, directly connected LSs exchange hello messages in order to establish bidirectional connectivity between peers. After connectivity is established, hello messages continue to be exchanged in order to indicate the status of the peer. Hello messages have two fields which control the frequency of the hello messages and the time before a neighbor is declared inoperable. Hello messages are sent every HelloInterval seconds. A peer is considered dead if no hello message has been received for HelloInterval*DeadFactor seconds. For GLP, hello messages must not be transmitted more than once per second. The suggested value for the HelloInterval is 30 seconds. The suggested value of DeadFactor is 3. Editor's Note. One shortcoming of SCSP is that the Hello Protocol is not particularly extendible. There is nothing like version or feature negotiation during the Hello Phase. Is version/feature negotiation required for GLP? 5.1.2 Cache Alignment Phase During the Cache Alignment phase, peer servers synchronize the contents of their entire database. During Cache Alignment, peer servers first exchange a summary of their database. After the summary exchange, a server requests data elements from their peers based on that summary information. Cache Alignment ends when peer servers have synchronized their databases for the first time. After first aligning its GLP database with a peer, an LS shall execute its local policies to determine if any of its advertised databases, or its local database, have changed. Any resulting changes to an advertised route must be synchronized with the affected neighbor(s). 5.1.3 Cache State Update Phase During the Cache Update phase, adjacent LSs exchange only changed or updated data elements. When something happens at an LS to change the set of advertised call routing elements to a peer, an LS must propagate this change to its neighbor. The neighbor acknowledges the newly received elements. When an LS is informed of an updated or new call routing data Squire [Page 8]
Internet Draft GLP 16 February 1999 element, it must execute its local policies to determine if the set of local or advertised call routes has been changed. If so, then these changes must be propagated to the affected neighbor(s). 5.2 GLP Specific SCSP Fields SCSP has generic and protocol specific aspects. This section details the GLP specific fields and formats for use within SCSP. GLP runs over a NBMA network of TCP connections. During initialization, servers establish TCP connections to their configured set of peers. By default, SCSP over TCP uses TCP port XXXX. This port value should be configurable at an LS. It is a straightforward exercise to run GLP over other types of NBMA networks, or to extend SCSP/GLP over a network with multicast ability. However, due to the inter-domain aspects of GLP, multicast is not recommended. Editor's Note. We need to get a SCSP TCP port assigned. Editor's Note. It is not obvious that TCP is the only or the right choice for the transport layer. RUTS? An encrypted transport? Other possibilities? The scope of a SCSP flooding domain is controlled by the combination of Server Group ID (SGID) and Protocol ID (PID). For GLP, the PID is XXXX. The assignment of the SGID for a specific set of servers is a local decision. Editor's Note. We need to get a SCSP GLP PID assigned. Servers within a SG of SCSP must have unique server identifiers. These identifiers are used to indicate the source and recipient of each SCSP message, as well as the originator of a data element within the distributed database. For GLP, this identifier is an IP address unique to the LS. The identifier is 4 octets in length. Each data element within a SCSP database can be identified by the combination of the Originator ID (the server which sourced the data element) and the Cache Key. The Cache Key is an identifier for the data element chosen such that the combination of Originator ID and Cache Key uniquely identifies this element. Servers use this identification method when determining if a received data element is a 'new' object or another version of an existing object. The Cache Key is variable length in SCSP. For GLP, the length of the Cache Key is 4. The Cache Key is a 4-octet field chosen by the originator of a data element such that the uniqueness condition is guaranteed. Squire [Page 9]
Internet Draft GLP 16 February 1999 SCSP also defines a 'newness' criteria for database elements. When a server receives a data element from a peer, and that new element matches an existing element in both the Originator ID and Cache Key, then the server examines the Sequence Number of the element to determine which version of the element is newer. Sequence Numbers can be used to refresh aging database elements. The format of the data elements synchronized by SCSP for GLP is given in Section 5.2.1. 5.2.1 Generic GLP Data Object Format SCSP synchronizes individual database elements to all servers within a Server Group. In SCSP, a database element is represented as a Cache State Advertisement (CSA). Each CSA contains a CSA header followed by a protocol specific part containing the actual data. The protocol specific part of a GLP CSA has the following generic format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Obj Type | Reserved | GLP Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Object Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are defined as follows. GLP Obj Type. This field defines the type of GLP object. This specification defines the following GLP Object Types. 1 - GLPv1.0 Call Routing Object GLP Object Length. The Length of the GLP Object, from the start of the GLP Object Type field to the end of the CSA data. For alignment purposes, all GLP objects should be padded to have even length. CSA Data. The data specific to this instance of the object. The format of the data depends on the object type. 5.2.2 GLP Call Routing Object Format Squire [Page 10]
Internet Draft GLP 16 February 1999 The GLP Call Routing Object (CRO) forms the basis for internet call routing. The GLP CRO associates a range of telephone numbers with an IP address. A CRO can be used to route signaling messages to phone numbers that lie within the range specified by the lower and upper bound telephone numbers. When forwarding a signaling message for a phone number in the specified range, a signaling server or user agent may forward the signaling message to the Next Hop Signaling Server specified in the CRO. The Next Hop Signaling Server may represent an actual gateway or a transit signaling server. Whether the CRO represents an actual gateway or a transit SS cannot be determined from the CRO. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Obj Type | Reserved | GLP Object Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Phone# LB Len | Phone# UB Len | Num GLP Attributes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Signaling Server | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Phone# Lower Bound (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Phone# Upper Bound (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attributes (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Object Type. Equals 1. GLP Object Length. A CRO object has variable length but the length must be even. Phone Number Lower Bound Length. The length of the Lower Bound Phone Number field. Phone Number Upper Bound Length. The length of the Upper Bound Phone Number field. Number of GLP Attributes. The number of GLP attributes in this CRO. Lifetime. The number of seconds that this call-routing object is valid. CROs Squire [Page 11]
Internet Draft GLP 16 February 1999 must be aged in the database and removed when their lifetime expires. Similarly, an originator must refresh CROs before they expire in a peer. A CRO can be refreshed by incrementing the Sequence Number of a CRO and synchronizing the updated CRO CSA with the peer. Next Hop Signaling Server. The IP address of the next hop signaling server that is associated with this call routing object. When using this call routing object to route a call, signaling messages are sent to this address. Editor's Note. Should probably have a more general concept of a protocol address (ie have a protocol type and a protocol address). This would permit the same protocol to be used for routing calls over other networks (IPv6). Phone Number Lower Bound. The lower bound of the telephone number range defined by this CRO. The sytax of this field is: phone-number-bound = +1*phone-digit phone-digit = DIGIT This format is similar to the format for a global telephone number as defined in SIP [4] without visual separators. This format facilitates efficient comparison with the internationalized format of a phone number. Editor's Note. This representation does not permot 'local' phone number formats. Local formats seem dangerous when one the concept of local can be different for the client and server. Phone Number Upper Bound. The upper bound of the telephone number range defined by this CRO. The lower and upper bounds may refer to phone numbers in different country codes and have different lengths. A phone number is covered by a particular CRO if lb <= p <= ub where p is the international version of the phone number and the comparison is performed using a string comparison function. For example, +1919 <= +19199929048 <= +1919993 Editor's Note. We could also make the phone numbers and next hop server into attributes (ie have the type, length, value format). Preferences anyone? GLP Attributes. The collection of attributes associated with this call routing object. For alignment purposes, this field starts on the first even-octet boundary after the previous field. Squire [Page 12]
Internet Draft GLP 16 February 1999 5.2.3 Generic GLP Attribute Format A CRO may contain any number of GLP Attributes. Attributes provide additional information about the call routing object. Each GLP Attribute has the following generic format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. GLP Attributes provide additional information that can be used to restrict the call routing path applicable to a specific signaling sequence. The following attribute types are defined in this specification. 1 - Supported Signaling Protocols 2 - Pricing 3 - Gateway Provider 4 - Next Hop Provider 5 - Supported Codecs 6 - Capacity 7 - Time-to-live GLP Attribute Length. The length of this attribute from the start of the type field. The length must be even. GLP Attribute Data. The data specific to this attribute. The data format for each attribute is given in the following sections. 5.2.3.1 Supported Signaling Protocol Attribute The Supported Signaling Protocol Attribute gives a signaling protocol supported for the CRO address range by the CRO next hop. There can be multiple instances of this attribute in a CRO CSA when a next hop can be contacted for the same phone numbers using multiple signaling protocols. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Squire [Page 13]
Internet Draft GLP 16 February 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=1 | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP/UDP Port | IP Protocol | SigProtoIdLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signaling Protocol Identifier (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Additional Signaling Protocol Parameters (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 1. GLP Attribute Length. Variable, even length. TCP/UDP Port. The TCP/UDP port that should be used to contact the next-hop when using the specified signaling protocol. IP Protocol. Indicates whether TCP (0x06) or UDP (x11) should be used to contact the next hop when using this signaling protocol. Signaling Protocol Identifier Length. The length of the Signaling Protocol Identifier field. Signaling Protocol Identifier. Identifies a signaling protocol that can be used to contact phone numbers in the CRO's phone number range using the specified next hop. The Signaling Protocol Identifier format is: sig-proto-id = "SIP" | "H323" Editor's Note. Is there a standard method of expressing signaling protocols like SIP or H.323 within a message? Couldn't find them registered with IANA. Additional Signaling Protocol Parameters. This field can be used to specify additional signaling parameters needed to establish a connection using this signaling protocol to the specified next hop. This attribute should contain only those signaling parameters required to establish a connection that cannot be expressed by any other GLP attribute. Many signaling parameters can be negotiated during the signaling process. It is recommended that negotiable signaling parameters are not included in this attribute. Limiting the number of signaling parameters improves scaleability of the protocol. The format of this field is dependent on the signaling protocol. Squire [Page 14]
Internet Draft GLP 16 February 1999 Editor's Note. The goal of this last field is to allow the expression of any attributes that need to be given in order to allow the signaling to work. Since signaling protocols are evolving, we can't cover everything in attributes. This gives a back door to get needed information into the database. If this approach is acceptable, then we need to define the formats of this field for SIP & H.323. 5.2.3.2 Pricing Attribute The purpose of the Pricing Attribute is to provide information on how much a call to a phone number in the CRO's telephone range would cost a user. The pricing attribute is sub-typed to yield several methods of expressing the pricing details. The End Users must recognize the pricing attribute cannot be taken as a guarantee of a particular service for a particular price. Other factors may influence the actual amount a user is charged for a service. Pricing structures may have too many variables to guarantee the accuracy of this data to the end user. For example, the cost of a call through a gateway may depend upon the source of the call (ie are you a customer of ISP-X?). The cost may also depend upon the negotiated media capabilities. Such variables complicate the pricing structures. Other protocols (AAA, OTP, RSVP, etc) must perform the authentication, negotiation, accounting, etc. required to actually negotiate and authorize the final charge for the phone service. There can be at most one Pricing Attribute in a CRO. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=2 | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Pricing Attribute Subtype | Pricing Attribute Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pricing Attr Originator Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pricing Attribute Data (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pricing Attribute Originator (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pricing Attribute Signature (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 2. Squire [Page 15]
Internet Draft GLP 16 February 1999 GLP Attribute Length. Variable, even length. Pricing Attribute Subtype. The subtype may have either local significance or be a registered subtype with IANA. Local subtypes have the L-flag set, while IANA registered subtypes have the L-flag cleared. The purpose of the local subtypes is so that within a ITAD, or within a confederation of ITADs, a pricing structure can be expressed in method that can be automatically interpreted by a program (such as the LS policy decision process) to better automate the choice of next hop. The format of the data section differs for each subtype. The set of currently defined subtypes is: 1 - Text 2 - URL Editor's Note. Any other suggestions on how to do pricing? Pricing Attribute Data Length. The length of the Pricing Attribute Data Field. Must be even. Pricing Attribute Originator Length. The length of the Pricing Attribute Data Field. Must be even. Pricing Attribute Data. The formats for the Pricing Attribute Data are given in subsequent sections. Pricing Attribute Originator. The originator of the Pricing Attribute. A LS should not propagate a CRO if the originator of the pricing attribute is not trusted. Editor's Note. Any suggestions on how to handle representation of the originator? Company name? Web page? Contact information? Some ITAD numeric representation? Pricing Attribute Signature. A digital signature that can be used to authenticate the the validity of the pricing data. In the event of a false advertisement, the source of the false advertisement can be traced. The pricing attribute signature is calculated over the entire Pricing Attribute. The pricing attribute may be signed before being advertised by an LS. If an LS does not alter the Pricing attribute data, it must not alter the originator or the signature. If an LS does modify the Pricing attribute data, it must put itself as the originator and may sign the message as well. Squire [Page 16]
Internet Draft GLP 16 February 1999 5.2.3.2.1 Text This Pricing Attribute subtype contains a textual description of a pricing strategy. The intent of this subtype is that this description can be displayed to an end user. The character set is ISO 10646 using UTF-8 encoding [UTF8]. Editor's Note. If we want this, do we need to worry about language concerns? I'd prefer to let language concerns be handled by the URL sub-type and let this sub-type be simple character representations. 5.2.3.2.2 URL This Princing Attribute sub-type contains a URL from which additional pricing data may be retrieved. The intent of this subtype is that the URL may contain data that can be displayed to the end user or used by some automated selection process. A pricing structure may be given in multiple languages using an HTTP URL and language negotiation as specified in HTTP [HTTP1.1]. URL formats are defined in [URL]. 5.2.3.3 Gateway Provider The Gateway Provider attribute specifies the owner/provider of an egress gateway to the PSTN indicated by this CRO. The provider of a gateway may be used when selecting how to route a particular call. There may be multiple Gateway Provider attributes in a CRO. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=3 | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway Provider (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 3. GLP Attribute Length. Variable, even length. Gateway Provider. The Gateway Provider field specifies the owner/provider of the Squire [Page 17]
Internet Draft GLP 16 February 1999 egress gateway for this CRO. Editor's Note. We are now presented with the question of how to represent an Internet telephony service provider. Two obvious possibilities are using a numeric representation along the lines of a BGP AS, or using a string representation along the lines of DNS. Could we use DNS names or do we need a new type of name? Maybe a URL? 5.2.3.4 Next Hop Provider The next hop provider attribute specifies the owner/provider of the next hop SS specified by this CRO. Like the Gateway Provider attribute, the Next Hop Provider may be used when deciding how to route a particular call. A single Next Hop Provider attribute must be in every CRO. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=4 | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Hop Provider | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 4. GLP Attribute Length. Variable, even length. Next Hop Provider. The Next Hop Provider field specifies the owner/provider of the provider of the next hop signaling server listed in the CRO. A single Next Hop Provider attribute must exist in every CRO. Editor's Note. Again have to worry how to represent providers. 5.2.3.5 Supported Codec This attribute is used to specify the codecs that are supported by an egress gateway that can be reached via the next hop in this CRO. There may be multiple Supported Codec attributes in a CRO. Squire [Page 18]
Internet Draft GLP 16 February 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=5 | GLP Attribute Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Supported Codec (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 5. GLP Attribute Length. Variable, even length. Supported Codec. Specifies an algorithm for the encoding and decoding of packetized voice. The set of registered codec names is maintained by IANA [RFC1890]. Non-registered codecs are indicated by preceding the name with "X-". The format for the Supported Codecs field is: supported-codec ; see [RFC1890] 5.2.3.6 Capacity Gateways may have varying capabilities with regard to the number of phone calls that can be simultaneously processed. The capacity of a gateway may be limited by link speed, memory, the number of circuits, etc. The Capacity Attribute allows administrators to assign gateways a metric representative of their capacity. The Capacity Attribute is a relative metric to be used across a confederation of ITADs. The determination of the capacity of a gateway as communicated by this attribute is an administrative matter. The unitless nature of the Capacity Attribute makes it impossible to compare the capacity of two gateways in different Internet telephony confederations. This attribute can be used to load-balance connections between a set of satisfactory next-hops. Note that this metric is NOT a path cost, but a relative measurement of the capacity of the egress gateway(s). This attribute is not intended to indicate any aspects of the real- time load on the gateway(s). This attribute may be modified by intermediate LSs when performing aggregation or filtering of CROs. Only one Capacity Attribute is permitted in a CRO. The format of the Capacity attribute is given below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=6 | GLP Attribute Length=8 | Squire [Page 19]
Internet Draft GLP 16 February 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 6. GLP Attribute Length. Equals 8. Capacity. A relative measurement of the capacity of the egress gateway(s) represented by the call routing object. Represented as a 32-bit unsigned integer. A larger value in the Capacity field represents a CRO with more egress gateway capacity. The capacity of a gateway(s) is a relative value and cannot be used for comparison between different Internet telephony confederations. Editor's Note. We could define some unit(s) for the capacity metric. For example, bandwidth, maximum circuits, etc. Defining multiple units complicates the comparison of two capacities (ie is 10 Mbps greater than 20 circuits?), but makes the measurement more concrete. Suggestions? 5.2.3.7 Time-To-Live The TTL attribute is used to prevent loop detection. A LS must decrement the TTL of a CRO that it advertises to a peer in another administrative domain. When aggregating multiple inbound CROs into a single outbound CRO, the aggregated CRO must have a TTL less than all of the CROs that served as input for the outbound CRO. CROs with a TTL of zero must be ignored on receipt and should not be transmitted. Each CRO must contain a single TTL attribute. The format for the TTL Attribute is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GLP Attribute Type=7 | GLP Attribute Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GLP Attribute Type. Equals 7. Squire [Page 20]
Internet Draft GLP 16 February 1999 GLP Attribute Length. Equals 8. TTL. The number of intermediate LSs through which this CRO may be forwarded. The default value for CROs originated within the local ITAD is XXXX (?). Editor's Note. Might be better to use a loop detection algorithm more like BGP where we record the route of every entry. Preferences? Editor's Note. SCSP doesn't have any error indication defined. Should we try to define one, or just have the application layer deal with errors. Editor's Note. Instead of including all of the attributes with the call routing information in a single object, we could put each attribute into its own object. This would allow attributes to be updated independently of the base call routing data (ie every update wouldn't have to include the entire CRO), but would require more objects and the correlation of the objects. 6 Security Considerations SCSP has an Authentication Extension that can be appended to any SCSP message. When included in a SCSP message, the Authentication Extension provides integrity and authentication between directly connected peers. It is recommended that GLP speakers use the Authentication Extension of SCSP to validate incoming GLP messages. LSs may also wish to provide confidentiality for their transmitted data. To achieve confidentiality, peer LSs may communicate over an encrypted TCP connection. 7 IANA Considerations - scsp pid - tcp port for scsp? - signaling protocols - internet telephony admin domains - other? Squire [Page 21]
Internet Draft GLP 16 February 1999 8 Conclusions 9 References [GLP-FR] J. Rosenberg and H. Schulzrinne, A Framework for a Gateway Location Protocol, Internet Draft, Internet Engineering Task Force, Work in Progress, 1999 [BGP4] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4), Request for Comments (Draft Standard) 1771, Internet Engineering Task Force, Mar. 1995. (Obsoletes RFC1654). [OSPF] OSPF [SIP] SIP [H323] H323 [SCSP] SCSP [HTTP1.1] HTTP 1.1 [UTF8] ISO 10646 in UTF8 (rfc 2279) [RFC1890] RTP codec names & payload types [URL] URL formats [ISO4217] ISO 4217 (currency codes?) Author's Address Matt Squire Nortel Networks 4309 Emporer Blvd Suite 200 Durham, NC 27703 Phone: (919) 992-9048 msquire@nortelnetworks.com Squire [Page 22]
