idnits 2.17.1 draft-ietf-iptel-glp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 337 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...d is in full ...' == Line 16 has weird spacing: '...), its areas...' == Line 17 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '... and may be...' == Line 22 has weird spacing: '...opriate to u...' == (332 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 1999) is 9202 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BGP' is mentioned on line 83, but not defined -- Looks like a reference, but probably isn't: '4' on line 533 == Unused Reference: 'BGP4' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'ISO4217' is defined on line 1002, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GLP-FR' ** Obsolete normative reference: RFC 1654 (ref. 'BGP4') (Obsoleted by RFC 1771) -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIP' -- Possible downref: Non-RFC (?) normative reference: ref. 'H323' -- Possible downref: Non-RFC (?) normative reference: ref. 'SCSP' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1890 (Obsoleted by RFC 3551) -- Possible downref: Non-RFC (?) normative reference: ref. 'URL' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO4217' Summary: 10 errors (**), 0 flaws (~~), 13 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force IPTEL WG 3 Internet Draft Matt Squire 4 draft-ietf-iptel-glp-00.txt Nortel Networks 5 February 16, 1999 6 Expires: August 1999 8 A Gateway Location Protocol 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 1 Abstract 33 Given a gateway and a (possibly empty) list of gateway attributes, 34 the "gateway location problem" is to find a gateway serving the given 35 phone number that satisfies the attribute set. This problem has also 36 been referred to as the "call routing problem" as the answer returned 37 may not be an IP-PSTN gateway but an intermediate signaling server. 39 Part of the solution to this problem is the maintenance and 40 distribution of the call routing tables. This document describes a 41 protocol for maintaining a distributed call routing database across 42 multiple administrative domains. The protocol uses the Server Cache 43 Synchronization Protocol (SCSP) to maintain the distributed database. 44 This document describes the problem of gateway location and a 45 potential solution that uses SCSP as the foundation for distributing 46 the call routing tables. 48 2 Overview of the Gateway Location Problem 49 A gateway is a device providing connectivity between the PSTN and an 50 IP network. A telephone call that originates from an IP device, or 51 that passes through an IP network, and that terminates on the PSTN, 52 must traverse a gateway. There may be multiple gateways in the 53 network through which a particular call could egress the network. An 54 important step in the evolution of IP telephony is automating the 55 choice of an egress gateway for a particular call. 57 The general gateway location problem is described in the Gateway 58 Location Framework [GLP-FR], and the position of the Gateway Location 59 Protocol (GLP) relative to other IP telephony protocols and entities 60 is defined. This framework is summarized here, but the reader is 61 referred to [GLP-FR] for a fuller description. 63 In the framework, End Users (EUs) are entities with IP connectivity 64 and with the ability to place phone calls to users on the PSTN. EUs 65 may be users with IP telephony equipment or may be gateways from the 66 PSTN to an IP network. Gateways are the devices that translate 67 between an IP network and the PSTN. Location Servers (LSs) are the 68 logical entities that maintain knowledge of the gateways, and 69 Signaling Servers (SSs) are the entities which forward and process 70 signaling messages. Common signaling protocols are SIP [SIP] and 71 H.323 [H323]. Signaling servers forward (route) signaling messages 72 while location servers maintain the information on which these 73 forwarding decisions are made. 75 GLP is defined as an inter-domain protocol, where an IP Telephony 76 Administrative Domain (ITAD) is a collection of IP telephony 77 resources under the control of a single administrative authority. 78 LSs participate in the GLP to maintain this database of gateways 79 across multiple ITADs. Another protocol, the intra-domain protocol, 80 may be used by LSs within a domain to further distribute this 81 information. The use of possibly different inter-domain and an 82 intra-domain protocols is analogous to the use of the Border Gateway 83 Protocol (BGP) [BGP] and the Open Shortest Path First (OSPF) [OSPF] 84 protocol to maintain routing tables between and within autonomous 85 systems (IP routing domains). Note that just as BGP can be used 86 within an autonomous system, GLP can be use within an ITAD. Using 87 GLP within an ITAD provides reliability and scaleability for inter- 88 domain communications by permitting multiple border routers. 90 LSs learn about the gateways within their domain through an out-of- 91 band mechanism. Another protocol, the front-end protocol, is used by 92 EUs to access the LS database in order to route a call toward the 93 PSTN. The GLP places no restrictions on the front-end or intra- 94 domain protocols. 96 3 Comparison of Call Routing and IP Routing 98 To better understand the problem of call routing, we first compare it 99 with the well-understood problem of IP routing. 101 IP routing tables are made up of a collection of routing table 102 entries. For basic IP routing, each entry consists of a destination 103 address, an address mask, a next-hop router, and a path-length. All 104 packets targeted to a destination covered by the combination of the 105 destination address and address mask are forwarded to the next-hop 106 router. The cost to reach the destination is given by path-length. 108 Whenever there are multiple entries that cover a single destination, 109 the more specific entry (with the longer address mask) is used to 110 route the packet. There are mechanisms defined for aggregating and 111 forwarding routing information. For example, when advertising a 112 route entry received from one neighbor to another neighbor, the 113 router may increment the path-length before transmitting the 114 advertisement. Also, when a router receives multiple routes to a 115 particular destination, it may discard entries with a longer path- 116 length as these represent non-optimal routes. 118 Call routing is similar but has several important distinctions. The 119 call routing infrastructure is overlayed on the IP infrastructure, 120 but the two routing realms are independent. Location Servers, which 121 maintain the call routing tables, and Signaling Servers, which 122 forward the signaling messages, are distinct logical entities 123 (however, a single device may perform both functions). The IP 124 telephony data (the packetized voice) is not routed using the LS/SS 125 combination. It is forwarded as normal IP packets and need not be 126 routed through any signaling server. Peer LSs need not be physically 127 adjacent. 129 Call routing tables are made up of a collection of call routing 130 objects. A call routing object is a more complex version of an IP 131 routing table entry. Like an IP routing table entry, a call routing 132 object includes a set of destination addresses and a next hop. In 133 this case, the set of destination addresses is given by upper and 134 lower bound telephone numbers, and the next-hop is the next-hop 135 signaling server (which may in fact be a gateway). In IP routing, 136 the cost represents a path cost (ie a relative measurement of the 137 distance/delay between two points). In call routing, the cost of a 138 route is an optional attribute of a call routing object, and the cost 139 of a route is dependent on may variables other than the path (the 140 cost charged by a gateway to service a call, the quality of the 141 service given by the network and gateway, etc). 143 A call routing object may also include any number of additional 144 attributes. These might include the signaling protocols supported by 145 the next-hop SS for this destination, the telephony features provided 146 for this destination, the speech codecs understood for this 147 destination, the encryption algorithms supported for this 148 destination, etc. The set of attributes is open-ended and 149 destination specific. As such, defining a standard set of rules for 150 aggregating and forwarding call-routing objects is itself a difficult 151 problem. 153 In IP routing, given any destination address, there is a simple rule 154 for determining the routing table entry that should be applied. 155 Namely, find the routing table entry with the longest matching 156 prefix. Such a rule does not exist in the context of call routing. 157 Prefix length is not the most significant variable in determining the 158 best suited routing object. Call routing objects are multi- 159 attributed, as such there can certainly be more than one entry that 160 applies to a particular destination. For example, a particular phone 161 number may be reachable via a SIP server at one destination or via a 162 H.323 server at another destination. Multiple matching entries could 163 be used by a server to load-balance between several possible 164 destinations. 166 One can also examine the scaleability of call routing versus IP 167 routing. For the Internet, all routers must be interconnected. Each 168 routing table must contain an applicable entry for every Internet 169 address. The collection of SSs on the Internet need not be (and most 170 likely will never be) connected. A likely scenario is that a set of 171 IP telephony providers will combine resources to form a confederation 172 whose signaling servers and location servers communicate. Different 173 confederations will most likely not share call routing data, implying 174 a collection of independent call routing confederations. So although 175 a call routing table may contain an entry covering every phone number 176 on the PSTN, any particular LS/SS only propagates information 177 about/to gateways within its confederation. 179 4 GLP Model 181 GLP is analogous to BGP in that it is used to distribute (call) 182 routing information between domains. As such, BGP is used as the 183 model for GLP. 185 At its core, BGP is a combination of link-state and distance-vector 186 routing protocols whose aggregation and filtering rules are partially 187 specified by the protocol itself and partially specified by a set of 188 local policies for that BGP speaker. BGP speakers may have internal 189 and external links to BGP speakers in its or other domains. A BGP 190 link is a communication between two peer BGP speakers. Behavior over 191 internal and external links is slightly different. Within a domain, 192 all BGP speakers use a combination of a mesh or route reflectors to 193 achieve complete connectivity. BGP speakers maintain an inbound and 194 outbound routing table for each link, as well as a local routing 195 table used in their own routing decisions. When a link is first 196 established, BGP synchronizes each speaker's outbound routing table 197 with its peer's inbound routing table. After this synchronization, 198 only updates traverse across the link. 200 The Server Cache Synchronization Protocol (SCSP), on the other hand, 201 is a generalization of OSPF in that it accomplishes database 202 synchronization on multiple servers by flooding information received 203 from one neighbor to all other neighbors. However, if an SCSP 204 flooding domain is restricted to a pair of neighbors, then SCSP 205 behaves much like BGP. Both protocols exchange hello messages 206 between peers, perform an entire transfer of the database upon 207 detecting a new peer, and only exchange incremental updates after the 208 initial synchronization. GLP applies SCSP to the inter-domain 209 problem of gateway location by limiting the inter-domain flooding 210 group to a pair of peer speakers from adjacent ITADs. In other 211 words, the flooding aspects of SCSP are not used on inter-ITAD links. 213 To this end, a Location Server belongs to a number of Server Groups 214 (SGs). Each SG corresponds to a collection of servers whose 215 databases are to be synchronized. When a SG spans domains, it likely 216 consists of only two LSs and provides bidirectional connectivity 217 between the LSs. This is analogous to two peer BGP speakers over an 218 external BGP link. For internal links, however, the possibilities 219 are more flexible. Within a domain, a Server Group may consist of 220 multiple LSs interconnected with an arbitrary topology. This 221 provides a much more flexible and robust intra-domain connectivity 222 than BGP meshes and route reflectors. 224 The set of SGs to which a particular LS belongs, the set of servers 225 forming a Server Group, and the topology of interconnection within a 226 SG are all determined administratively. Since GLP is defined as an 227 inter-domain protocol, no neighbor discovery is provided. 229 SCSP is used to maintain a distributed and synchronized database over 230 all servers in a Server Group. This database consists of the 231 information required to route calls across the network. As in BGP, 232 the database can be logically partitioned into inbound and outbound 233 databases. The LS has an internal Policy Information Base (LS-PIB) 234 that defines how to compute the outbound databases given the set of 235 inbound databases. The LS also has a local database that it uses to 236 make call forwarding decisions. The contents of the local database 237 is also determined by applying the LS-PIB policy to the inbound 238 databases. 240 The GLP model is depicted in Figure 1, where LSs LS-A1 through LS-A3 241 are in one administrative domain, and LSs LS-B1 through LS-B2 are in 242 another ITAD. In this example, the SGs are {LS-A1, LS-A2, LS-A3}, 243 {LS-A3, LS-B1}, and {LS-B1, LS-B2}. Note that the topology in 244 administrative domain A is not complete. SCSP provides 245 synchronization across arbitrary connected topologies. 247 |---------------------- 248 | LS-A1 | 249 | gw-local | 250 | | | 251 | LS-PIB | 252 | | | 253 | | | |---------------------| 254 | gw-in gw-out | | LS-A3 | 255 |---------------------| | gw-local | 256 | | | | 257 / | | | 258 / ----------------| gw-in -- LS-PIB | 259 / | gw-out | | 260 |---------------------- | | | 261 | gw-in gw-out | | gw-out gw-in | 262 | | | |---------------------| 263 | | | | 264 | LS-PIB | | 265 | | | | 266 | | LS-A2 | |-----------------------| 267 | gw-local | | gw-in gw-out | 268 |---------------------| | | | 269 | LS-PIB -- gw-local | 270 | | | 271 | gw-in gw-out LS-B1 | 272 |-----------------------| 273 | 274 |-----------------------| 275 | gw-in gw-out | 276 | | | 277 | LS-PIB -- gw-local | 278 | | 279 | LS-B2 | 280 |-----------------------| 282 Figure 1 GLP Model 284 The form and function of the LS policies is not defined in this 285 document. We believe that the most appropriate policies will be 286 developed over time and through implementation innovation and 287 experience. The multi-attributed nature of a gateway makes it 288 difficult to define a satisfactory set of policies for aggregating 289 and filtering the collection of gateways forwarded to each neighbor. 291 5 SCSP 293 The Server Cache Synchronization Protocol (SCSP) [SCSP] solves the 294 general problem of server synchronization and cache replication. 295 SCSP synchronizes the caches of a set of servers of a particular 296 protocol bound to a particular server group. In the case of GLP, 297 SCSP is used to synchronize the call routing database of all servers 298 within a SG. The SG may consist of two servers (for example, an 299 inter-ITAD SG may consist of one LS from each of two domains) or may 300 be more general (for example, when used between the border LSs within 301 a particular ITAD). 303 SCSP uses the combination of a Protocol ID (PID) and a Server Group 304 ID (SGID) to identify both the protocol for which the servers are 305 being synchronized as well as the instance of that protocol. In our 306 case, the PID identifies the protocol as GLP. 308 Editor's Note. We need to get an SCSP PID for GLP. 310 SCSP assumes a the underlying network is a Non-Broadcast Multiple 311 Access (NBMA) network. For GLP, the NMBA network is any IP network 312 providing TCP connectivity. GLP could also operate directly over 313 other NBMA networks (such as ATM AAL5, Frame Relay, etc), but the 314 specifics of such behavior is not detailed here. 316 5.1 SCSP Operation 318 SCSP has three phases. The first phase serves to establish 319 connectivity between directly connected neighbors. This phase is 320 known as the Hello Phase. The second phase is the Cache Alignment 321 phase, where directly connected servers quickly exchange the contents 322 of their entire database. The third phase is the Cache State Update 323 phase, where servers only transmit updates of their local database to 324 their directly connected peers, and servers flood received database 325 elements to other directly connected peers within the same SG. Note 326 that this flooding operation permits a more general intra-domain 327 topology than BGP which requires a combination of meshes and route 328 reflectors. 330 5.1.2 Hello Phase 332 In the Hello Phase, directly connected LSs exchange hello messages in 333 order to establish bidirectional connectivity between peers. 335 After connectivity is established, hello messages continue to be 336 exchanged in order to indicate the status of the peer. Hello 337 messages have two fields which control the frequency of the hello 338 messages and the time before a neighbor is declared inoperable. 339 Hello messages are sent every HelloInterval seconds. A peer is 340 considered dead if no hello message has been received for 341 HelloInterval*DeadFactor seconds. For GLP, hello messages must not 342 be transmitted more than once per second. The suggested value for 343 the HelloInterval is 30 seconds. The suggested value of DeadFactor 344 is 3. 346 Editor's Note. One shortcoming of SCSP is that the Hello Protocol is 347 not particularly extendible. There is nothing like version or 348 feature negotiation during the Hello Phase. Is version/feature 349 negotiation required for GLP? 351 5.1.2 Cache Alignment Phase 353 During the Cache Alignment phase, peer servers synchronize the 354 contents of their entire database. During Cache Alignment, peer 355 servers first exchange a summary of their database. After the 356 summary exchange, a server requests data elements from their peers 357 based on that summary information. Cache Alignment ends when peer 358 servers have synchronized their databases for the first time. 360 After first aligning its GLP database with a peer, an LS shall 361 execute its local policies to determine if any of its advertised 362 databases, or its local database, have changed. Any resulting 363 changes to an advertised route must be synchronized with the affected 364 neighbor(s). 366 5.1.3 Cache State Update Phase 368 During the Cache Update phase, adjacent LSs exchange only changed or 369 updated data elements. When something happens at an LS to change the 370 set of advertised call routing elements to a peer, an LS must 371 propagate this change to its neighbor. The neighbor acknowledges the 372 newly received elements. 374 When an LS is informed of an updated or new call routing data 375 element, it must execute its local policies to determine if the set 376 of local or advertised call routes has been changed. If so, then 377 these changes must be propagated to the affected neighbor(s). 379 5.2 GLP Specific SCSP Fields 381 SCSP has generic and protocol specific aspects. This section details 382 the GLP specific fields and formats for use within SCSP. 384 GLP runs over a NBMA network of TCP connections. During 385 initialization, servers establish TCP connections to their configured 386 set of peers. By default, SCSP over TCP uses TCP port XXXX. This 387 port value should be configurable at an LS. It is a straightforward 388 exercise to run GLP over other types of NBMA networks, or to extend 389 SCSP/GLP over a network with multicast ability. However, due to the 390 inter-domain aspects of GLP, multicast is not recommended. 392 Editor's Note. We need to get a SCSP TCP port assigned. 394 Editor's Note. It is not obvious that TCP is the only or the right 395 choice for the transport layer. RUTS? An encrypted transport? 396 Other possibilities? 398 The scope of a SCSP flooding domain is controlled by the combination 399 of Server Group ID (SGID) and Protocol ID (PID). For GLP, the PID is 400 XXXX. The assignment of the SGID for a specific set of servers is a 401 local decision. 403 Editor's Note. We need to get a SCSP GLP PID assigned. 405 Servers within a SG of SCSP must have unique server identifiers. 406 These identifiers are used to indicate the source and recipient of 407 each SCSP message, as well as the originator of a data element within 408 the distributed database. For GLP, this identifier is an IP address 409 unique to the LS. The identifier is 4 octets in length. 411 Each data element within a SCSP database can be identified by the 412 combination of the Originator ID (the server which sourced the data 413 element) and the Cache Key. The Cache Key is an identifier for the 414 data element chosen such that the combination of Originator ID and 415 Cache Key uniquely identifies this element. Servers use this 416 identification method when determining if a received data element is 417 a 'new' object or another version of an existing object. The Cache 418 Key is variable length in SCSP. For GLP, the length of the Cache Key 419 is 4. The Cache Key is a 4-octet field chosen by the originator of a 420 data element such that the uniqueness condition is guaranteed. 422 SCSP also defines a 'newness' criteria for database elements. When a 423 server receives a data element from a peer, and that new element 424 matches an existing element in both the Originator ID and Cache Key, 425 then the server examines the Sequence Number of the element to 426 determine which version of the element is newer. Sequence Numbers 427 can be used to refresh aging database elements. 429 The format of the data elements synchronized by SCSP for GLP is given 430 in Section 5.2.1. 432 5.2.1 Generic GLP Data Object Format 434 SCSP synchronizes individual database elements to all servers within 435 a Server Group. In SCSP, a database element is represented as a 436 Cache State Advertisement (CSA). Each CSA contains a CSA header 437 followed by a protocol specific part containing the actual data. The 438 protocol specific part of a GLP CSA has the following generic format. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | GLP Obj Type | Reserved | GLP Object Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | GLP Object Data (variable) | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The fields are defined as follows. 450 GLP Obj Type. 451 This field defines the type of GLP object. This specification 452 defines the following GLP Object Types. 453 1 - GLPv1.0 Call Routing Object 455 GLP Object Length. 456 The Length of the GLP Object, from the start of the GLP Object Type 457 field to the end of the CSA data. For alignment purposes, all GLP 458 objects should be padded to have even length. 460 CSA Data. 461 The data specific to this instance of the object. The format of 462 the data depends on the object type. 464 5.2.2 GLP Call Routing Object Format 465 The GLP Call Routing Object (CRO) forms the basis for internet call 466 routing. The GLP CRO associates a range of telephone numbers with an 467 IP address. A CRO can be used to route signaling messages to phone 468 numbers that lie within the range specified by the lower and upper 469 bound telephone numbers. When forwarding a signaling message for a 470 phone number in the specified range, a signaling server or user agent 471 may forward the signaling message to the Next Hop Signaling Server 472 specified in the CRO. The Next Hop Signaling Server may represent an 473 actual gateway or a transit signaling server. Whether the CRO 474 represents an actual gateway or a transit SS cannot be determined 475 from the CRO. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | GLP Obj Type | Reserved | GLP Object Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Phone# LB Len | Phone# UB Len | Num GLP Attributes | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Lifetime | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Next Hop Signaling Server | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Phone# Lower Bound (variable) | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Phone# Upper Bound (variable) | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | GLP Attributes (variable) | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 GLP Object Type. 496 Equals 1. 498 GLP Object Length. 499 A CRO object has variable length but the length must be even. 501 Phone Number Lower Bound Length. 502 The length of the Lower Bound Phone Number field. 504 Phone Number Upper Bound Length. 505 The length of the Upper Bound Phone Number field. 507 Number of GLP Attributes. 508 The number of GLP attributes in this CRO. 510 Lifetime. 511 The number of seconds that this call-routing object is valid. CROs 512 must be aged in the database and removed when their lifetime 513 expires. Similarly, an originator must refresh CROs before they 514 expire in a peer. A CRO can be refreshed by incrementing the 515 Sequence Number of a CRO and synchronizing the updated CRO CSA with 516 the peer. 518 Next Hop Signaling Server. 519 The IP address of the next hop signaling server that is associated 520 with this call routing object. When using this call routing object 521 to route a call, signaling messages are sent to this address. 523 Editor's Note. Should probably have a more general concept of a 524 protocol address (ie have a protocol type and a protocol address). 525 This would permit the same protocol to be used for routing calls over 526 other networks (IPv6). 528 Phone Number Lower Bound. 529 The lower bound of the telephone number range defined by this CRO. 530 The sytax of this field is: 531 phone-number-bound = +1*phone-digit phone-digit = DIGIT 532 This format is similar to the format for a global telephone number 533 as defined in SIP [4] without visual separators. This format 534 facilitates efficient comparison with the internationalized format 535 of a phone number. 537 Editor's Note. This representation does not permot 'local' phone 538 number formats. Local formats seem dangerous when one the concept of 539 local can be different for the client and server. 541 Phone Number Upper Bound. 542 The upper bound of the telephone number range defined by this CRO. 543 The lower and upper bounds may refer to phone numbers in different 544 country codes and have different lengths. A phone number is 545 covered by a particular CRO if 546 lb <= p <= ub 547 where p is the international version of the phone number and the 548 comparison is performed using a string comparison function. For 549 example, 550 +1919 <= +19199929048 <= +1919993 552 Editor's Note. We could also make the phone numbers and next hop 553 server into attributes (ie have the type, length, value format). 554 Preferences anyone? 556 GLP Attributes. 557 The collection of attributes associated with this call routing 558 object. For alignment purposes, this field starts on the first 559 even-octet boundary after the previous field. 561 5.2.3 Generic GLP Attribute Format 563 A CRO may contain any number of GLP Attributes. Attributes provide 564 additional information about the call routing object. Each GLP 565 Attribute has the following generic format. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | GLP Attribute Type | GLP Attribute Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | GLP Attribute Data (variable) | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 GLP Attribute Type. 576 GLP Attributes provide additional information that can be used to 577 restrict the call routing path applicable to a specific signaling 578 sequence. The following attribute types are defined in this 579 specification. 580 1 - Supported Signaling Protocols 581 2 - Pricing 582 3 - Gateway Provider 583 4 - Next Hop Provider 584 5 - Supported Codecs 585 6 - Capacity 586 7 - Time-to-live 588 GLP Attribute Length. 589 The length of this attribute from the start of the type field. The 590 length must be even. 592 GLP Attribute Data. 593 The data specific to this attribute. The data format for each 594 attribute is given in the following sections. 596 5.2.3.1 Supported Signaling Protocol Attribute 598 The Supported Signaling Protocol Attribute gives a signaling protocol 599 supported for the CRO address range by the CRO next hop. There can 600 be multiple instances of this attribute in a CRO CSA when a next hop 601 can be contacted for the same phone numbers using multiple signaling 602 protocols. 604 0 1 2 3 605 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | GLP Attribute Type=1 | GLP Attribute Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | TCP/UDP Port | IP Protocol | SigProtoIdLen | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Signaling Protocol Identifier (variable) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | Additional Signaling Protocol Parameters (variable) | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 GLP Attribute Type. 618 Equals 1. 620 GLP Attribute Length. 621 Variable, even length. 623 TCP/UDP Port. 624 The TCP/UDP port that should be used to contact the next-hop when 625 using the specified signaling protocol. 627 IP Protocol. 628 Indicates whether TCP (0x06) or UDP (x11) should be used to contact 629 the next hop when using this signaling protocol. 631 Signaling Protocol Identifier Length. 632 The length of the Signaling Protocol Identifier field. 634 Signaling Protocol Identifier. 635 Identifies a signaling protocol that can be used to contact phone 636 numbers in the CRO's phone number range using the specified next 637 hop. The Signaling Protocol Identifier format is: 638 sig-proto-id = "SIP" | "H323" 640 Editor's Note. Is there a standard method of expressing signaling 641 protocols like SIP or H.323 within a message? Couldn't find them 642 registered with IANA. 644 Additional Signaling Protocol Parameters. 645 This field can be used to specify additional signaling parameters 646 needed to establish a connection using this signaling protocol to 647 the specified next hop. This attribute should contain only those 648 signaling parameters required to establish a connection that cannot 649 be expressed by any other GLP attribute. Many signaling parameters 650 can be negotiated during the signaling process. It is recommended 651 that negotiable signaling parameters are not included in this 652 attribute. Limiting the number of signaling parameters improves 653 scaleability of the protocol. The format of this field is 654 dependent on the signaling protocol. 656 Editor's Note. The goal of this last field is to allow the 657 expression of any attributes that need to be given in order to allow 658 the signaling to work. Since signaling protocols are evolving, we 659 can't cover everything in attributes. This gives a back door to get 660 needed information into the database. If this approach is 661 acceptable, then we need to define the formats of this field for SIP 662 & H.323. 664 5.2.3.2 Pricing Attribute 666 The purpose of the Pricing Attribute is to provide information on how 667 much a call to a phone number in the CRO's telephone range would cost 668 a user. The pricing attribute is sub-typed to yield several methods 669 of expressing the pricing details. 671 The End Users must recognize the pricing attribute cannot be taken as 672 a guarantee of a particular service for a particular price. Other 673 factors may influence the actual amount a user is charged for a 674 service. Pricing structures may have too many variables to guarantee 675 the accuracy of this data to the end user. For example, the cost of 676 a call through a gateway may depend upon the source of the call (ie 677 are you a customer of ISP-X?). The cost may also depend upon the 678 negotiated media capabilities. Such variables complicate the pricing 679 structures. Other protocols (AAA, OTP, RSVP, etc) must perform the 680 authentication, negotiation, accounting, etc. required to actually 681 negotiate and authorize the final charge for the phone service. 682 There can be at most one Pricing Attribute in a CRO. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | GLP Attribute Type=2 | GLP Attribute Length | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 |L| Pricing Attribute Subtype | Pricing Attribute Data Len | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Pricing Attr Originator Len | Reserved | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Pricing Attribute Data (variable) | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Pricing Attribute Originator (variable) | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Pricing Attribute Signature (variable) | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 GLP Attribute Type. 701 Equals 2. 703 GLP Attribute Length. 704 Variable, even length. 706 Pricing Attribute Subtype. 707 The subtype may have either local significance or be a registered 708 subtype with IANA. Local subtypes have the L-flag set, while IANA 709 registered subtypes have the L-flag cleared. The purpose of the 710 local subtypes is so that within a ITAD, or within a confederation 711 of ITADs, a pricing structure can be expressed in method that can 712 be automatically interpreted by a program (such as the LS policy 713 decision process) to better automate the choice of next hop. The 714 format of the data section differs for each subtype. 716 The set of currently defined subtypes is: 717 1 - Text 718 2 - URL 720 Editor's Note. Any other suggestions on how to do pricing? 722 Pricing Attribute Data Length. 723 The length of the Pricing Attribute Data Field. Must be even. 725 Pricing Attribute Originator Length. 726 The length of the Pricing Attribute Data Field. Must be even. 728 Pricing Attribute Data. 729 The formats for the Pricing Attribute Data are given in subsequent 730 sections. 732 Pricing Attribute Originator. 733 The originator of the Pricing Attribute. A LS should not propagate 734 a CRO if the originator of the pricing attribute is not trusted. 736 Editor's Note. Any suggestions on how to handle representation of 737 the originator? Company name? Web page? Contact information? Some 738 ITAD numeric representation? 740 Pricing Attribute Signature. 741 A digital signature that can be used to authenticate the the 742 validity of the pricing data. In the event of a false 743 advertisement, the source of the false advertisement can be traced. 744 The pricing attribute signature is calculated over the entire 745 Pricing Attribute. The pricing attribute may be signed before 746 being advertised by an LS. If an LS does not alter the Pricing 747 attribute data, it must not alter the originator or the signature. 748 If an LS does modify the Pricing attribute data, it must put itself 749 as the originator and may sign the message as well. 751 5.2.3.2.1 Text 753 This Pricing Attribute subtype contains a textual description of a 754 pricing strategy. The intent of this subtype is that this 755 description can be displayed to an end user. The character set is 756 ISO 10646 using UTF-8 encoding [UTF8]. 758 Editor's Note. If we want this, do we need to worry about language 759 concerns? I'd prefer to let language concerns be handled by the URL 760 sub-type and let this sub-type be simple character representations. 762 5.2.3.2.2 URL 764 This Princing Attribute sub-type contains a URL from which additional 765 pricing data may be retrieved. The intent of this subtype is that 766 the URL may contain data that can be displayed to the end user or 767 used by some automated selection process. A pricing structure may be 768 given in multiple languages using an HTTP URL and language 769 negotiation as specified in HTTP [HTTP1.1]. URL formats are defined 770 in [URL]. 772 5.2.3.3 Gateway Provider 774 The Gateway Provider attribute specifies the owner/provider of an 775 egress gateway to the PSTN indicated by this CRO. The provider of a 776 gateway may be used when selecting how to route a particular call. 777 There may be multiple Gateway Provider attributes in a CRO. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | GLP Attribute Type=3 | GLP Attribute Length | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Gateway Provider (variable) | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 GLP Attribute Type. 788 Equals 3. 790 GLP Attribute Length. 791 Variable, even length. 793 Gateway Provider. 794 The Gateway Provider field specifies the owner/provider of the 795 egress gateway for this CRO. 797 Editor's Note. We are now presented with the question of how to 798 represent an Internet telephony service provider. Two obvious 799 possibilities are using a numeric representation along the lines of a 800 BGP AS, or using a string representation along the lines of DNS. 801 Could we use DNS names or do we need a new type of name? Maybe a 802 URL? 804 5.2.3.4 Next Hop Provider 806 The next hop provider attribute specifies the owner/provider of the 807 next hop SS specified by this CRO. Like the Gateway Provider 808 attribute, the Next Hop Provider may be used when deciding how to 809 route a particular call. A single Next Hop Provider attribute must 810 be in every CRO. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | GLP Attribute Type=4 | GLP Attribute Length | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Next Hop Provider | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 GLP Attribute Type. 821 Equals 4. 823 GLP Attribute Length. 824 Variable, even length. 826 Next Hop Provider. 827 The Next Hop Provider field specifies the owner/provider of the 828 provider of the next hop signaling server listed in the CRO. A 829 single Next Hop Provider attribute must exist in every CRO. 831 Editor's Note. Again have to worry how to represent providers. 833 5.2.3.5 Supported Codec 835 This attribute is used to specify the codecs that are supported by an 836 egress gateway that can be reached via the next hop in this CRO. 837 There may be multiple Supported Codec attributes in a CRO. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | GLP Attribute Type=5 | GLP Attribute Length | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Supported Codec (variable) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 GLP Attribute Type. 848 Equals 5. 850 GLP Attribute Length. 851 Variable, even length. 853 Supported Codec. 854 Specifies an algorithm for the encoding and decoding of packetized 855 voice. The set of registered codec names is maintained by IANA 856 [RFC1890]. Non-registered codecs are indicated by preceding the 857 name with "X-". The format for the Supported Codecs field is: 858 supported-codec ; see [RFC1890] 860 5.2.3.6 Capacity 862 Gateways may have varying capabilities with regard to the number of 863 phone calls that can be simultaneously processed. The capacity of a 864 gateway may be limited by link speed, memory, the number of circuits, 865 etc. The Capacity Attribute allows administrators to assign gateways 866 a metric representative of their capacity. The Capacity Attribute is 867 a relative metric to be used across a confederation of ITADs. The 868 determination of the capacity of a gateway as communicated by this 869 attribute is an administrative matter. The unitless nature of the 870 Capacity Attribute makes it impossible to compare the capacity of two 871 gateways in different Internet telephony confederations. This 872 attribute can be used to load-balance connections between a set of 873 satisfactory next-hops. Note that this metric is NOT a path cost, 874 but a relative measurement of the capacity of the egress gateway(s). 875 This attribute is not intended to indicate any aspects of the real- 876 time load on the gateway(s). This attribute may be modified by 877 intermediate LSs when performing aggregation or filtering of CROs. 878 Only one Capacity Attribute is permitted in a CRO. 880 The format of the Capacity attribute is given below. 882 0 1 2 3 883 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 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | GLP Attribute Type=6 | GLP Attribute Length=8 | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Capacity | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 GLP Attribute Type. 891 Equals 6. 893 GLP Attribute Length. 894 Equals 8. 896 Capacity. 897 A relative measurement of the capacity of the egress gateway(s) 898 represented by the call routing object. Represented as a 32-bit 899 unsigned integer. A larger value in the Capacity field represents 900 a CRO with more egress gateway capacity. The capacity of a 901 gateway(s) is a relative value and cannot be used for comparison 902 between different Internet telephony confederations. 904 Editor's Note. We could define some unit(s) for the capacity metric. 905 For example, bandwidth, maximum circuits, etc. Defining multiple 906 units complicates the comparison of two capacities (ie is 10 Mbps 907 greater than 20 circuits?), but makes the measurement more concrete. 908 Suggestions? 910 5.2.3.7 Time-To-Live 912 The TTL attribute is used to prevent loop detection. A LS must 913 decrement the TTL of a CRO that it advertises to a peer in another 914 administrative domain. When aggregating multiple inbound CROs into a 915 single outbound CRO, the aggregated CRO must have a TTL less than all 916 of the CROs that served as input for the outbound CRO. CROs with a 917 TTL of zero must be ignored on receipt and should not be transmitted. 918 Each CRO must contain a single TTL attribute. 920 The format for the TTL Attribute is: 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | GLP Attribute Type=7 | GLP Attribute Length = 8 | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | TTL | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 GLP Attribute Type. 931 Equals 7. 933 GLP Attribute Length. 934 Equals 8. 936 TTL. 937 The number of intermediate LSs through which this CRO may be 938 forwarded. The default value for CROs originated within the local 939 ITAD is XXXX (?). 941 Editor's Note. Might be better to use a loop detection algorithm 942 more like BGP where we record the route of every entry. Preferences? 944 Editor's Note. SCSP doesn't have any error indication defined. 945 Should we try to define one, or just have the application layer deal 946 with errors. 948 Editor's Note. Instead of including all of the attributes with the 949 call routing information in a single object, we could put each 950 attribute into its own object. This would allow attributes to be 951 updated independently of the base call routing data (ie every update 952 wouldn't have to include the entire CRO), but would require more 953 objects and the correlation of the objects. 955 6 Security Considerations 957 SCSP has an Authentication Extension that can be appended to any SCSP 958 message. When included in a SCSP message, the Authentication 959 Extension provides integrity and authentication between directly 960 connected peers. It is recommended that GLP speakers use the 961 Authentication Extension of SCSP to validate incoming GLP messages. 963 LSs may also wish to provide confidentiality for their transmitted 964 data. To achieve confidentiality, peer LSs may communicate over an 965 encrypted TCP connection. 967 7 IANA Considerations 969 - scsp pid - tcp port for scsp? 970 - signaling protocols 971 - internet telephony admin domains 972 - other? 974 8 Conclusions 976 9 References 978 [GLP-FR] J. Rosenberg and H. Schulzrinne, A Framework for a Gateway 979 Location Protocol, Internet Draft, Internet Engineering Task Force, 980 Work in Progress, 1999 982 [BGP4] Y. Rekhter and T. Li, A border gateway protocol 4 (BGP-4), 983 Request for Comments (Draft Standard) 1771, Internet Engineering Task 984 Force, Mar. 1995. (Obsoletes RFC1654). 986 [OSPF] OSPF 988 [SIP] SIP 990 [H323] H323 992 [SCSP] SCSP 994 [HTTP1.1] HTTP 1.1 996 [UTF8] ISO 10646 in UTF8 (rfc 2279) 998 [RFC1890] RTP codec names & payload types 1000 [URL] URL formats 1002 [ISO4217] ISO 4217 (currency codes?) 1004 Author's Address 1006 Matt Squire 1007 Nortel Networks 1008 4309 Emporer Blvd 1009 Suite 200 1010 Durham, NC 27703 1012 Phone: (919) 992-9048 1014 msquire@nortelnetworks.com