idnits 2.17.1 draft-ietf-iptel-glp-attribs-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 42 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 43 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 854: '...pacity attribute SHOULD NOT be treated...' RFC 2119 keyword, line 880: '...pacity attribute MAY be used as an inp...' RFC 2119 keyword, line 973: '...capacity metrics, Eq. 1 SHOULD be used...' RFC 2119 keyword, line 974: '...gated do not overlap, and Eq. 2 SHOULD...' RFC 2119 keyword, line 977: '...ibution of calls, it MAY use alternate...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 142 has weird spacing: '...nctions inclu...' == Line 659 has weird spacing: '...taining the...' == Line 1012 has weird spacing: '...mediate signa...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '0100000000' is mentioned on line 1799, but not defined == Missing Reference: '0111111110' is mentioned on line 1799, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 1771 (ref. '4') (Obsoleted by RFC 4271) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IETF 2 Internet Draft iptel WG 3 draft-ietf-iptel-glp-attribs-00.txt J. Rosenberg, H. Salama, M. Squire 4 June 25, 1999 Bell Labs/Cisco Systems/Nortel Networks 5 Expires: December, 1999 7 Attributes for a Gateway Location Protocol 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as work in progress. 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1 Abstract 32 The Gateway Location Protocol (GLP) provides a mechanism for 33 distributing and maintaining call routing tables between multiple 34 internet telephony providers. GLP is currently under development by 35 the iptel WG. 37 There have been multiple GLP proposals submitted to the IPTEL working 38 group. These proposals, although differing in some areas, have much 39 common ground. Specifically, the proposals each try to adapt many of 40 the concepts from BGP for GLP, and have common themes in the areas of 41 routing objects, route attributes, and route processing. This draft 42 offers recommendations based on the common areas in the current GLP 43 proposals, covering the routing objects, route attributes, and route 44 processing for GLP. This draft represents a consensus among the 45 multiple GLP proposals under consideration by the WG. 47 Issues of transport and data synchronization are not considered in 48 this draft. The data objects and their processing are considered 49 independent of the transport and synchronization mechanisms. 51 2 GLP Overview and Background 53 The Gateway Location Protocol (GLP) provides a mechanism for 54 distributing and maintaining call routing tables between multiple 55 internet telephony providers. GLP is currently under development by 56 the iptel WG. An in-depth overview of GLP can be found in [1], but 57 the framework is sketched here for convenience. 59 There are several proposals for GLP under consideration by the iptel 60 working group [2,3]. After discussions among the participants, it 61 was clear that the proposals had a similar basic framework and view 62 of the data objects that need to be distributed by GLP. This draft 63 addresses the definition and processing of the routing objects for 64 GLP. 66 GLP is an inter-domain protocol, where an IP Telephony Administrative 67 Domain (ITAD) is a collection of IP telephony resources under the 68 control of a single administrative authority. Location Servers (LSs) 69 participate in the GLP to maintain this database of gateways across 70 multiple ITADs. Another protocol, the intra-domain protocol, may be 71 used by LSs within a domain to further distribute this information. 72 The use of possibly different inter-domain and an intra-domain 73 protocols is analogous to the use of the Border Gateway Protocol 74 (BGP) [4] and the Open Shortest Path First (OSPF) [5] protocol to 75 maintain routing tables between and within autonomous systems (IP 76 routing domains). Note that just as BGP can be used within an 77 autonomous system, GLP can be use within an ITAD. Using GLP within 78 an ITAD provides reliability and scalability for inter-domain 79 communications by permitting multiple border routers. The general 80 GLP model is depicted in Figure 1. 82 ITAD1 ITAD2 83 ----------------- ------------------ 84 | | | | 85 | ---- | | ---- | 86 | | GW | | | | EU | | 87 | ---- - ---- | | ---- / ---- | 88 | | LS | ---------------- | LS | | 89 | ---- ---- | / ---- - ---- | 90 | | GW | / | /| | EU | | 91 | ---- | / | ---- | 92 | | / | | 93 ------------------ / ------------------ 94 / 95 / 96 --------- /---------- 97 | | | 98 | ---- | 99 | | LS | | 100 | / ---- | | 101 | ---- || ---- | 102 | | GW | || | EU | | 103 | ---- || ---- | 104 | ---- || ---- | 105 | | GW | / - | EU | | 106 | ---- ---- | 107 | | 108 --------------------- 109 ITAD3 111 Figure 1. General GLP Model 113 A Location Server has access to a database of gateways, called the 114 Gateway Information Base (GIB). This database of gateways is 115 constructed by combining the set of locally available gateways and 116 the set of remote gateways (learned through GLP) based on policy. 117 The LS also exports a set of gateways to its peer LSs in other ITADs. 118 The set of exported gateways is constructed from the set of local 119 gateways and the set of remote gateways (learned through GLP) based 120 on policy. As such, policy plays a central role in the LS operation. 121 The internal model of a Location Server is shown in Figure 2. 123 | 124 |Intra-domain protocol 125 | 126 Local 127 Gateways 129 GLP--> Gateways POLICY Gateways -->GLP 130 IN Out 131 | 132 | 133 Gateway 134 Information Base 136 Figure 2. Internal Location Server Model 138 The gateway database contains a number of call routing objects. The 139 call routing objects received from other LSs via GLP serve as input 140 to LS route processing, and the call routing objects advertised to 141 other LSs and used for local routing decisions are the output of the 142 LS route processing. The LS route processing functions include 143 route origination, route selection, aggregation, and route 144 dissemination. 146 GLP is an application layer routing protocol for telephony signaling 147 over IP networks. Given a phone number (and possibly a set of 148 attributes), an LS is capable of determining the next-hop signaling 149 server to which signaling messages for that phone number should be 150 forwarded. This next-hop could be a terminating IP entity, an IP- 151 PSTN gateway, or another signaling server. The GLP attributes 152 presented in this draft are concentrated on the signaling path and 153 its properties. The application of GLP for controlling aspects of 154 the media path is an area for future investigation. 156 An LS may represent a set of gateways in its administrative domain. 157 An LS may have to inject new call routing objects into GLP for these 158 gateways. There are many potential methods for an LS to learn of the 159 call routing objects that it should originate. The methods include a 160 front-end protocol, an intra-domain protocol, and static 161 configuration. The method by which an LS learns of new gateway 162 information within its domain is outside the scope of GLP. The 163 process of injecting new gateway information into GLP, and 164 determining the proper set of attributes for that information, is 165 also known as route origination. 167 An LS maintains the collection of call routing objects received from 168 other LSs via GLP. An LS performs route selection on the set of 169 received call routing objects. Route selection is the process by 170 which an LS chooses the routing objects out of this set to advertise 171 to other LSs, and to use for local routing decisions. The attributes 172 of the candidate call routing objects are used by policy mechanisms 173 within the LS to select certain routes for use and advertisement. 175 Aggregation is a method of information reduction. LSs may combine 176 multiple call routing objects into a single call routing object in 177 order to reduce the size of the database. The ability to combine 178 call routing objects, and the resultant call routing object, is 179 dependent on the attributes of the component routing objects. 181 An LS advertises selected routing objects to peer LSs. The 182 attributes included in advertised routing objects may not match the 183 attributes that were included in the received routing object. LSs 184 may add, remove, or modify attributes before advertising a specific 185 route. Route dissemination is when an LS advertises selected call 186 routing objects to its peers. 188 3 Overview of GLP Attributes 190 Each call routing object consists of a number of attributes. The 191 primary attributes in any call routing object are the 192 DestinationPhoneNumbers and NextHopSignalingServer attributes. These 193 attributes define a set of phone numbers and an address to which 194 signaling messages destined for a phone number in that set should be 195 sent. These are analogous to the IP address prefix and a next-hop 196 router in IP routing. 198 3.1 TLV encoding 200 Attributes are transported in a type-length-value encoding. There is 201 a flags field in the attribute that guides the processing of the 202 attribute when the attribute is unrecognized. Recognized attributes 203 are processed according to their recognized definition. 205 3.2 Attribute Types 207 The following sections describe an initial set of attribute types 208 recommended for GLP. These attributes are defined in more detail in 209 Section 4. 211 3.2.1 DestinationPhoneNumbers 213 This attribute defines the set of phone numbers described by the call 214 routing object. Each call routing object represents a limited range 215 of phone numbers as specified by an phone number prefix. 217 3.2.2 NextHopSignalingServer 219 This attribute gives the IP address of the entity to which signaling 220 messages should be sent. Unless further refined by the 221 SignalingProtocols attribute, messages for any signaling protocol 222 should be forwarded to this address. Note that this is NOT the 223 address to which the media (voice, video, etc.) should be 224 transmitted. Unlike BGP4 [4], the next-hop signaling server need not 225 share a subnet with the LS, nor must an LS advertise only one of its 226 own IP addresses as the next-hop. An LS may advertise a next-hop 227 with which it is not physically adjacent. 229 3.2.3 AdvertisementPath 231 The AdvertisementPath is analogous to the AS_PATH in BGP4 [4]. The 232 attribute records the sequence of domains through which this object 233 has passed. The attribute is used to detect when the routing object 234 is looping. This attribute does NOT reflect the path through which 235 signaling messages would traverse. Since the next-hop need not be 236 modified by each LS, the actual signaling path to the destination may 237 not have to traverse every domain in the AdvertisementPath. 239 3.2.4 GatewayCapacity 241 All gateways are not created equal. Some are large, capable of 242 supporting hundreds or even thousands of simultaneous calls. Others, 243 such as residential gateways, may only support one or two calls. The 244 GatewayCapacity attribute may be used in route selection to select 245 only those gateways with sufficient capacity. The GatewayCapacity 246 attribute might also be used to support a form of load balancing 247 across gateways based on their relative capacities. 249 3.2.5 SignalingProtocols 251 GLP is designed to be independent of the signaling protocol used to 252 establish multi-media sessions. However, not all gateways and 253 signaling servers will support all flavors of all signaling 254 protocols. The inclusion of the SignalingProtocols attribute is a 255 refinement on the NextHopSignalingServer attribute to indicate that 256 the next-hop is only valid for a certain set of signaling protocols. 257 If this attribute is not present, it may be assumed that the next-hop 258 can be used for any signaling protocol. 260 3.2.6 Pricing 262 The initiator of a voice session over the PSTN network may incur a 263 monetary charge for the PSTN services. This attribute is used to 264 advertise the charge for establishing and maintaining a session to 265 the DestinationPhoneNumbers. This cost generally reflects only those 266 charges occurred after the egress gateway (ie on the PSTN network). 267 Due to the complexity of the various pricing structures in use on the 268 PSTN, this attribute is subtyped to yield a detailed pricing 269 structure. New pricing subtypes may be registered with ICANN using 270 the procedures described in Section 7. It is expected that the 271 market requirements will drive the definition and implementation of 272 new pricing structures. 274 3.2.7 LastModifiedBy 276 Call routing objects may be modified or propagated unchanged by an 277 LS. An LS may modify a routing object due to aggregation, it may 278 filter an unknown attribute, it may add an attribute, or it may 279 change the value of an existing attribute. An LS that modifies 280 certain attributes may include the LastModifiedBy attribute to 281 indicate that this LS is the verifiable source of these attributes. 282 The attributes that are covered by the LastModifiedBy attribute are 283 identified by the LastModifiedByFlag as defined in Section 3.3. 285 3.2.8 NumSignalingHops 287 This attribute records the maximum and minimum number of signaling 288 hops that a signaling message would have to be forwarded when using 289 this routing object. When an LS inserts a new NextHopSignalingServer 290 for a call routing object, it increments the minimum and maximum 291 number of signaling hops. When an LS aggregates multiple routing 292 objects into a single object, it recalculates the maximum and minimum 293 number of signaling hops based on the aggregated routing objects. 294 This attribute can be used to select a path with a shorter signaling 295 path to the egress gateway. Note that the media path is independent 296 of the signaling path, and that this attribute does not describe 297 anything about the media path. 299 3.2.9 AtomicAggregate 301 If an LS, when presented with a set of overlapping routes from a peer 302 LS, selects the a specific route without selecting the more specific 303 route, then the LS includes the AtomicAggregate attribute with the 304 routing object. An LS receiving a routing object with an 305 AtomicAggregate attribute must not make make the set of destinations 306 more specific when advertising it to other LSs. The AtomicAggregate 307 attribute indicates that a routing object may have traversed domains 308 not listed in the AdvertisementPath. 310 3.2.10 LocalPreference 311 The LocalPreference attribute is used to inform other LSs *within the 312 same domain* of the local LSs preference for a given call routing 313 object. Other LSs within the same ITAD can use this attribute in 314 their route selection process. This attribute has no significance 315 between domains. 317 3.2.11 MultiExitDisc 319 Two internet telephony administrative domains may be connected via 320 more than one pair of LSs. The MultiExitDisc attribute is used by an 321 LS to express a preference for one link between the domains over 322 another link. The use of the MultiExitDisc attribute is controlled 323 by local policy. 325 3.3 Attribute Order 327 An LS should order the attributes in any routing object numerically 328 to facilitate faster operation. 330 3.4 Mandatory Attributes 332 Certain attributes are mandatory, ie they must be in every call 333 routing object. The DestinationPhoneNumbers attribute is an example 334 of a mandatory attribute. Mandatory attributes are identified in 335 their definition. Call routing objects that do not include all 336 mandatory attributes are discarded. 338 3.5 Attribute Flags 340 It is clear that the set of attributes for GLP will evolve over time. 341 Hence it is essential that mechanisms be provided to handle 342 attributes with unrecognized types. The handling of unrecognized 343 attributes is controlled via the flags field of the attribute. 344 Recognized attributes should be processed according to their specific 345 definition. 347 The following flags are recommended for GLP: 349 Optional. If set, the attribute is optional. If not set, the 350 attribute is well-known. Every well-known attribute must be 351 understood in order to process a routing object. 353 Partial. If set, indicates that the information in the attribute 354 is partial. Otherwise, the attribute is complete. Partial 355 attributes have not been processed by every LS along the 356 relevant parts of the AdvertisementPath. 358 IndependentTransitive. If set, the attribute is an independent 359 transitive attribute. IndependentTransitive attributes can be 360 propagated by an LS even if they don't recognize the type. 362 DependentTransitive. If set, the attribute is an dependent transi- 363 tive attribute. DependentTransitive attributes can be pro- 364 pagated by an LS even if they don't recognize the type only if 365 the LS does not change the next-hop. 367 LastModifiedByFlag. If set, this attribute is covered by the Last- 368 ModifiedBy attribute. The source of this attribute can be 369 authenticated by parsing the contents of the LastModifiedBy 370 attribute. 372 The transitivity flags only apply to optional attributes. The tran- 373 sitivity flags are ignored for well-known attributes. 375 3.4.1 Attribute Flags and Route Selection 377 The Optional flag determines whether an entire call routing object 378 received from a peer should be processed or discarded. If an LS 379 receives a well-known attribute with an unrecognized type, then it 380 must ignore the entire routing object. If an LS receives an optional 381 attribute with an unrecognized type, then it should process the rout- 382 ing object according to the other flags. 384 If a recognized attribute is received for which the flags are not 385 properly set, that attribute should be ignored and not propagated. 387 Any recognized attribute can be used as input to the route selection 388 process, although the utility of some attributes in route selection 389 is minimal. 391 3.4.2 Attribute Flags and Route Dissemination 393 GLP provides for two variations of transitivity due to the fact that 394 intermediate LSs need not modify the NextHopSignalingServer when pro- 395 pagating call routing objects. Attributes may be non-transitive, 396 dependent transitive, or independent transitive. An attribute cannot 397 be both dependent and independent transitive. An attribute with both 398 transitivity flags set should be ignored. 400 Unrecognized *independent* transitive attributes may be propagated by 401 any intermediate LS. Unrecognized *dependent* transitive attributes 402 may only be propagated if the LS is NOT changing the next-hop (given 403 by the NextHopSignalingServer attribute). The transitivity varia- 404 tions permit some attributes to be carried end-to-end (independent 405 transitive), some to be carried between adjacent next-hop signaling 406 servers (dependent transitive), and other to be restricted to peer 407 LSs (non-transitive). 409 An LS that passes an unrecognized transitive attribute to a peer must 410 set the Partial flag on that attribute. Any LS along a path may 411 insert a transitive attribute into a call routing object. If any LS 412 except the originating LS inserts a new transitive attribute into a 413 call routing object, then it must set the Partial flag on that attri- 414 bute. The Partial flag indicates that not every LS along the 415 relevant path has processed and understood the attribute. For 416 independent transitive attributes, the "relevant path" is the path 417 given in the AdvertisementPath attribute, while for dependent transi- 418 tive attributes, it is only those domains that have passed this 419 object since the NextHopSignalingServer was last modified. The Par- 420 tial flag in an independent transitive attribute must not be unset by 421 any other LS along the path. The Partial flag in a dependent transi- 422 tive attribute must be reset whenever the next-hop is changed. 424 The rules governing the addition of new non-transitive attributes are 425 defined independently for each new non-transitive attribute. 427 Any attribute may be updated by an LS in the path. 429 3.4.3 Attribute Flags and Route Aggregation 431 Each attribute defines how it is to be handled during route aggrega- 432 tion. 434 The rules governing the handling of unknown attributes are guided by 435 the Attribute Flags. Unrecognized transitive attributes are dropped. 437 There should be no unrecognized non-transitive attributes during 438 aggregation because non-transitive attributes must be processed by 439 the local LS in order to be propagated. 441 Editor's Note. There are several options available to handle 442 unrecognized transitive attributes during aggregation. We can 443 (a) drop them, (b) propagate them if they are binary 444 equivalent, (c) define a set of aggregation operations and 445 have these indicated by a flag(s) in the attribute (ie addi- 446 tion, union, drop if !equal, etc.), (d) other suggestions? 448 4 Details of GLP Attributes 450 This section provides a detailed description for each of the recom- 451 mended attributes of GLP. The processing of the attribute is 452 addressed in each of the following stages of route processing: route 453 origination, route selection, aggregation, and route dissemination. 455 4.1 DestinationPhoneNumbers 457 Mandatory: True. 458 Flags: Well-known. 460 The DestinationPhoneNumbers attribute describes the phone numbers 461 that are covered by this call routing object. If a phone number is 462 covered by this call routing object, then this object can be used to 463 reach that phone number. Note that certain phone numbers or ranges 464 may not exist on the PSTN, even though they are covered by this set. 465 Black-holes (i.e., ranges of non-existant PSTN numbers) should not be 466 advertised within GLP. 468 4.1.1 Syntax of DestinationPhoneNumbers 470 Phone numbers are represented by a string of digits giving a phone 471 number prefix. All phone numbers starting with this prefix are 472 covered by this call routing object. 474 The syntax for the phone number prefix is: 475 phone-number-bound = +1*phone-digit 476 phone-digit = DIGIT 477 DIGIT = '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9' 479 This format is similar to the format for a global telephone number as 480 defined in SIP [4] without visual separators. This format facili- 481 tates efficient comparison when using GLP to route SIP or H323, both 482 of which use character based representations of phone numbers. 484 Editor's Note. This section is purposefully left somewhat 485 vague due to the fact that one of the GLP proposals under con- 486 sideration [2] uses an existing BGP extension to carry the 487 this information and the next-hop, while the other proposal 488 [3] would use new extensions for both. 490 4.1.2 Route Origination and DestinationPhoneNumbers 492 A gateway that can reach all valid numbers in the area code +1919 493 should advertise +1919 as the DestinationPhoneNumbers, even though 494 there may be more specific prefixes that do not actually exist on the 495 PSTN. 497 Destination phone numbers are injected into GLP by a method outside 498 the scope of GLP. Possible methods include the front-end protocol, 499 and intra-domain protocol, or static configuration. The originating 500 LS must include the DestinationPhoneNumbers in every call routing 501 object. 503 4.1.3 Route Selection and DestinationPhoneNumbers 505 The destination phone numbers are a necessary criteria for route 506 selection. 508 4.1.4 Aggregation and DestinationPhoneNumbers 510 To aggregate multiple call routing objects, the set of Destination- 511 PhoneNumbers must combine to form a less specific set. For example, 512 the prefixes +19190, +19191, +19192, +19193, +19194, +19195, +19196, 513 +19197, +19198, and +19199 could be aggregated to form the prefix 514 +1919. 516 In general, it takes ten (10) prefixes of length n to aggregate into 517 a prefix of length n-1. However, if an LS is aware that a prefix is 518 an invalid PSTN prefix, then fewer more specific prefixes may be 519 required. For example, if the prefix +19191 is known not to exist, 520 then an LS can aggregate to +1919 without +19191. A prefix 521 representing an invalid set of PSTN destinations is sometimes 522 referred to as a "black-hole". The method by which an LS is aware 523 of black-holes is not within the scope of GLP. It is recommended 524 that an LS not explicitly advertise black-holes. 526 Editor's Note. We debated whether an LS should advertise 527 black-holes within GLP, but came to the consensus that expli- 528 cit black-hole advertisements should not be in GLP. It seems 529 unimportant whether signaling to an invalid number fails at 530 the ingress, egress, or such an LS. Knowledge of black-holes 531 helps aggregation, but the best option seemed to be keeping 532 the distribution of this knowledge outside of GLP. Note that 533 an LS cannot be prevented from advertising something it knows 534 to be a black-hole. 536 Editor's Note. We were unable to reach consensus on the issue 537 of "scope". Using scope to geographically limit the distribu- 538 tion of 800 numbers seemed like a bad idea, but there seems to 539 be a need to map some non-unique numbers into a globally 540 unique number space. The disagreement over scope centered on 541 whether one should apply this concept to just 800-type 542 numbers, or to any private numbering space. One camp believed 543 that private numbers should not be advertised between domains, 544 that the definition of private implied intra-domain only. The 545 other camp believed that a confederation of providers may com- 546 bine to provide a "VPN-like" service for handling private 547 numbering spaces across domains, and hence that private 548 numbers should be mapped into something globally unique and be 549 carried between domains. Comments? 551 4.1.5 Route Dissemination and DestinationPhoneNumbers 553 The DestinationPhoneNumbers attribute should be propagated to peers 554 unchanged except by aggregation. 556 Editor's Note. The following alternative representation to 557 prefixes was suggested. Each digit position is represented by 558 a 10-bit bitmask. If digit position i has bit j set, then the 559 digit j can appear in position i. As an example, to 560 [0100000000] represents all numbers starting with 1, and 561 [0100000000, 0111111110] represents all numbers starting with 562 11, 12, 13, ..., or 18. This representation is very flexible 563 with regards to aggregation, but its unclear how, given a 564 phone number, one finds the 'most specific' match in an effi- 565 cient manner. 567 4.2 NextHopSignalingServer 569 Mandatory: True. 570 Flags: Well-known. 572 The NextHopSignalingServer gives the address to which signaling mes- 573 sages should be forwarded when routing a call using this object. 575 4.2.1 NextHopSignalingServer Syntax 577 For generality, the address of the next-hop signaling server may be 578 of various types (IPv4, IPv6, etc). The NextHopSignalingServer 579 attribute includes an address type identifier, address length, and a 580 next-hop address. The type of address is given by an Address Family 581 Identifier as defined in RFC1700 [6]. 583 Editor's Note. This section is purposefully left somewhat 584 vague due to the fact that one of the GLP proposals under con- 585 sideration [2] uses an existing BGP extension to carry the 586 this information and the destination phone numbers, while the 587 other proposal [3] would use new extensions for both. 589 4.2.2 Route Origination and NextHopSignalingServer 591 When an LS originates a call routing object into GLP, it must include 592 a NextHopSignalingServer within its domain. The NextHopSignaling- 593 Server could be an address of the egress gateway or of a signaling 594 proxy. 596 4.2.3 Route Selection and NextHopSignalingServer 598 LS policy may prefer certain next-hops over others. 600 Editor's Note: Is it necessary to include the domain of the 601 next-hop for policy applications? Ie, is it a viable policy 602 to prefer the next hop to be in domain X? It may be possible 603 to get the domain of the next-hop from the LastModifiedBy 604 attribute, but this needs to be verified. The SignalingPath 605 attribute (Section 5.5) is another possible way to get this 606 information. 608 4.2.4 Aggregation and NextHopSignalingServer 610 When aggregating multiple routing objects into a single routing 611 object, an LS must insert a new signaling server from within its 612 domain as the new NextHopSignalingServer. 614 4.2.5 Route Dissemination and NextHopSignalingServer 616 When propagating routing objects to peers, an LS may choose to insert 617 an address of a signaling proxy within its domain as the new next- 618 hop, or it may leave the next-hop unchanged. Inserting a new address 619 as the next-hop will cause the signaling messages to be sent to that 620 address, and will provide finer control over the signaling path. 621 Leaving the next-hop unchanged will yield a more efficient signaling 622 path (ie fewer hops). It is a local policy decision of the LS to 623 decide whether to propagate or change the NextHopSignalingServer. 625 4.3 AdvertisementPath 627 Mandatory: True. 628 Flags: Well-known. 630 The AdvertisementPath attribute is analogous to the AS_PATH attribute 631 in BGP. The attributes differ in that BGP's AS_PATH also reflects 632 the path to the destination. In GLP, the next-hop need not be modi- 633 fied by every domain along the path, so the AdvertisementPath may 634 include many more hops than the actual signaling path to the 635 destination. The NumSignalingHops attribute reflects the number of 636 signaling hops to the destination. 638 This attribute identifies the ITADs through which routing information 639 carried in an advertisement has passed. 641 4.3.1 AdvertisementPath Syntax 643 AdvertisementPath is a variable length attribute that is composed of 644 a sequence of ITAD path segments. Each ITAD path segment is 645 represented by a triple . 648 The path segment type is a 1-octet long field with the following 649 values defined: 651 ValueSegment Type 653 1. AP_SET: unordered set of ITADs a route in the advertisement mes- 654 sage has traversed 656 2. AP_SEQUENCE: ordered set of ITADs a route in the advertisement 657 message has traversed 659 The path segment length is a 1-octet long field containing the 660 number of ITADs in the path segment value field. 662 The path segment value field contains one or more ITAD numbers, each 663 encoded as a 2-octets long field. ITAD numbers uniquely identify an 664 Internet Telephony Administrative Domain, and must be obtained from 665 IANA. See Section 7.3 for procedures to obtain an ITAD number from 666 IANA. 668 4.3.2 Route Origination and AdvertisementPath 670 When an LS originates a route then: 672 a) The originating LS shall include its own ITAD number in the 673 AdvertisementPath attribute of all advertisements sent to LSs 674 located in neighboring ITADs. In this case, the ITAD number of the 675 originating LS's ITAD will be the only entry in the Adver- 676 tisementPath attribute. 678 b) The originating LS shall include an empty AdvertisementPath 679 attribute in all advertisements sent to LSs located in its own 680 ITAD. An empty AdvertisementPath attribute is one whose length 681 field contains the value zero. 683 4.3.3 Route Selection and AdvertisementPath 685 The AdvertisementPath may be used for route selection. Possible cri- 686 teria to be used are the number of hops on the advertisement path and 687 the presence or absence of particular ITADs on the advertisement 688 path. 690 4.3.4 Aggregation and AdvertisementPath 692 If routes to be aggregated have identical AdvertisementPath attri- 693 butes, then the aggregated route has the same AdvertisementPath 694 attribute as each individual route. 696 For the purpose of aggregating AdvertisementPath attributes of two 697 routes, we model each ITAD as a tuple , where "type" 698 identifies a type of the path segment the ITAD belongs to (e.g. 699 AP_SEQUENCE, AP_SET), and "value" is the ITAD number. Two ITADs are 700 said to be the same if their corresponding tuples are 701 the same. 703 For the purpose of aggregating AdvertisementPath attributes we model 704 each ITAD within the AdvertisementPath attribute as a tuple , where "type" identifies a type of the path segment the ITAD 706 belongs to (e.g. AP_SEQUENCE, AP_SET), and "value" is the ITAD 707 number. If the routes to be aggregated have different Adver- 708 tisementPath attributes, then the aggregated AdvertisementPath attri- 709 bute shall satisfy all of the following conditions: 711 - All tuples of the type AP_SEQUENCE in the aggregated Adver- 712 tisementPath shall appear in all of the AdvertisementPath in the 713 initial set of routes to be aggregated. 715 - All tuples of the type AP_SET in the aggregated AdvertisementPath 716 shall appear in at least one of the AdvertisementPath in the ini- 717 tial set (they may appear as either AP_SET or AP_SEQUENCE types). 719 - For any tuple X of the type AP_SEQUENCE in the aggregated Adver- 720 tisementPath which precedes tuple Y in the aggregated Adver- 721 tisementPath, X precedes Y in each AdvertisementPath in the initial 722 set which contains Y, regardless of the type of Y. 724 - No tuple with the same value shall appear more than once in the 725 aggregated AdvertisementPath, regardless of the tuple's type. 727 An implementation may choose any algorithm which conforms to these 728 rules. At a minimum a conformant implementation shall be able to 729 perform the following algorithm that meets all of the above condi- 730 tions: 732 - determine the longest leading sequence of tuples (as defined 733 above) common to all the AdvertisementPath attributes of the routes 734 to be aggregated. Make this sequence the leading sequence of the 735 aggregated AdvertisementPath attribute. 737 - set the type of the rest of the tuples from the AdvertisementPath 738 attributes of the routes to be aggregated to AP_SET, and append 739 them to the aggregated AdvertisementPath attribute. 741 - if the aggregated AdvertisementPath has more than one tuple with 742 the same value (regardless of tuple's type), eliminate all, but one 743 such tuple by deleting tuples of the type AP_SET from the aggre- 744 gated AdvertisementPath attribute. 746 An implementation which chooses to provide a path aggregation algo- 747 rithm which retains significant amounts of advertisement path infor- 748 mation may wish to use the following procedure: 750 For the purpose of aggregating AdvertisementPath attributes of two 751 routes, we model each ITAD as a tuple , where "type" 752 identifies a type of the path segment the ITAD belongs to (e.g. 753 AP_SEQUENCE, AP_SET), and "value" is the ITAD number. Two ITADs are 754 said to be the same if their corresponding tuples are 755 the same. 757 The algorithm to aggregate two AdvertisementPath attributes works as 758 follows: 760 a) Identify the same ITADs (as defined above) within each Adver- 761 tisementPath attribute that are in the same relative order within 762 both AdvertisementPath attributes. Two ITADs, X and Y, are said to 763 be in the same order if either: 764 - X precedes Y in both AdvertisementPath attributes, or 765 - Y precedes X in both AdvertisementPath attributes. 767 b) The aggregated AdvertisementPath attribute consists of ITADs 768 identified in (a) in exactly the same order as they appear in the 769 AdvertisementPath attributes to be aggregated. If two consecutive 770 ITADs identified in (a) do not immediately follow each other in 771 both of the AdvertisementPath attributes to be aggregated, then the 772 intervening ITADs (ITADs that are between the two consecutive ITADs 773 that are the same) in both attributes are combined into an AP_SET 774 path segment that consists of the intervening ITADs from both 775 AdvertisementPath attributes; this segment is then placed in 776 between the two consecutive ITADs identified in (a) of the aggre- 777 gated attribute. If two consecutive ITADs identified in (a) immedi- 778 ately follow each other in one attribute, but do not follow in 779 another, then the intervening ITADs of the latter are combined into 780 an AP_SET path segment; this segment is then placed in between the 781 two consecutive ITADs identified in (a) of the aggregated attri- 782 bute. 784 If as a result of the above procedure a given ITAD number appears 785 more than once within the aggregated AdvertisementPath attribute, 786 all, but the last instance (rightmost occurrence) of that ITAD number 787 should be removed from the aggregated AdvertisementPath attribute. 789 4.3.5 Route Dissemination and AdvertisementPath 791 When an LS propagates a route which it has learned from another LS, 792 it shall modify the route's AdvertisementPath attribute based on the 793 location of the LS to which the route will be sent: 795 a) When a given LS advertises the route to another LS located in 796 its own ITAD, the advertising LS shall not modify the Adver- 797 tisementPath attribute associated with the route. 799 b) When a given LS advertises the route to an LS located in a 800 neighboring ITAD, then the advertising LS shall update the 801 AdvertisementPath attribute as follows: 803 1) if the first path segment of the AdvertisementPath is of type 804 AP_SEQUENCE, the local system shall prepend its own ITAD 805 number as the last element of the sequence (put it in the 806 leftmost position). 808 2) if the first path segment of the AdvertisementPath is of type 809 AP_SET, the local system shall prepend a new path segment of 810 type AP_SEQUENCE to the AdvertisementPath, including its own 811 ITAD number in that segment. 813 4.4 GatewayCapacity 815 Mandatory: True. 816 Flags: Well-known. 818 The gateway capacity attribute is used to characterize the number of 819 calls a gateway is capable of handling. In reality, a gateway's capa- 820 city is dependent on many things, including the rates of its 821 telephony interfaces (PRI, T1, T3), the rate of its IP interfaces 822 (10Base-T, 100Base-T, T1), the number of codecs it can simultaneously 823 support, the amount of memory and processing it has for handling 824 signaling, and local policy. Rather than breaking capacity into a 825 complex function of all these factors, it is represented by a single 826 metric - gateway capacity - in units of calls. 828 The purpose of the metric is twofold. First, it provides a useful 829 input to route selection. Secondly, it can serve as a means for load 830 balancing. 832 Its use as a tool for route selection is readily understood. When 833 presented with two routes which can reach the same phone prefixes, an 834 LS might prefer to select the route with the larger capacity, and 835 propagate that one. The capacity metric can be used to drive more 836 complex logic, limited only by the expressiveness of the policy at 837 the LS. 839 The capacity metric can also be used as a means for load balancing. 840 Consider LS A, which has two routes to the same prefix P. The first 841 route has a gateway capacity of 10, and the second route has a gate- 842 way capacity of 20. LS A aggregates these two, and propagates a route 843 with capacity 30 (see Section 4.4.5 for more details on aggregating 844 this attribute). When signaling messages arrive, the LS must decide 845 which route to use. Since the first gateway has twice the capacity 846 of the second, it can send 2/3 of its calls to the first, and 1/3 to 847 the second. It can do so in a round-robin fashion, or through 848 weighted hash functions on the call identifiers for each call. 850 Editor's Note. The exact methods for load-balancing require 851 more work, but we believe load-balancing to be a valuable and 852 important feature for GLP. 854 Note, however, that the capacity attribute SHOULD NOT be treated as a 855 guarantee on available capacity (i.e., that an LS can always initiate 856 calls through a route so long as the number of calls is below the 857 capacity), nor should it be treated as an absolute limit on capacity 858 (i.e., that if an LS sends a call to a gateway, but there are already 859 as many calls as indicated by the capacity, the next is rejected). 860 Such guarantees can only be made through static division of capacity 861 between peers, which is wasteful and difficult to administer. Furth- 862 ermore, the aggregation procedures below are inexact, and the result- 863 ing capacities can not carry the same guarantees as the original. 865 For this reason, if a gateway has capacity C, it is acceptable for 866 the originating gateway to advertise this gateway to two different 867 peers, both with the capacity C. 869 4.4.1 Capacity Syntax 870 The gateway capacity is an unsigned 32 bit quantity. 872 4.4.2 Route Origination and Capacity 874 The capacity attribute is mandatory in originated routes. It is set 875 to the actual call capacity of the gateway, determined at the discre- 876 tion of the administrator. 878 4.4.3 Route Selection and Capacity 880 The capacity attribute MAY be used as an input to route selection, as 881 discussed above. 883 4.4.4 Aggregation and Capacity 885 Aggregation of the capacity attribute is non-trivial. The most 886 simple-minded approach is to add the capacity attributes of two 887 routes when aggregating. This approach is sensible when the prefixes 888 are the same. However, when they are not, this approach makes less 889 sense. Consider two routes, A and B. Route A is to the prefix 890 15551212 only, with capacity 100. Route B is to the prefix 1, with 891 capacity 1. Aggregating the prefixes is easy - the resulting aggre- 892 gate prefix is 1. However, the capacity is not really 101. Nearly 893 all of the calls in this prefix will be routed to B, which only has 894 capacity 1. As such, the process of aggregating capacity needs to 895 take into consideration the relative size of phone prefixes being 896 aggregated. 898 The difficulty is that the call capacity in the aggregate is no 899 longer uniform across the prefix space. As such, the meaning of capa- 900 city must be redefined in such a way as to make sense for aggregates. 901 The following definition appears sensible: 903 Calls are made randomly and uniformly within the space of the 904 prefix advertised by the route. The capacity C of the route is 905 one less than the expected number of calls that can occur 906 before the route runs out of space. The route runs out of 907 space for a set of calls when it is impossible to distribute 908 the calls to the component gateways in such a way that all 909 calls can go through. 911 Lets say an aggregate is composed of two non-overlapping prefixes p1 912 and p2, of sizes w1 and w2 numbers respectively, and with capacities 913 c1 and c2 respectively. Here, size refers to the number of phone 914 numbers covered by the prefix. As calls are made to the aggregate, 915 the calls fall within prefixes p1 and p2 with certain probabilities. 916 So, if there are N calls, a certain number, on average, full within 917 p1 (and thus go to the first gateway), and another number, on 918 average, fall within p2 (and thus go to the second gateway). The 919 capacity of the aggregate is the number of calls N which cause either 920 the first gateway or the second gateway to run out of room, on aver- 921 age. 923 Specifically, the probability of a call being within p1 is w1/(w1 + 924 w2), and the probability of call being within p2 is w2/(w1+2). When 925 there are N calls, there will be, on average, N*w1/(w1+w2) to the 926 first prefix, and N*w2/(w1+w2) to the second prefix. The capacities 927 of these prefixes are c1 and c2 respectively. Thus, the first prefix 928 is exhausted, on average, when N = c1*(w1+w2)/w1, and the second pre- 929 fix when N = c2*(w1+w2)/w2. The capacity of the aggregate (c3) is the 930 minimum of these. So: 932 c3 = min(c1*(w1+w2)/w1, c2(w1+w2)/w2) 934 When w1 << w2, c3 = c2, and when w2 << w1, c3=c1. This is intuitive. 935 The capacity of the aggregate is closest to the capacity of its larg- 936 est component. When w1=w2 and c1=c2, c3=c1+c2, which is also intui- 937 tive. 939 When the prefixes overlap, the result is different. Assume prefix p2 940 is completely within prefix p1. In this case: 942 c3 = min(c1*w1/(w1-w2), (c1+c2)*w1/w2) 944 Note that in this case, the primary attribute being aggregated is the 945 Capacity attribute, not on the DestinationPhoneNumbers attribute. 947 So how are w1 and w2 computed? In the case of IP addresses, a prefix 948 of M bits contains 2^(32-M) addresses. This is because IP addresses 949 are a fixed length of 32 bits. However, phone number prefixes are of 950 variable length. Fortunately, the exact size of the prefix does not 951 matter. In all of the computations above, it is only the relative 952 sizes that are important. So, assume that phone numbers prefixes can 953 have at most K digits. In that case, a prefix with d digits is of 954 size 10^(K-d). So, with w1 = 10^(K-d1) and w2 = 10^(K-d2), the first 955 of the above two equations becomes: 957 c3 = min(c1*(10^(K-d1)+10^(K-d2))/10^(K-d1), 958 c2*(10^(K-d1)+10^(K-d2))/10^(K-d2)) 960 Factoring out the 10^K term: 962 c3 = min(c1*(10^-d1 + 10^-d2)/10^-d1, 963 c2*(10^-d1 + 10^-d2)/10^-d2) (Eq. 1) 965 This means that the actual size of the prefix does not matter, as far 966 as capacity computations are concerned. Only the relative sizes are 967 important. Performing the same computation for the second capacity 968 expression: 970 c3 = min(c1*(10^-d1)/(10^-d1 - 10^-d2), 971 (c1+c2)*10^-d1/10^-d2) (Eq. 2) 973 When performing aggregation of capacity metrics, Eq. 1 SHOULD be used 974 when the prefixes being aggregated do not overlap, and Eq. 2 SHOULD 975 be used when the second prefix is completely encompassed within the 976 first. If an LS has more precise information about the size of a 977 prefix or the probability distribution of calls, it MAY use alternate 978 means to compute the aggregated capacity. These equations should be 979 applied iteratively when the set being aggregated contains more than 980 two prefixes. 982 4.4.5 Route Dissemination and Capacity 984 The capacity attribute represents the call handling capacity of the 985 gateway itself. This says nothing about the capacity of the media 986 path or of the capacity of the signaling path. However, an intermedi- 987 ate LS MAY modify the gateway capacity if it modifies the next hop, 988 to reflect any known restrictions in capacity from the signaling and 989 or media paths. An LS MAY increase or decrease the capacity, but it 990 is RECOMMENDED that an LS only decrease it. If an LS propagates a 991 route but does not modify the next hop, it SHOULD NOT modify the 992 capacity. 994 4.5 SignalingProtocols 996 Mandatory: False. 997 Flags: Optional, DependentTransitive. 999 The signaling protocols attribute specifies the signaling protocols 1000 and key signaling protocol parameters that are understood by the next 1001 hop signaling server. It is always re-originated by an LS which modi- 1002 fies the next hop, to reflect the capabilities of that next hop. 1004 The attribute contains both the basic protocol (currently, codepoints 1005 exist for SIP, H.323/Q.931 and H.323/RAS; others can be registered 1006 with ICANN), and parameters of that protocol necessary to determine 1007 interoperability or required for signaling exchange. Specifically, 1008 this includes transport protocols (TCP or UDP), port numbers, and 1009 ISUP-variants. The ISUP-variants component is present since some sig- 1010 naling protocols, such as SIP, can carry ISUP messages in their 1011 bodies. These ISUP messages are analyzed, processed, and potentially 1012 translated by intermediate signaling servers. As such, it is impor- 1013 tant to know what ISUP variants, if any, are supported by a signaling 1014 server. 1016 4.5.1 SignalingProtocols Syntax 1018 The signaling protocols attribute is a set of TLV objects. The type 1019 field is one byte, length is two bytes, and value has the length 1020 specified by the length field. Some objects may appear more than 1021 once. Whether this is allowed, and the meaning when this happens, 1022 depends on the type. 1024 Editor's Note: We should probably make each signalling proto- 1025 col into its own attribute because much of the related infor- 1026 mation is specific to one particular signalling protocol. For 1027 example, the UDP port numbers will likely be different if a 1028 single server supports both SIP & H323. 1030 4.5.1.1 Base Protocol 1032 The base protocol object is variable length, as indicated by the 1033 length field. In indicates the base signaling protocols supported. 1034 Each protocol is indicate by a single byte. Thus, if three signaling 1035 protocols are supported, the length of the object is three bytes. 1036 Currently defined values are: 1038 0: SIP 1039 1: H323/Q.931 1040 2: H323/RAS 1042 Others can be registered with IANA as needed. 1044 4.5.1.2 Transport Protocol 1046 The transport protocol object is variable length, as indicated by the 1047 length field. In indicates the base transport protocols supported. 1048 Each protocol is indicate by a single byte. Thus, if two transport 1049 protocols are supported, the length of the object is two bytes. 1050 Currently defined values are: 1052 0: UDP 1053 1: TCP 1055 Others may be defined in future versions of GLP as needed. 1057 4.5.1.3 ISUP flavors supported 1059 The ISUP flavors protocol object is variable length, as indicated by 1060 the length field. It contains a number of ISUP flavors, each of which 1061 is a NULL terminated string. These strings are the ISUP flavor type 1062 names registered with IANA. 1064 Editors Note: This registry doesn't exist right now, but its 1065 not really a GLP specific thing. So, its not clear whether 1066 registration procedures should be established here or else- 1067 where. 1069 4.5.1.4 Port Number 1071 The port number object is a single, 16 bit quantity. It represents 1072 the port number to use for the signaling. If not specified, the 1073 default port for the signaling protocol is used. 1075 4.5.2 Route Origination and SignalingProtocols 1077 Routing objects MAY be originated with a signaling types attribute. 1078 If not present, it is assumed that the signaling protocol is deter- 1079 mined out of bands by some other means (i.e., a closed network of GLP 1080 peers may be a strictly H.323 or SIP network), and all other parame- 1081 ters take their defaults. 1083 4.5.3 Route Selection and SignalingProtocols 1085 Signaling types MAY be used as an input to route selection. Possible 1086 criteria include the base protocol itself and ISUP variants under- 1087 stood. 1089 4.5.4 Route Aggregation and SignalingProtocols 1091 The signaling type attribute is never aggregated. When the next hop 1092 signaling server changes (as it must when aggregation occurs), the 1093 signaling protocol attribute MUST be changed to reflect the capabili- 1094 ties of the local signaling server. 1096 4.5.5 Route Dissemination and SignalingProtocols 1098 When the next hop is unchanged, the LS MUST NOT modify the signaling 1099 type attribute. When the LS changes the next hop signaling attribute, 1100 it MUST modify the signaling types attribute to reflect the capabili- 1101 ties of the new path. An LS must have knowledge of the signaling 1102 capabilities of the next-hop when inserting a SignalingProtocols 1103 attribute into a routing object with that next-hop. When advertising 1104 a signaling protocol as being supported by a next-hop, the LS must 1105 also ensure that the signaling protocol is supported by the entire 1106 path. As an example, an LS must not insert a SignalingProtocols 1107 attribute advertising SIP is supported by the next-hop unless the 1108 next-hop supports SIP AND either 1109 - the inbound routing object also advertised SIP, or 1110 - the next-hop is known to support translation from SIP into a sig- 1111 naling protocol supported by the previous hop. 1113 4.6 Pricing 1115 Mandatory: False. 1116 Flags: Well-known. 1118 The pricing attribute conveys information about the cost of terminat- 1119 ing calls at a gateway. The pricing reflects the cost of the PSTN 1120 component of the call only. The actual cost of a completing a call 1121 to a gateway might include costs for media transport, but these are 1122 outside the scope of this attribute. 1124 When the cost attribute is sent in a route from A to B, it indicates 1125 the amount that A will charge B for calls along the route. As such, 1126 the pricing attribute is non-transitive - it has significance only 1127 between peers. This is in line with the GLP model overall, since two 1128 LS's communicate only when their administrators have established 1129 administrative agreements with each other. 1131 Since pricing is at the discretion of the provider, GLP does not res- 1132 trict the pricing models that can be used. It provides a common set 1133 of pricing mechanisms. Additional ones can be registered with ICANN 1134 and used, as needed. The common pricing mechanisms provided are: 1135 * connect charge plus per minute rate 1137 4.6.1 Pricing Syntax 1139 The capacity attribute contains a 16 bit sub-type field and a vari- 1140 able length value. The sub-type field indicates the specific type of 1141 cost. Several sub-types are defined here. Others can be registered 1142 with ICANN. The value depends on the sub-type. 1144 4.6.1.1 Subtype 0: connect charge plus per minute rate 1146 The value field contains a 32 bit currency value, a 32 bit floating 1147 point connect charge value, and a 32 bit floating point per minute 1148 rate value. 1150 Currency values can be registered with ICANN. Some common types are 1151 provided here. They include: 1152 0: US Dollar 1153 1: Japanese Yen 1154 2: British Pound 1155 3: Euro 1156 4: German Deutchmark 1157 5: French Franc 1158 Procedures for registering additional currency types are given in 1159 section 7.4. 1161 The currency value has the same syntax and semantics as described 1162 above. The connect charge value indicates the number of units of the 1163 currency charged for each call completed. The per minute rate value 1164 indicates the number of units of the currency charged per minute in 1165 addition to the connect rate. 1167 Editor's Note. We believe currency codes are already 1168 used/defined in other IETF documents (OTP?). We should use 1169 the same currency codes if possible. Registering new codes is 1170 only required if we have to define them. 1172 Editor's Note. We need to specify a floating point represen- 1173 tation. 1175 Editor's Note. We probably need to provide a time unit as 1176 well because different plans have different time units (ie the 1177 rate gets incremented every 6 seconds, every minute, etc). We 1178 should look at ITU SG16 Annex G for a good example. 1180 4.6.2 Route Origination and Pricing 1182 Routes originating by an LS may contain a Pricing attribute. It is a 1183 local policy issue whether the Pricing attribute is included in ori- 1184 ginated call routing objects, and what the Pricing attribute con- 1185 tains. 1187 4.6.3 Route Selection and Pricing 1189 Route selection is definitely driven by the Pricing attribute. An LS 1190 may decide to prefer routes that are cheaper, for example. 1192 4.6.4 Aggregation and Pricing 1194 The Pricing attribute is never aggregated. It is always re-originated 1195 at each LS. This is because it represents a charging agreement 1196 between the sending LS and the receiving LS. The Pricing attribute 1197 re-originated at each LS may bear no resemblance at all to the Pric- 1198 ing attribute received by that LS for the same route, or it may be 1199 identical. 1201 4.6.5 Route Dissemination and Pricing 1203 When an LS disseminates a route, it must re-originate the pricing 1204 attribute as if it had created the route itself. 1206 Editor's Note: Should we relax these rules a bit? Can an LS 1207 propagate the pricing attribute if it doesn't change the next 1208 hop? This would allow the LastModifiedBy attribute to contain 1209 a signature for the pricing attribute as well. Should a LS be 1210 allowed to alter the Pricing attribute if it is not altering 1211 the next-hop? In this case, its not on the signalling path, 1212 so how would payment be received? 1214 Editor's Note. There a some possible methods for handling 1215 aggregation and route propagation of the Pricing attribute 1216 that might be worth investigation. The attribute itself 1217 might indicate its processing. For example, it could refer- 1218 ence a Java applet, or could be written in a well-known 1219 language like TCL or XML so that the data itself defines its 1220 properties. This possibility would definitely need more 1221 investigation. 1223 Editor's Note. It would seem beneficial if the Pricing attri- 1224 bute subtypes could be negotiated during peer session estab- 1225 lishment, so that an LS uses a pricing language understood by 1226 its peer. 1228 4.7 LastModifiedBy 1230 Mandatory: False. 1231 Flags: Well-known. 1233 The LastModifiedBy attribute provides information about the last LS 1234 that modified certain attributes of an advertisement. It also con- 1235 tains information to authenticate these attributes. 1237 GLP will provide a mechanism for hop-by-hop authentication between 1238 GLP peers. Peer-to-peer authentication is independent of the data 1239 elements. 1241 Some GLP attributes are for GLP's internal use, e.g. LocalPreference, 1242 AtomicAggregate, and MultiExitDisc. For these, hop-by-hop 1243 authentication is sufficient. However, attributes that are passed to 1244 the application in response to a call routing query probably require 1245 end-to-end authentication, or at least authentication since the last 1246 point of modification. For example, end-to-end authentication is not 1247 possible after route aggregation. In this case, authentication from 1248 the point of aggregation is the best possible. It is a local policy 1249 decision to determine whether authentication of received attributes 1250 is necessary. It is also a local policy decision to determine 1251 whether to add or propagate the LastModifiedBy attribute, and which 1252 attributes should be covered by the authentication. The attributes 1253 requiring authentication since the last modification point will prob- 1254 ably include: 1255 - DestinationPhoneNumbers 1256 - NextHopSignalingServer 1257 - SignalingProtocols 1258 - GatewayCapacity 1259 - Pricing 1260 - LastModifiedBy 1262 When computing the authentication data, an LS must consider only 1263 those attributes with the LastModifiedByFlag set, and must consider 1264 these in numerical order. 1266 4.7.1 LastModifiedBy Syntax 1268 The LastModifiedBy attribute is a variable length attribute. It con- 1269 sists of: 1270 (1) Type of LS identifier, 1 byte 1271 (2) Length of LS identifier, 1 byte 1272 (3) ITAD number of LS, 2 bytes (similar to BGP ASes) 1273 (4) LS identifier, variable 1274 (5) Authentication data, variable 1276 The detailed format of these fields are TBD. 1278 Editor's Note. The intent of this attribute is to allow an LS 1279 to 'sign' certain attributes. Receivers must be able to ver- 1280 ify this signature, so some type of identification of the pro- 1281 vider must be provided. This might be an IPv4 address, an 1282 IPv6 address, a DNS name, etc. The LS-type above should 1283 define what kind of identifier is provided (IPv, IPv6, DNS, 1284 etc.), and the identifier should carry that value. 1286 4.7.2 Route Origination and LastModifiedBy 1288 When an LS originates a call routing object into GLP, it may include 1289 the LastModifiedBy attribute. If the LastModifiedBy attribute is 1290 included, the the LastmodifiedByFlag must be set for all attributes 1291 included in the LastModifiedBy authentication. 1293 4.7.3 Route Selection and LastModifiedBy 1295 The LS identifier and the ITAD number field of the LastModifiedBy 1296 attribute may be used a route selection criteria. 1298 4.7.4 Aggregation and LastModifiedBy 1300 The aggregating LS may choose to include the LastModifiedBy attribute 1301 in an aggregated object. The aggregating LS may select those attri- 1302 butes covered by the inserted LastModifiedBy attribute, and must set 1303 the LastModifiedBy flags accordingly. 1305 4.7.5 Route Dissemination and LastModifiedBy 1307 The values of the LastModifiedBy attribute must be recalculated 1308 before disseminating the route whenever: 1309 * The LastModifiedByFlag of an attribute changes, or 1310 * an attribute for which the LastModifiedByFlag is set changes. 1312 4.8 NumSignalingHops 1314 Mandatory: False. 1315 Flags: Optional, DependentTransitive. 1317 The NumSignalingHops attribute records the number of signaling hops 1318 between the local LS and the destination. The primary purpose of 1319 this attribute is as a criteria for route selection. 1321 Editor's Note. As an alternative to NumSignalingHops, a Sig- 1322 nalingPath attribute was considered. The SignalingPath attri- 1323 bute would be much like the AdvertisementPath, except it would 1324 only be updated when the next-hop changed. Thus, it would 1325 record the signaling path to the destination. It was not 1326 clear whether the SignalingPath attribute would be more useful 1327 than simply counting the number of hops, so for simplicity we 1328 went with the NumSignalingHops attribute. Would a Signaling- 1329 Path attribute be useful enough in policy to justify the added 1330 complexity? 1332 4.8.1 NumSignalingHops Syntax 1334 The NumSignalingHops attribute contains two unsigned 16-bit numeric 1335 values, the minNumSignalingHops and maxNumSignalingHops. Due to 1336 aggregation, a single call routing object may represent paths of 1337 varying lengths. The minimum and maximum give bounds on the lengths 1338 of these paths. 1340 4.8.2 Route Origination and NumSignalingHops 1342 When a LS originates a route into GLP, it may include the NumSig- 1343 nalingHops attribute with the minNumSignalingHops and maxNumSig- 1344 nalingHops set to zero (0). 1346 4.8.3 Route Selection and NumSignalingHops 1348 This attribute may be used in route selection to select routes with 1349 shorter signaling paths. 1351 4.8.4 Aggregation and NumSignalingHops 1353 When aggregating multiple routing objects into a single call routing 1354 object, an LS may choose to propagate the NumSignalingHops attribute. 1355 If it chooses to do so, the LS must propagate the minimum of the min- 1356 NumSignalingHops and the maximum of the maxNumSignalingHops in the 1357 NumSignalingHops attribute of the aggregated object. 1359 4.8.5 Route Dissemination and NumSignalingHops 1361 Intermediate LSs that alter the NextHopSignalingServer must increment 1362 the minimum and maximum values before propagating the NumSig- 1363 nalingHops attribute. Intermediate LSs that do not modify the Nex- 1364 tHopSignalingServer attribute should not modify this attribute. 1366 4.9 AtomicAggregate 1368 Mandatory: False. 1369 Flags: Well-known. 1371 The AtomicAggregate attribute indicates that a routing object may 1372 have traversed domains not listed in the AdvertisementPath. If an 1373 LS, when presented with a set of overlapping routes from a peer LS, 1374 selects the less specific (ie more phone number destinations) route 1375 without selecting the more specific route, then the LS includes the 1376 AtomicAggregate attribute with the routing object. 1378 4.9.1 AtomicAggregate Syntax 1380 This attribute has length zero (0). 1382 4.9.2 Route Origination and AtomicAggregate 1383 Call routing objects are never originated with the AtomicAggregate 1384 attribute. 1386 4.9.3 Route Selection and AtomicAggregate 1388 The AtomicAggregate attribute may be used in route selection - it 1389 indicates that the AdvertisementPath may be incomplete. 1391 4.9.4 Aggregation and AtomicAggregate 1393 If any of the call routing objects to aggregate has the AtomicAggre- 1394 gate attribute, so should the resultant aggregated object. 1396 4.9.5 Route Dissemination and AtomicAggregate 1398 If an LS, when presented with a set of overlapping routes from a peer 1399 LS, selects the less specific (ie more phone number destinations) 1400 route without selecting the more specific route, then the LS includes 1401 the AtomicAggregate attribute with the routing object (if its not 1402 already present). 1404 An LS receiving a routing object with an AtomicAggregate attribute 1405 must not make the set of destinations more specific when advertising 1406 it to other LSs, and must not remove the attribute when propagating 1407 this object to a peer LS. 1409 4.10 LocalPreference 1411 Mandatory: False. 1412 Flags: Well-known. 1414 The LocalPreference attribute is used intra-domain only, it indicates 1415 the local LS's preference for the routing object to other LSs within 1416 the same domain. This attribute should not be included when communi- 1417 cating to an LS in another domain. 1419 4.10.1 LocalPreference Syntax 1421 The LocalPreference attribute is a 4-octet unsigned numeric value. A 1422 higher value indicates a higher preference. 1424 4.10.2 Route Origination and LocalPreference 1426 Call routing objects should not be originated with the LocalPrefer- 1427 ence attribute. 1429 4.10.3 Route Selection and LocalPreference 1430 The LocalPreference attribute allows one LS in a domain to calculate 1431 a preference for a route, and to communicate this preference to other 1432 LSs in the domain. During route selection, a LS may determine its 1433 own preference for a call routing object, or it may use the 1434 LocalPreference attribute as its preference (if included). 1436 4.10.4 Aggregation and LocalPreference 1438 The LocalPreference attribute is not affected by aggregation. The 1439 inclusion of this attribute must follow the rules in Section 4.10.5. 1441 4.10.5 Route Dissemination and LocalPreference 1443 An LS must include the LocalPreference attribute when communicating 1444 with peer LSs within its own domain. An LS must not include the 1445 LocalPreference attribute when communicating with LSs in other 1446 domains. LocalPreference attributes received from inter-domain peers 1447 must be ignored. 1449 4.11 MultiExitDisc 1451 Mandatory: False. 1452 Flags: Optional, non-transitive. 1454 When two ITADs are connected by more than one set of peers, the Mul- 1455 tiExitDisc attribute may be used to specify preferences for routing 1456 objects received over one of those links over the others. The Mul- 1457 tiExitDisc parameter is used in route selection. 1459 4.11.1 MultiExitDisc Syntax 1461 The MultiExitDisc attribute carries a 4-octet unsigned numeric value. 1462 A lower value represents a more preferred routing object. 1464 4.11.2 Route Origination and MultiExitDisc 1466 Call routing objects should not be originated with the MultiExitDisc 1467 attribute. 1469 4.11.3 Route Selection and MultiExitDisc 1471 The MultiExitDisc attribute is used to express a preference when 1472 there are multiple links between two domains. If all other factors 1473 are equal, then a routing object with a lower MultiExitDisc attribute 1474 should be preferred over a routing object with a higher MultiExitDisc 1475 attribute. 1477 4.11.4 Aggregation and MultiExitDisc 1478 Call routing objects with differing MultiExitDisc parameters must not 1479 be aggregated. Call routing objects with the same value in the Mul- 1480 tiExitDisc attribute may be aggregated and the same MultiExitDisc 1481 attribute attached to the aggregated object. 1483 4.11.5 Route Dissemination and MultiExitDisc 1485 If received over from a peer LS in another domain, a LS may propagate 1486 the MultiExitDisc to other LSs within its domain. The MultiExitDisc 1487 attribute should not be propagated to LSs in other domains. 1489 An LS may add the MultiExitDisc attribute when propagating routing 1490 objects to an LS in another domain. The inclusion of the MultiExit- 1491 Disc attribute is a matter of policy, as is the value of the attri- 1492 bute. 1494 5 Recommended Non-Attributes 1496 In addition to the attributes mentioned in Section 4, many other 1497 attributes were under consideration for inclusion into GLP. In this 1498 section, we briefly mention these attributes, and why they weren't 1499 recommended for GLP in this draft. 1501 Some of the criteria used to select recommended attributes were: 1503 (a) If a value can be determined via signaling protocols, then it 1504 was not recommended. 1506 (b) If there were no good suggestions on how to aggregate it, it was 1507 not recommended. 1509 5.1 Origin 1511 BGP4 has an Origin attribute, which indicates whether the route ori- 1512 ginated from within the originating AS, or via a different exterior 1513 routing protocol. With GLP, there are no other existing routing pro- 1514 tocols, either interior or exterior, so Origin has no current func- 1515 tion in GLP. 1517 5.2 CodecsSupported 1519 The CodecsSupported attribute was considered to indicate the codes 1520 supported for the media path by the egress gateway(s). 1522 The codec to use for an RTP session can often be negotiated during 1523 signaling. For this reason, in addition to an effort to "keep it 1524 simple, stupid" (KISS), CodecsSupported is not recommended. 1526 5.3 EncryptionAlgsSupported 1528 Like CodecsSupported, the EncryptionAlgsSupported was considered to 1529 indicate the encryption algorithms supported by the egress gateway. 1531 This attribute is not recommended for the same reasons as the 1532 CodecsSupported attribute. 1534 5.4 TelephonyFeaturesSupported 1536 Like CodecsSupported, the TelephonyFeaturesSupported was considered 1537 to indicate the telephony features supported by the egress gateway. 1538 Potential telephony features considered were multi-party conferencing 1539 and video conferencing. 1541 This attribute is not recommended for the same reasons as the 1542 CodecsSupported attribute. 1544 5.5 SignalingPath 1546 The SignalingPath attribute was considered to record the signaling 1547 hops in the same way that the AdvertisementPath records the domains 1548 that the routing object has traversed. This attribute was targeted 1549 at route selection so that the administrator may choose shorter sig- 1550 naling paths or choose paths that go through certain domains. 1552 In an effort to simplify, the NumSignalingHops attribute is recom- 1553 mended instead. If the SignalingPath attribute can be demonstrated 1554 to be more useful than the NumSignalingHops attribute, then Sig- 1555 nalingPath may replace NumSignalingHops. 1557 5.6 SignalingPathCapacity 1559 The GatewayCapacity attribute indicates the relative size of egress 1560 gateways. The SignalingPathCapacity was suggested as an analog to 1561 the GatewayCapacity so that the signaling path could also be taken 1562 into consideration in route selection and load balancing. 1564 In general, the capacity of a signaling path is going to be limited 1565 by that of the egress gateways, so the usefulness of this metric was 1566 not demonstrated. Also, LSs could modify the GatewayCapacity attri- 1567 bute so that the signaling path is taken into account. 1569 5.7 MediaPathCapacity 1571 The MediaPathCapacity attribute was considered as another potential 1572 analog of GatewayCapacity, providing a metric on the size of the data 1573 path to the egress. 1575 This metric is only possible if the media path is tied to the signal- 1576 ing path. In general, this is not true because the media may go 1577 directly to the egress gateway even if the signaling goes to a proxy 1578 server. So this attribute was not recommended. 1580 5.8 GatewayProvider, NextHopProvider, Aggregator 1582 These attributes were intended to identify (perhaps in an authenti- 1583 cated manner) certain important domains along the advertised path, 1584 sometimes in an authenticated manner. 1586 Most of the function of these attributes is provided by the LastModi- 1587 fiedBy attribute, so these attributes were not recommended. 1589 5.9 Lifetime 1591 The Lifetime attribute was considered so that gateways could adver- 1592 tise the times at which certain routing objects are valid. For exam- 1593 ple, a gateway could indicate that a certain route (and the associ- 1594 ated price, etc) is only valid between the hours of 10:00 pm and 6:00 1595 am. 1597 Explicitly adding and removing routing objects seemed preferable to 1598 giving attributes Lifetimes, which would have required periodically 1599 sweeping the call routing table to remove and insert expired entries. 1601 5.10 Time-To-Live 1603 The Time-To-Live attribute was considered to limit the number of hops 1604 that a routing object may propagate. If LS peering relationships had 1605 some geographic significance, then the TTL attribute could be used to 1606 limit how far the information propagates. Such an attribute might be 1607 useful for certain "800" type services. 1609 Without a clearly demonstrated benefit for the TTL attribute, it was 1610 decided to not recommend this attribute for now. However, the rela- 1611 tive simplicity in supporting the attribute makes the attribute a 1612 good candidate to bring back of a clear need can be demonstrated. 1614 6 Security Considerations 1616 Peer-to-peer security (between adjacent LSs) is assumed to be pro- 1617 vided by the transport protocol. 1619 Security between LSs that are not adjacent is provided in two ways. 1620 First, the transitivity of the peer relationship provides some level 1621 of security. Second, the LastModifiedBy attribute can be used to 1622 sign a set of attributes, so that the receivers of the attributes can 1623 verify the authenticity of certain attributes. 1625 7 IANA Considerations 1627 This section discusses IANA registration procedures for parameters 1628 defined in GLP. 1630 7.1 IANA Considerations for registering new GLP attributes 1632 When registering new GLP attributes, the following information must 1633 be provided to IANA: 1635 1 Name of registering organization: company name, university, 1636 organization name. 1638 2. Name of principal contact: Name of the individual that is the 1639 primary contact point for questions and comments regarding the 1640 attribute. 1642 3. Email address of principal contact. 1644 4. Phone number of principal contact. 1646 5. Name of attribute: A short, descriptive name describing the 1647 attribute. For example - "supported codecs". 1649 6. Attribute Number: The numeric identifier for the attribute. This 1650 must not conflict with attribute numbers already defined in GLP 1651 or already registered. 1653 7. Description: Several sentences or paragraphs describing the pur- 1654 pose of the attribute. Sufficient detail must be provided to 1655 allow an implementor to determine whether or not the attribute 1656 is needed in their implementation, and if so, what its value 1657 should be. 1659 8. Flags: The values for the attribute flags. 1661 9. Originating considerations: Information useful for originating 1662 this attribute. Specifically, under what conditions it should be 1663 originated. 1665 10. Selection considerations: Information useful in using the attri- 1666 bute for route selection. 1668 11. Aggregation considerations: Clear rules on how the attribute is 1669 aggregated. 1671 12. Dissemination considerations: Information useful when dissem- 1672 inating the attribute. 1674 This information parallels that provided here in Section 4 for each 1675 attribute. 1677 7.2 Registering new pricing attribute sub-types with IANA 1679 When registering new pricing sub-types with IANA, the following 1680 information must be provided: 1682 1. Name of registering organization: company name, university, or 1683 organization name. 1685 2. Name of principal contact: Name of the individual that is the 1686 primary contact point for questions and comments regarding the 1687 sub-type. 1689 3. Email address of principal contact. 1691 4. Phone number of principal contact. 1693 5. Name of sub-type: A short, descriptive name describing the pric- 1694 ing sub-type. For example - ``per minute with peak'' 1696 6. Subtype Number: The numeric identifier for the sub-type. This 1697 must not conflict with sub-type numbers already defined in GLP 1698 or already registered. 1700 7. Description: Several sentences or paragraphs describing the 1701 meaning of the sub-type. 1703 8. Syntax of the value: The detailed syntax and semantics for the 1704 value component of the pricing element must be provided. 1706 9. Example: An example of a correctly formatted pricing attribute 1707 of this sub-type must be provided. 1709 7.3 Registering new ITAD Numbers with IANA 1711 When registering new ITAD numbers with IANA, the following informa- 1712 tion must be provided: 1714 1. Name of registering organization: company name, university, or 1715 organization name. This name must be unique. 1717 2. Name of principal contact: Name of the individual that is the 1718 primary contact point for questions and comments regarding the 1719 sub-type. 1721 3. Email address of principal contact. 1723 4. Phone number of principal contact. 1725 Editors Note: How is registration of AS's in BGP handled? 1726 RFC1771 has no IANA considerations section. 1728 7.4 Registering new Currency Types with IANA 1730 When registering new Currency types with IANA, the following informa- 1731 tion must be provided: 1733 1. Name of country: Name of country where currency is used 1735 2. Name of currency: Name of the currency 1737 3. Currency type number: An unused and unregistered type number for 1738 this currency. 1740 8 Open Issues 1742 In this section, we capture the open issues as identified throughout 1743 the document by Editor's Notes. This section just collects these 1744 notes, no new information is provided. 1746 8.1 Aggregation Rules for Transitive Attributes 1748 From Section 3.4.3: 1750 Editor's Note. There are several options available to handle 1751 unrecognized transitive attributes during aggregation. We can 1752 (a) drop them, (b) propagate them if they are binary 1753 equivalent, (c) define a set of aggregation operations and 1754 have these indicated by a flag(s) in the attribute (ie addi- 1755 tion, union, drop if !equal, etc.), (d) other suggestions? 1757 8.2 Black-holes 1759 From Section 4.1.4: 1761 Editor's Note. We debated whether an LS should advertise 1762 black-holes within GLP, but came to the consensus that expli- 1763 cit black-hole advertisements should not be in GLP. It seems 1764 unimportant whether signaling to an invalid number fails at 1765 the ingress, egress, or such an LS. Knowledge of black-holes 1766 helps aggregation, but the best option seemed to be keeping 1767 the distribution of this knowledge outside of GLP. Note that 1768 an LS cannot be prevented from advertising something it knows 1769 to be a black-hole. 1771 8.3 Scope 1773 From Section 4.1.4: 1775 Editor's Note. We were unable to reach consensus on the issue 1776 of "scope". Using scope to geographically limit the distribu- 1777 tion of 800 numbers seemed like a bad idea, but there seems to 1778 be a need to map some non-unique numbers into a globally 1779 unique number space. The disagreement over scope centered on 1780 whether one should apply this concept to just 800-type 1781 numbers, or to any private numbering space. One camp believed 1782 that private numbers should not be advertised between domains 1783 - that the definition of private implied intra-domain only. 1784 The other camp believed that a confederation of providers may 1785 combine to provide a "VPN-like" service for handling private 1786 numbering spaces across domains, and hence that private 1787 numbers should be mapped into something globally unique and be 1788 carried between domains. Comments? 1790 8.4 Phone number representation using bitmasks 1792 From Section 4.1.5: 1794 Editor's Note. The following alternative representation to 1795 prefixes was suggested. Each digit position is represented by 1796 a 10-bit bitmask. If digit position i has bit j set, then the 1797 digit j can appear in position i. As an example, to 1798 [0100000000] represents all numbers starting with 1, and 1799 [0100000000, 0111111110] represents all numbers starting with 1800 11, 12, 13, ..., or 18. This representation is very flexible 1801 with regards to aggregation, but its unclear how, given a 1802 phone number, one finds the 'most specific' match. 1804 8.5 Domain of NextHopSignalingServer 1806 From Section 4.2.3: 1808 Editor's Note: Is it necessary to include the domain of the 1809 next-hop for policy applications? Ie, is it a viable policy 1810 to prefer the next hop to be in domain X? It may be possible 1811 to get the domain of the next-hop from the LastModifiedBy 1812 attribute, but this needs to be verified. The SignalingPath 1813 attribute would represent another way to get this information. 1815 8.6 Load-balancing on capacity 1817 From Section 4.4: 1819 Editor's Note. The exact methods for load-balancing require 1820 more work, but we believe load-balancing to be a valuable and 1821 important feature for GLP. 1823 8.7 Separation of Signalling Protocols 1825 From Section 4.5.1 on SignallingProtocols syntax: 1827 Editor's Note: We should probably make each signalling proto- 1828 col into its own attribute because much of the related infor- 1829 mation is specific to one particular signalling protocol. For 1830 example, the UDP port numbers will likely be different if a 1831 single server supports both SIP & H323. 1833 8.8 Pricing 1835 From Section 4.6.1 on the syntax of the Pricing attribute: 1837 Editor's Note. We believe currency codes are already 1838 used/defined in other IETF documents (OTP?). We should use 1839 the same currency codes if possible. Registering new codes is 1840 only required if we have to define them. 1842 Editor's Note. We need to specify a floating point represen- 1843 tation. 1845 Editor's Note. We probably need to provide a time unit as 1846 well because different plans have different time units (ie the 1847 rate gets incremented every 6 seconds, every minute, etc). We 1848 should look at ITU SG16 Annex G for a good example. 1850 From Section 4.6.5 on disseminating the Pricing attribute. 1852 Editor's Note: Should we relax these rules a bit? Can an LS 1853 propagate the pricing attribute if it doesn't change the next 1854 hop? This would allow the LastModifiedBy attribute to contain 1855 a signature for the pricing attribute as well. 1857 Editor's Note. There a some possible methods for handling 1858 aggregation and route propagation of the Pricing attribute 1859 that might be worth investigation. The attribute itself 1860 might indicate its processing. For example, it could refer- 1861 ence a Java applet, or could be written in a well-known 1862 language like TCL or XML so that the data itself defines its 1863 properties. This possibility would definitely need more 1864 investigation. 1866 Editor's Note. It would seem beneficial if the Pricing attri- 1867 bute subtypes could be negotiatiated during peer session 1868 establishment, so that an LS uses a pricing language under- 1869 stood by its peer. 1871 8.9 Authentication via LastModifiedBy 1873 The following issue discusses the syntax of the LastModifiedBy attri- 1874 bute: 1876 Editor's Note. The intent of this attribute is to allow an LS 1877 to 'sign' certain attributes. Receivers must be able to ver- 1878 ify this signature, so some type of identification of the pro- 1879 vider must be provided. This might be an IPv4 address, an 1880 IPv6 address, a DNS name, etc. The LS-type above should 1881 define what kind of identifier is provided (IPv, IPv6, DNS, 1882 etc.), and the identifier should carry that value. 1884 8.10 Number of hops versus path 1886 The following note is in Section 4.8: 1888 Editor's Note. As an alternative to NumSignalingHops, a Sig- 1889 nalingPath attribute was considered. The SignalingPath attri- 1890 bute would be much like the AdvertisementPath, except it would 1891 only be updated when the next-hop changed. Thus, it would 1892 record the signaling path to the destination. It was not 1893 clear whether the SignalingPath attribute would be more useful 1894 than simply counting the number of hops, so for simplicity we 1895 went with the NumSignalingHops attribute. Would a Signaling- 1896 Path attribute be useful enough in policy to justify the added 1897 complexity? 1899 9 Conclusions 1901 This draft recommends a set of attributes for initial consideration 1902 for GLP. These attributes is independent of the transport and syn- 1903 chronization issues that also have to be decided. 1905 This attribute set is intended as the final set, but merely as the 1906 starting point for further discussions. The function and suggested 1907 implementation of each attribute should be reviewed by the IPTEL WG 1908 community. 1910 10 References 1912 [1] J. Rosenberg and H. Schulzrinne, "A Framework for a Gateway Loca- 1913 tion Protocol," Internet Draft, Internet Engineering Task Force, Work 1914 in Progress, June 1999. 1916 [2] D. Hampton, D. Oran, H. Salama, and D. Shah, "The IP Telephony 1917 Border Gateway Protocol Architecture," Internet Draft, Internet 1918 Engineering Task Force, February 1999. 1920 [3] M. Squire, "A Gateway Location Protocol," Internet Draft, Inter- 1921 net Engineering Task Force, Work in Progress, February 1999. 1923 [4] Y. Rekhter and T. Li, "A border gateway protocol 4 (BGP-4)," 1924 Request for Comments (Draft Standard) 1771, Internet Engineering Task 1925 Force, March 1995. 1927 [5] J. Moy, "OSPF Version 2," Request For Comments (Draft Standard) 1928 2328, Internet Engineering Task Force, April 1998. 1930 [6] J. Reynolds and J. Postel, "Assigned Numbers," Request For Com- 1931 ments (Draft Standard) 1700, Internet Engineering Task Force, October 1932 1994. 1934 Author's Address 1936 Jonathan Rosenberg 1937 Lucent Technologies, Bell Laboratories 1938 101 Crawfords Corner Rd. 1939 Holmdel, NJ 07733 1940 RM 4C-526 1941 email: jdrosen@bell-labs.com 1943 Hussein Salama 1944 Cisco Systems 1945 170 W. Tasman Drive 1946 San Jose, CA 95134 1947 hsalama@cisco.com 1949 Matt Squire 1950 Nortel Networks 1951 4309 Emporer Blvd 1952 Suite 200 1953 Durham, NC 27703 1954 msquire@nortelnetworks.com