idnits 2.17.1 draft-ietf-drinks-spprov-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (October 22, 2010) is 4935 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) == Outdated reference: A later version (-07) exists of draft-ietf-drinks-sppp-over-soap-00 == Outdated reference: A later version (-06) exists of draft-ietf-drinks-usecases-requirements-03 -- Obsolete informational reference (is this intentional?): RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DRINKS J-F. Mule 3 Internet-Draft CableLabs 4 Intended status: Standards Track K. Cartwright 5 Expires: April 25, 2011 TNS 6 S. Ali 7 NeuStar 8 A. Mayrhofer 9 enum.at GmbH 10 October 22, 2010 12 Session Peering Provisioning Protocol 13 draft-ietf-drinks-spprov-03 15 Abstract 17 This document defines a protocol for provisioning session 18 establishment data into Session Data Registries and SIP Service 19 Provider data stores. The provisioned data is typically used by 20 various network elements for session peering. 22 This document describes the Session Peering Provisioning Protocol 23 used by clients to provision registries. The document provides a set 24 of guiding principles for the design of this protocol including 25 extensibility and independent transport definitions, a basic data 26 model and an XML Schema Document. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2011. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Protocol High Level Design . . . . . . . . . . . . . . . . . . 9 65 3.1. Protocol Layering . . . . . . . . . . . . . . . . . . . . 9 66 3.2. Protocol Data Model . . . . . . . . . . . . . . . . . . . 10 67 4. Transport Protocol Requirements . . . . . . . . . . . . . . . 14 68 4.1. Connection Oriented . . . . . . . . . . . . . . . . . . . 15 69 4.2. Request and Response Model . . . . . . . . . . . . . . . . 15 70 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 15 71 4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 15 72 4.5. Confidentiality and Integrity . . . . . . . . . . . . . . 16 73 4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 16 74 4.7. Request and Response Sizes . . . . . . . . . . . . . . . . 16 75 4.8. Request and Response Correlation . . . . . . . . . . . . . 16 76 4.9. Request Acknowledgement . . . . . . . . . . . . . . . . . 16 77 4.10. Mandatory Transport . . . . . . . . . . . . . . . . . . . 17 78 5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 18 79 5.1. Request and Response Structures . . . . . . . . . . . . . 18 80 5.1.1. Update Request and Response Structures . . . . . . . . 18 81 5.1.2. Query Request and Response Structures . . . . . . . . 21 82 5.2. Response Codes and Messages . . . . . . . . . . . . . . . 23 83 5.3. Basic Object Type and Organization Identifiers . . . . . . 25 84 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 27 85 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 27 86 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 31 87 6.3. Add Destination Group Operation . . . . . . . . . . . . . 32 88 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 33 89 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 34 90 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 36 91 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 37 92 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 38 93 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 40 94 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 45 95 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 47 96 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 52 97 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 53 98 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 54 99 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 54 100 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 55 101 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 56 102 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 57 103 7.5. Add Public Identity -- Successful COR claim . . . . . . . 59 104 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 60 105 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 61 106 7.8. Add TN Range with Open Number Plan support . . . . . . . . 62 107 7.9. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 63 108 7.10. Enable Peering -- Route Group Offer . . . . . . . . . . . 64 109 7.11. Enable Peering -- Route Group Offer Accept . . . . . . . . 66 110 7.12. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 67 111 7.13. Get Destination Group . . . . . . . . . . . . . . . . . . 68 112 7.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 69 113 7.15. Get Route Group Request . . . . . . . . . . . . . . . . . 70 114 7.16. Get Route Group Offers Request . . . . . . . . . . . . . . 71 115 7.17. Get Egree Route . . . . . . . . . . . . . . . . . . . . . 72 116 7.18. Delete Destination Group . . . . . . . . . . . . . . . . . 74 117 7.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 74 118 7.20. Delete Route Group Request . . . . . . . . . . . . . . . . 75 119 7.21. Delete Route Group Offers Request . . . . . . . . . . . . 76 120 7.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 77 121 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 79 122 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 79 123 8.2. Versioning and Character Encoding . . . . . . . . . . . . 79 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 126 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 82 127 12. Specification Extensibility . . . . . . . . . . . . . . . . . 95 128 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 96 129 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 97 130 14.1. Normative References . . . . . . . . . . . . . . . . . . . 97 131 14.2. Informative References . . . . . . . . . . . . . . . . . . 97 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99 134 1. Introduction 136 Service providers and enterprises use registries to make call or 137 session routing decisions for Voice over IP, SMS and MMS traffic 138 exchanges. This document is narrowly focused on the provisioning 139 protocol for these registries. This protocol prescribes a way for an 140 entity to provision session-related data into a registry. The data 141 being provisioned can be optionally shared with other participating 142 peering entities. The requirements and use cases driving this 143 protocol have been documented in 144 [I-D.ietf-drinks-usecases-requirements]. The reader is expected to 145 be familiar with the terminology defined in the previously mentioned 146 document. 148 Three types of provisioning flows have been described in the use case 149 document: client to registry provisioning, registry to local data 150 repository and registry-to-registry. This document addresses a 151 subset (client-to-registry provisioning) by defining a Session 152 Peering Provisioning Protocol (SPPP) for provisioning Session 153 Establishment Data (SED) into a Registry (arrow "1" in the figure 154 below). While the other "provisioning flows" are shown below as 155 separate message flows, no determination has been made for whether 156 one common baseline protocol could be used for all three, or whether 157 distinct protocols are required. 159 *------------* *------------* 160 (1). Provisioning SED | | (3).Registry | | 161 -----------------------> | Registry |<------------->| Registry | 162 data into Registries| | to Registry | | 163 *------------* exchanges *------------* 164 / \ \ 165 / \ \ 166 / \ \ 167 / \ v 168 / \ ... 169 / \ 170 / (2). \ 171 / Distributing \ 172 / SED \ 173 V V 174 +----------+ +----------+ 175 |Local Data| |Local Data| 176 |Repository| |Repository| 177 +----------+ +----------+ 179 Three Registry Provisioning Flows 181 Figure 1 183 The data provisioned for session establishment is typically used by 184 various downstream SIP signaling systems to route a call to the next 185 hop associated with the called domain. These systems typically use a 186 local data store ("Local Data Repository") as their source of session 187 routing information. More specifically, the SED data is the set of 188 parameters that the outgoing signaling path border elements (SBEs) 189 need to initiate the session. See [RFC5486] for more details. 191 A "terminating" SIP Service Provider (SSP) provisions SED into the 192 registry to be selectively shared with other peer SSPs. 193 Subsequently, a Registry may distribute the provisioned data into 194 local Data Repositories used for look-up queries (identifier -> URI) 195 or for lookup and location resolution (identifier -> URI -> ingress 196 SBE of terminating SSP). In some cases, the Registry may 197 additionally offer a central query resolution service (not shown in 198 the above figure). 200 A key requirement for the SPPP protocol is to be able to accommodate 201 two basic deployment scenarios: 203 1. A Local Data Repository serves a Look-Up Function (LUF) to 204 determine the target domain to assist in call routing (as 205 described in [RFC5486]). In this case, the querying entity may 206 use other means to perform the Location Routing Function (LRF) 207 which in turn helps determine the actual location of the 208 Signaling Function in that domain. 210 2. A Local Data Repository serves both a Look-Up function (LUF) and 211 Location Routing Function (LRF) to locate the SED data fully. 213 In terms of protocol design, SPPP protocol is agnostic to the 214 transport. This document includes the description of the data model 215 and the means to enable protocol operations within a request and 216 response structure. To encourage interoperability, the protocol 217 supports extensibility aspects. 219 Transport requirements are provided in this document to help with the 220 selection of the optimum transport mechanism. 221 ([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport 222 mechanism for SPPP. 224 This document is organized as follows: 226 o Section 2 provides the terminology; 228 o Section 3 provides an overview of the SPPP protocol, including 229 the layering approach, functional entities and data model; 231 o Section 4 specifies requirements for SPPP transport protocols; 233 o Section 5 describes the base protocol data structures including 234 the request and response elements (Section 5.1), the response 235 codes and messages (Section 5.2) and the basic object type most 236 first class objects extend from; 238 o Section 6 and Section 7 describe the main protocol commands and 239 examples; 241 o Section 8 defines XML considerations that XML parsers must meet 242 to conform to this specification; 244 o Section 11 normatively defines the SPPP protocol using its XML 245 Schema Definition. 247 2. Terminology 249 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 250 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 251 document are to be interpreted as described in [RFC2119]. 253 This document reuses terms from [RFC3261], [RFC5486], use cases and 254 requirements documented in [I-D.ietf-drinks-usecases-requirements] 255 and the ENUM Validation Architecture [RFC4725]. 257 In addition, this document specifies the following additional terms: 259 SPPP: Session Peering Provisioning Protocol, the protocol used to 260 provision data into a Registry (see arrow labeled "1." in Figure 1 261 of [I-D.ietf-drinks-usecases-requirements]). It is the primary 262 scope of this document. 264 SPDP: Session Peering Distribution Protocol, the protocol used to 265 distribute data to Local Data Repository (see arrow labeled "2." 266 in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). 268 Client: An application that supports an SPPP Client; it is 269 sometimes referred to as a "Registry Client". 271 Registry: The Registry operates a master database of Session 272 Establishment Data for one or more Registrants. 274 A Registry acts as an SPPP Server. 276 Registrant: In this document, we extend the definition of a 277 Registrant based on [RFC4725]. The Registrant is the end-user, 278 the person or organization who is the "holder" of the Session 279 Establishment Data being provisioned into the Registry. For 280 example, in [I-D.ietf-drinks-usecases-requirements], a Registrant 281 is pictured as a SIP Service Provider in Figure 2. 283 A Registrant is identified by its name and an identifier in the 284 data model. 286 Registrar: In this document, we also extend the definition of a 287 Registrar from [RFC4725]. A Registrar performs provisioning 288 operations on behalf of a Registrant by interacting with the 289 Registry, in our case via the SPPP protocol defined in this 290 document. 292 A Registrar is identified by its name and an identifier in the 293 data model. 295 3. Protocol High Level Design 297 This section introduces the structure of the data model and provides 298 the information framework for the SPPP protocol. An overview of the 299 protocol operations is first provided with a typical deployment 300 scenario. The data model is then defined along with all the objects 301 manipulated by the protocol and their relationships. 303 3.1. Protocol Layering 305 SPPP is a simple request/reply protocol that allows a client 306 application to submit provisioning data and query requests to a 307 server. The SPPP data structures are designed to be protocol 308 agnostic. Concerns regarding encryption, non-repudiation, and 309 authentication are beyond the scope of this document. For more 310 details, please refer to the Transport Protocol Requirements section. 312 Layer Example 313 +-------------+ +-----------------------------+ 314 (5) |Data Objects | | RteGrpType, etc. | 315 +-------------+ +-----------------------------+ 316 | | 317 +-------------+ +-----------------------------+ 318 (4) | Operations | | AddRteGrpRqstType, etc. | 319 +-------------+ +-----------------------------+ 320 | | 321 +-------------+ +-----------------------------+ 322 (3) | Message | | spppUpdateRequest, | 323 | | | spppUpdateResponse, | 324 | | | spppQueryRequest, | 325 | | | spppQueryResponse | 326 +-------------+ +-----------------------------+ 327 | | 328 +-------------+ +-----------------------------+ 329 (2) | Message | | HTTP, SOAP, None, etc. | 330 | Envelope | | | 331 +-------------+ +-----------------------------+ 332 | | 333 +-------------+ +-----------------------------+ 334 (1) | Transport | | TCP, TLS, BEEP, etc. | 335 | Protocol | | | 336 +-------------+ +-----------------------------+ 338 SPPP Layering 340 Figure 2 342 SPPP can be viewed as a set of layers that collectively define the 343 structure of an SPPP request and response. Layers 1 and 2, as 344 detailed below, are left to separate specifications to allow for 345 potentially multiple SPPP transport, envelope, and authentication 346 technologies. This document defines layers 3, 4, and 5 below. 348 1. The transport protocol layer provides a communication mechanism 349 between the client and server. SPPP can be layered over any 350 transport protocol that provides a set of basic requirements 351 defined in the Transport Protocol Requirements section. 353 2. The message envelope layer is optional, but can provide features 354 that are above the transport technology layer but below the 355 application messaging layer. Technologies such as HTTP and SOAP 356 are examples of messaging envelope technologies. 358 3. The message layer provides a simple, envelope-independent and 359 transport-independent, SPPP wrapper for SPPP request and response 360 messages. 362 4. The operation layer defines the set of base SPPP actions that can 363 be invoked for a given object data type using an SPPP message. 364 Operations are encoded using XML encoded actions and objects. 366 5. The data object layer defines the base set of SPPP data objects 367 that can be included in update operations or returned in 368 operation responses. 370 3.2. Protocol Data Model 372 The data model illustrated and described in Figure 3 defines the 373 logical objects and the relationships between these objects that the 374 SPPP protocol supports. SPPP defines the protocol operations through 375 which an SPPP Client populates a Registry with these logical objects. 376 Various clients belonging to different Registrars may use the 377 protocol for populating the Registry's data. 379 The logical structure presented below is consistent with the 380 terminology and requirements defined in 381 [I-D.ietf-drinks-usecases-requirements]. 383 +-------------+ +------------------+ 384 | all object | |Organization: | 385 | types | |orgId, | 386 +------+------+ |orgName, | 387 +------------>|extension | 388 | | 390 All objects are | | 391 associated with 2 | | 392 Organizations to +------------------+ 393 identify the ^ 394 registrant and |A Route Group is 395 the registrar |associated with 396 |zero or more Peering 397 |Organizations 398 | 399 +--------+--------------+ 400 |Route Group: | +-----[abstract]-+ 401 | rantId, | | Route Record: | 402 | rarId, | | | 403 | rteGrpName, | | rrName, | 404 | destGrpRef, +------->| priority, | 405 | isInSvc, | | extension | 406 | rteRecRef, | | | 407 | peeringOrg, | +----------------+ 408 | sourceIdent, | ^ 409 | priority, | | 410 | extension | |Various types 411 +-----------------------+ |of Route 412 ^ |Records... 413 | +------+------------... 414 | | | | 415 | +----+ +-------+ +----+ 416 | | URI| | NAPTR | | NS | 417 +----------------+-----+ +----+ +-------+ +----+ 418 |Destination | 419 |Group: | +----------[abstract]-+ 420 | rantId, | |Public Identifier: | 421 | rarId, | | | 422 | dgName, | | rantId, | 423 | extension |<----+ rarId, | 424 +----------------------+ | publicIdentifier, | 425 | destGrpRef, | 426 | rteRec, | 427 | extension | 428 +---------------------+ 429 ^ 430 |Various types 431 |of Public 432 |Identifiers... 433 +---------+-------+------------... 434 | | | | 435 +------+ +-----+ +-----+ +-----+ 436 | TN | | TNP | | TNR | | RN | 437 +------+ +-----+ +-----+ +-----+ 438 SPPP Data Model 440 Figure 3 442 The objects and attributes that comprise the data model can be 443 described as follows (objects listed from the bottom up): 445 o Public Identifier: 446 A public identifier is a well known attribute that is used as the 447 key to perform lookup functions. For the purposes of this 448 document, a Public Identifier can be a telephone number, a range 449 of telephone numbers, a PSTN Routing Number (RN), or perhaps 450 another type of lookup key. 452 A Public Identifier is associated with a Destination Group to 453 create a logical grouping of Public Identifiers that share a 454 common set of Routes. 456 A TN Public Identifier may optionally be associated with zero or 457 more individual Route Records. This ability for a Public 458 Identifier to be directly associated with a set of Route Records 459 (e.g. target URI), as opposed to being associated with a 460 Destination Group, supports the use cases where the target URI 461 contains data specifically tailored to an individual TN Public 462 Identifier. 464 o Telephone Number Range: 465 A public identifier may represent an inclusive range of telephone 466 numbers. The TN range is defined by the first and last telephone 467 number of the inclusive range. For example, a TN range defined by 468 tn=12125550000 and endTn=12125560000 means all the TNs from 469 12125550000 to 12125560000 inclusive are included. 471 o Destination Group: 472 A name collection of zero or more Public Identifiers that can be 473 associated with one or more Route Groups for the purpose of 474 facilitating the management of thier common routing information. 476 o Route Group: 477 A Route Group contains a set of references to Route Records, a set 478 of Destination Group references, and a set of peering organization 479 identifiers. This is used to establishe a three part 480 relationships between a set of Public Identifiers and their common 481 routing information (SED), and the list of peering organizations 482 whose query responses may include that routing information in 483 their query responses. To support the use cases defined in 484 [I-D.ietf-drinks-usecases-requirements], this document defines the 485 following types of Route Records: NAPTRType, NSType, and URIType. 487 The sourceIdent element within a Route Group, in concert with the 488 set of peering organization identifiers enables fine grained 489 source based routing. Further details about the Route Group and 490 source based routing refer to the definitions and descriptions of 491 the Route Group operations found later in this document. 493 o Route Record: 494 A Route Record contains the data that a resolution system returns 495 in response to a successful query for a Public Identifier. Route 496 Recoords are associated with a Route Group for SED that is not 497 specific to a Public Identifier. 498 To support the use cases defined in 499 [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines 500 three type of Route Records: URIType, NAPTRType, and NSType. 501 These Route Records extend the abstract type RteRecType and 502 inherit the common attribute 'priority' that is meant for setting 503 precedence across the route records defined within a Route Group 504 in a protocol agnostic fashion. 506 o Organization: 507 An Organization is an entity that may fulfill any combination of 508 three roles: Registrant, Registrar, and Peering Organization. All 509 SPPP objects are associated with two organization identifiers to 510 identify each object's registrant and the registrar. A Route 511 Group object is also associated with a set of zero or more 512 organization identifiers that identify the peering organizations 513 whose query responses may include the routing information (SED) 514 defined in the Route Records within that Route Group. 516 4. Transport Protocol Requirements 518 This section provides requirements for transport protocols suitable 519 for SPPP. More specifically, this section specifies the services, 520 features, and assumptions that SPPP delegates to the chosen transport 521 and envelope technologies. 523 Two different groups of use cases are specified in 524 [I-D.ietf-drinks-usecases-requirements]. One group of use cases 525 describes the provisioning of data by a client into a Registry 526 (Section 3.1 of the above referenced document), while the other group 527 describes the distribution of data into local data repositories 528 (Section 3.2). The current version of this document focuses on the 529 first set of use cases (client to registry provisioning). 531 These use cases may involve the provisioning of very small data sets 532 like the modification or update of a single public identifier. Other 533 provisioning operations may deal with huge datasets like the 534 "download" of a whole local number portability database to a 535 Registry. 537 As a result, a transport protocol for SPPP must be very flexible and 538 accommodate various sizes of data set sizes. 540 For the reasons outlined above, it is conceivable that provisioning 541 and distributing may use different transport protocols. This 542 document focuses on the provisioning protocol. 544 A few topics remain open for discussion: 546 o The ability to establish multiple connections between a client and 547 server may be desirable. If so, we may want to specify the 548 relation of transactions between the various connections. 550 o Pipelining of requests is required at the SPPP protocol layer. It 551 may have impacts at the transport level that need to be outlined. 553 o Scope: the current scope of this effort is based upon having a 554 connection oriented transport. Is there any need to support a 555 transport protocol with asynchronous operation? 557 o If it is required that responses arrive in the order of the 558 requests, this must be specified clearly. 560 4.1. Connection Oriented 562 The SPPP protocol follows a model where a Client establishes a 563 connection to a Server in order to further exchange provisioning 564 transactions over such point-to-point connection. A transport 565 protocol for SPPP MUST therefore be connection oriented. 567 Note that the role of the "Client" and the "Server" only applies to 568 the connection, and those roles are not related in any way to the 569 type of entity that participates in a protocol exchange. For 570 example, a Registry might also include a "Client" when such a 571 Registry initiates a connection (for example, for data distribution 572 to SSP). 574 4.2. Request and Response Model 576 Provisioning operations in SPPP follow the request - response model, 577 where a transaction is initiated by a Client using a Request command, 578 and the Server responds to the Client by means of a Response. 580 Multiple subsequent request-response exchanges MAY be performed over 581 a single connection. 583 Therefore, a transport protocol for SPPP MUST follow the request- 584 response model by allowing a response to be sent to the request 585 initiator. 587 4.3. Connection Lifetime 589 Some use cases involve provisioning a single request to a network 590 element - connections supporting such provisioning requests might be 591 short-lived, and only established on demand. 593 Other use cases involve either provisioning a huge set of data, or a 594 constant stream of small updates, which would require long-lived 595 connections. 597 Therefore, a protocol suitable for SPPP SHOULD support short lived as 598 well as long lived connections. 600 4.4. Authentication 602 Many use cases require the Server to authenticate the Client, and 603 potentially also the Client to authenticate the Server. While 604 authentication of the Server by the Client is expected to be used 605 only to prevent impersonation of the Server, authentication of the 606 Client by the Server is expected to be used to identify and further 607 authorize the Client to certain resources on the Server. 609 Therefore, an SPPP transport protocol MUST provide means for a Server 610 to authenticate and authorize a Client, and MAY provide means for 611 Clients to authenticate a Server. 613 However, SPPP transport SHOULD also allow for unauthenticated 614 connections. 616 4.5. Confidentiality and Integrity 618 Data that is transported over the protocol is deemed confidential. 619 Therefore, a transport protocol suitable for SPPP MUST ensure 620 confidentiality and integrity protection by providing encryption 621 capabilities. 623 Additionally, a DRINKS protocol MUST NOT use an unreliable lower- 624 layer transport protocol that does not provide confidentiality and 625 integrity protection. 627 4.6. Near Real Time 629 Many use cases require near real-time responses from the Server. 630 Therefore, a DRINKS transport protocol MUST support near-real-time 631 response to requests submitted by the Client. 633 4.7. Request and Response Sizes 635 SPPP covers a range of use cases - from cases where provisioning a 636 single public identifier will create very small request and response 637 sizes to cases where millions of data records are submitted or 638 retrieved in one transaction. Therefore, a transport protocol 639 suitable for SPPP MUST support a great variety of request and 640 response sizes. 642 A transport protocol MAY allow splitting large chunks of data into 643 several smaller chunks. 645 4.8. Request and Response Correlation 647 A transport protocol suitable for SPPP MUST allow responses to be 648 correlated with requests. 650 4.9. Request Acknowledgement 652 Data transported in the SPPP protocol is likely crucial for the 653 operation of the communication network that is being provisioned. 655 Failed transactions can lead to situations where a subset of public 656 identifiers (or even SSPs) might not be reachable, or situations 657 where the provisioning state of the network is inconsistent. 659 Therefore, a transport protocol for SPPP MUST provide a Response for 660 each Request, so that a Client can identify whether a Request 661 succeeded or failed. 663 4.10. Mandatory Transport 665 As of this writing of this revision, one transport protocol proposal 666 has been provided in [I-D.ietf-drinks-sppp-over-soap]. 668 This section will define a mandatory transport protocol to be 669 compliant with this RFC. 671 5. Base Protocol Data Structures 673 SPPP uses a common model and a common set of data structures for most 674 of the supported operations and object types. This section describes 675 these common data structures. 677 5.1. Request and Response Structures 679 An SPPP client interacts with an SPPP server by using one of the 680 supported transport mechanisms to send one or more requests to the 681 server and receive corresponding replies from the server. There are 682 two generalized types of operations that an SPPP client can submit to 683 an SPPP server, updates and queries. The following two sub-sections 684 describe the generalized data structures that are used for each of 685 these two types of operations. 687 5.1.1. Update Request and Response Structures 689 An SPPP update request is wrapped within the 690 element while an SPPP update response is wrapped within an 691 element. The following two sub-sections 692 describe these two elements. 694 5.1.1.1. Update Request 696 An SPPP update request object is contained within the generic 697 element. 699 700 701 702 704 706 708 709 710 712 713 714 715 716 717 719 The data elements within the element are 720 described as follows: 722 o clientTransId: Zero or one client generated transaction ID that, 723 within the context of the SPPP client, identifies this request. 724 This value can be used at the discretion of the SPPP client to 725 track, log or correlate requests and their responses. This 726 value is also echoed back to the client in the SPPP update 727 response. An SPPP server will not check this value for 728 uniqueness. 730 o minorVer: Zero or one minor version identifier, indicating the 731 minor version of the SPPP API that the client is attempting to 732 use. This is used in conjunction with the major version 733 identifier in the XML namespace to identify the version of SPPP 734 that the client is using. If the element is not present, the 735 server assumes that the client is using the latest minor version 736 supported by the SPPP server for the given major version. The 737 versions supported by a given SPPP server can be retrieved by 738 the client using the SPPP server menu operation described later 739 in the document. 741 o rqst: One or more BasicRqstType objects. These are the actions 742 that the client is requesting the SPPP server perform. They are 743 processed by the SPPP server in the order in which they are 744 included in the request. And with respect to handling error 745 conditions, it is a matter of policy whether the objects are 746 processed in a "stop and rollback" fashion or in a "stop and 747 commit" fashion. In the "stop and rollback" scenario, the SPPP 748 server would stop processing BasicRqstType object instances in 749 the request at the first error and roll back any BasicRqstType 750 object instances that had already been processed for that update 751 request. In the "stop and commit" scenario the SPPP server 752 would stop processing BasicRqstType object instances in the 753 request at the first error but commit any BasicRqstType object 754 instances that had already been processed for that update 755 request. 757 All update request objects extend the base type BasicRqstType. This 758 base type is defined as follows: 760 761 762 763 764 766 The BasicRqstType object primarily acts as an abstract base type, and 767 its only data element is described as follows: 769 o ext: This is the standard extension element for this object. 770 Refer to the Extensibility section of this document for more 771 details. 773 5.1.1.2. Update Response 775 An SPPP update response object is contained within the generic 776 element. 778 779 780 781 782 784 786 787 788 789 791 792 793 794 795 796 798 799 800 801 802 803 804 806 807 809 An contains the elements necessary for the SPPP 810 client to precisely determine the overal result of the request, and 811 if an error occurred, it provides information about the specific 812 object, data element, or condition caused the error. 814 The data elements within the SPPP update response are described as 815 follows: 817 o clientTransId: Zero or one client transaction ID. This value is 818 simply an echo of the client transaction ID that SPPP client 819 passed into the SPPP update request. 821 o serverTransId: Exactly one server transaction ID that identifies 822 this request for tracking purposes. This value is guaranteed to 823 be unique for a given SPPP server. 825 o overallResult: Exactly one response code and message pair that 826 explicitly identifies the result of the request. See the 827 Response Code section for further details. 829 o rqstObjResult: An optional response code, response message, and 830 BasicRqstObject triplet. This element will be present only if 831 an object level error condition occurs, and indicates exactly 832 which error condition occurred and exactly which request object 833 that was passed in caused the error condition. The contained 834 BasicRqstObject is simply an echo of the request object instance 835 that caused the error, while the response code and message 836 indicate the error condition for this object. See the Response 837 Code section for further details. 839 o ext: This is the standard extension element for this object. 840 Refer to the Extensibility section for more details. 842 5.1.2. Query Request and Response Structures 844 An SPPP query request is wrapped within the 845 element while an SPPP query response is wrapped within an 846 element. The following two sub-sections describe 847 these two element structures. 849 5.1.2.1. Query Request 851 An SPPP query request object is contained within the generic 852 element. 854 855 856 857 859 860 861 862 864 The data elements within the element are described 865 as follows: 867 o minorVer: Zero or one minor version identifier, indicating the 868 minor version of the SPPP API that the client is attempting to 869 use. This is used in conjunction with the major version 870 identifier in the XML namespace to identify the version of SPPP 871 that the client is using. If the element is not present, the 872 server assumes that the client is using the latest minor version 873 supported by the SPPP server for the given major version. The 874 versions supported by a given SPPP server can be retrieved by 875 the client using the SPPP server menu operation described later 876 in the document. 878 o rqst: One BasicQueryRqstType objects. This is the query that 879 the client is requesting the SPPP server perform. 881 All query request objects extend the base type BasicQueryRqstType. 882 This base type is defined as follows: 884 885 886 887 888 890 The BasicQueryRqstType object primarily acts as an abstract base 891 type, and its only data element is described as follows: 893 o ext: This is the standard extension element for this object. 894 Refer to the Extensibility section of this document for more 895 details. 897 5.1.2.2. Query Response 899 An SPPP query response object is contained within the generic 900 element. 902 903 904 905 906 908 909 910 912 An contains the elements necessary for the SPPP 913 client to precisely determine the overal result of the query, and if 914 an error occurred, exactly what condition caused the error. 916 The data elements within the SPPP query response are described as 917 follows: 919 o overallResult: Exactly one response code and message pair that 920 explicitly identifies the result of the request. See the 921 Response Code section for further details. 923 o resultSet: The set of zero or more objects that matched the 924 query criteria. If no objects matched the query criteria then 925 this result set MUST be empty and the overallResult value MUST 926 indicate success (if no matches are found for the query 927 criteria, the response is considered a success). 929 5.2. Response Codes and Messages 931 This section contains the listing of response codes and their 932 corresponding human-readable text. 934 The response code numbering scheme generally adheres to the theory 935 formalized in section 4.2.1 of [RFC5321]: 937 o The first digit of the response code can only be 1 or 2: 1 = a 938 positive result, 2 = a negative result. 940 o The second digit of the response code indicates the category: 0 941 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 942 = Security, 3 = Server System. 944 o The third and fourth digits of the response code indicate the 945 individual message event within the category defines by the 946 first two digits. 948 The response codes are also categorized as to whether they are 949 overall response codes that may only be returned in the 950 "overallResult" data element in SPPP responses, of object level 951 response codes that may only be returned in the "rqstObjResult" 952 element of the SPPP responses. 954 +--------+--------------------------+-------------------------------+ 955 | Result | Text | Overall or Object Level | 956 | Code | | | 957 +--------+--------------------------+-------------------------------+ 958 | 1000 | Request Succeeded. | Overall Response Code | 959 | | | | 960 | 2001 | Request syntax invalid. | Overall Response Code | 961 | | | | 962 | 2002 | Request too large. | Overall Response Code | 963 | | | | 964 | 2003 | Version not supported. | Overall Response Code | 965 | | | | 966 | 2103 | Command invalid. | Overall Response Code | 967 | | | | 968 | 2301 | System temporarily | Overall Response Code | 969 | | unavailable. | | 970 | | | | 971 | 2302 | Unexpected internal | Overall Response Code | 972 | | system or server error. | | 973 | | | | 974 | 2104 | Attribute value invalid. | Object Level Response Code | 975 | | | | 976 | | AttrName:[AttributeName] | | 977 | | AttrVal:[AttributeValue] | | 978 | | | | 979 | 2105 | Object does not exist. | Object Level Response Code | 980 | | AttrName:[AttributeName] | | 981 | | AttrVal:[AttributeValue] | | 982 | | | | 983 | 2106 | Object status or | Object Level Response Code | 984 | | ownership does not allow | | 985 | | for operation. | | 986 | | AttrName:[AttributeName] | | 987 | | AttrVal:[AttributeValue] | | 988 +--------+--------------------------+-------------------------------+ 990 Table 1: Response Codes Numbering Scheme and Messages 992 Each of the object level response messages are "parameterized" with 993 the following parameters: "AttributeName" and "AttributeValue". 995 The use of these parameters MUST adhere to the following rules: 997 o All parameters within a response message are mandatory and MUST 998 be present. 1000 o Any value provided for the "AttributeName" parameter MUST be an 1001 exact XSD element name of the protocol data element that the 1002 response message is referring to. For example, valid values for 1003 "attribute name" are "dgName", "rteGrpName", "rteRec", etc. 1005 o The value for "AttributeValue" MUST be the value of the data 1006 element to which the preceding "AttributeName" refers. 1008 o Result code 2104 SHOULD be used whenever an element value does 1009 not adhere to data validation rules. 1011 o Result codes 2104 and 2105 MUST NOT be used interchangeably. 1012 Response code 2105 SHOULD be returned by an update operation 1013 when the data element(s) used to uniquely identify a pre- 1014 existing object do not exist. If the data elements used to 1015 uniquely identify an object are malformed, then response code 1016 2104 SHOULD be returned. 1018 5.3. Basic Object Type and Organization Identifiers 1020 This section introduces the basic object type that most first class 1021 objects derive from. 1023 All first class objects extend the basic object type BasicObjType 1024 which contains the identifier of the registrant organization that 1025 owns this object, the identifier of the registrar organization that 1026 provisioned this object, the date and time that the object was 1027 created by the server, and the date and time that the object was last 1028 modified. 1030 1031 1032 1033 1034 1035 1036 1037 1038 1040 The identifiers used for registrants (rantId), registrars (rarId) and 1041 peering organizations (peeringOrg) are instances of OrgIdType. The 1042 OrgIdType is defined as a string and all OrgIdType instances SHOULD 1043 follow the textual convention: "namespace:value" (for example "iana- 1044 en:32473"). See the IANA Consideration section for more details. 1046 6. Protocol Commands 1048 This section provides a description of each supported protocol 1049 command. 1051 6.1. Add Route Group Operation 1053 As described in the introductory sections, a Route Group represents a 1054 combined grouping of Route Records that define route information, 1055 Destination Groups that contain a set of Public Identifiers with 1056 common routing information, and the list of peer organizations that 1057 have access to these public identifiers using this route information. 1058 It is this indirect linking of public identifiers to their route 1059 information that significantly improves the scalability and 1060 manageability of the peering data. Additions and changes to routing 1061 information are reduced to a single operation on a Route Group or 1062 Route Record , rather than millions of data updates to individual 1063 public identifier records that individually contain their peering 1064 data. 1066 The AddRteGrpRqstType operation creates or overwrites a Route Group 1067 object. If a Route Group with the given name and registrant ID 1068 (which together comprise the unique key or a Route Group) does not 1069 exist, then the server MUST create the Route Group. If a Route Group 1070 with the given name and registrant ID does exist, then the server 1071 MUST replace the current properties of the Route Group with the 1072 properties passed into the AddRteGrpRqstType operation. The XSD 1073 declarations of the AddRteGrpRqstType operation request object are as 1074 follows: 1076 1077 1078 1079 1080 1081 1082 1083 1084 1086 The element passed into the spppUpdateRequest element for this 1087 operation is an instance of AddRteGrpRqstType, which extends 1088 BasicRqstType and contains one RteGrpType object. The RteGrpType 1089 object structure is defined as follows: 1091 1092 1093 1094 1095 1096 1098 1100 1102 1104 1105 1106 1107 1108 1109 1110 1112 1113 1114 1115 1116 1117 1118 1120 The RteGrpType object is composed of the following elements: 1122 o base: All first class objects extend BasicObjType which contains 1123 the ID of the registrant organization that owns this object, the 1124 ID of the registrar organization that provisioned this object, 1125 the date and time that the object was created by the server, and 1126 the date and time that the object was last modified. If the 1127 client passes in either the created date or the modification 1128 date, the server will ignore them. The server sets these two 1129 date/time values. 1131 o rteGrpName: The character string that contains the name of the 1132 Route Group. It uniquely identifies this object within the 1133 context of the registrant ID (a child element of the base 1134 element as described above). 1136 o rteRecRef: Set of zero or more objects of type RteRecRefType 1137 that house the unique keys of the Route Records that the the 1138 RteGrpType object refers to and their relative priority within 1139 the context of a given route group. The associated Route 1140 Records contain the routing information, sometimes called SED, 1141 associated with this Roue Group. 1143 o dgName: Set of zero or more names of DestGrpType object 1144 instances. Each dgName name, in association with this Route 1145 Group's registrant ID, uniquely identifies a DestGrpType object 1146 instance whose public identifiers are reachable using the 1147 routing information housed in this Route Group. An intended 1148 side affect of this is that a Route Group cannot provide routing 1149 information for a Destination Group belonging to another 1150 registrant. 1152 o peeringOrg: Set of zero or more peering organization IDs that 1153 have accepted an offer to receive this Route Group's 1154 information. The set of peering organizations in this list is 1155 not directly settable or modifiable using the addRteGrpsRqst 1156 operation. This set is instead controlled using the route offer 1157 and accept operations. 1159 o sourceIdent: Set of zero or more SourceIdentType object 1160 instances. These objects, described further below, house the 1161 source identification schemes and identifiers that are applied 1162 at resolution time as part of source based routing algorithms 1163 for the Route Group. 1165 o isInSvc: A boolean element that defines whether this Route Group 1166 is in service. The routing information contained in a Route 1167 Group that is in service is a candidate for inclusion in 1168 resolution responses for public identities residing in the 1169 Destination Group associated with this Route Group. The routing 1170 information contained in a Route Group that is not in service is 1171 not a candidate for inclusion in resolution responses. 1173 o priority: Zero or one priority value that can be used to provide 1174 a relative value weighting of one Route Group over another. The 1175 manner in which this value is used, perhaps in conjunction with 1176 other factors, is a matter of policy. 1178 o ext: Point of extensibility described in a previous section of 1179 this document. 1181 As described above, the Route Group contains a set of references to 1182 route record objects. A route record object is based on an abstract 1183 type: RteRecType. The concrete types that use RteRecType as an 1184 extension base are NAPTRType, NSType, and URIType. The definitions 1185 of these types are included the Route Record section of this 1186 document. 1188 The RteGrpType object provides support for source-based routing via 1189 the peeringOrg data element and more granular source base routing via 1190 the source identity element. The source identity element provides 1191 the ability to specify zero or more of the following in association 1192 with a given Route Group: a regular expression that is matched 1193 against the resolution client IP address, a regular expression that 1194 is matched against the root domain name(s), and/or a regular 1195 expression that is matched against the calling party URI(s). The 1196 result will be that, after identifying the visible Route Groups whose 1197 associated Destination Group(s) contain the lookup key being queried 1198 and whose peeringOrg list contains the querying organizations 1199 organization ID, the resolution server will evaluate the 1200 characteristics of the Source URI, and Source IP address, and root 1201 domain of the lookup key being queried. The resolution server then 1202 compares these criteria against the source identity criteria 1203 associated with the Route Groups. The routing information contained 1204 in Route Groups that have source based routing criteria will only be 1205 included in the resolution response if one or more of the criteria 1206 matches the source criteria from the resolution request. The Source 1207 Identity data element is of type SourceIdentType, whose structure is 1208 defined as follows: 1210 1211 1212 1213 1215 1216 1217 1219 1220 1221 1222 1223 1224 1225 1227 The SourceIdentType object is composed of the following data 1228 elements: 1230 o sourceIdentScheme: The source identification scheme that this 1231 source identification criteria applies to and that the 1232 associated sourceIdentRegex should be matched against. 1234 o sourceIdentRegex: The regular expression that should be used to 1235 test for a match against the portion of the resolution request 1236 that is dictated by the associated sourceIdentScheme. 1238 o ext: Point of extensibility described in a previous section of 1239 this document. 1241 As with the responses to all update operations, the result of the 1242 AddRteGrpRqstType operation is contained in the generic 1243 spppUpdateResponse data structure described in an earlier sections of 1244 this document. For a detailed description of the spppUpdateResponse 1245 data structure refer to that section of the document. 1247 6.2. Get Route Groups Operation 1249 The getRteGrpsRqst operation allows a client to get the properties of 1250 Route Group objects that a registrar organization is authorized to 1251 view. The server will attempt to find a Route Group object that has 1252 the registrant ID and route group name pair contained in each 1253 ObjKeyType object instance. If the set of ObjKeyType objects is 1254 empty then the server will return the list of Route Group objects 1255 that the querying client has the authority to view. If there are no 1256 matching Route Groups found then an empty result set will be 1257 returned. 1259 The element passed into the spppQueryRequest element for this 1260 operation is an instance of type GetRteGrpsRqstType, which extends 1261 BasicRqstType and contains zero or more ObjKeyType objects. Any 1262 limitation on the maximum number of objects that may be passed into 1263 or returned by this operation is a policy decision and not limited by 1264 the protocol. The XSD declaration of the operation is as follows: 1266 1267 1268 1269 1270 1272 1273 1274 1275 1277 As described in an earlier section of this document, the result of 1278 any spppQueryRequest operation is an spppQueryResponse element that 1279 contains the overall response code and the query result set, if any. 1280 Refer to that section of the document for a detailed description of 1281 the spppQueryResponse element. 1283 6.3. Add Destination Group Operation 1285 As described in the introductory sections, a Destination Group 1286 represents a set of Public Identifiers with common routing 1287 information. 1289 The AddDestGrpRqstType operation creates or overwrites a Destination 1290 Group object. If a Destination Group with the given name and 1291 registrant ID (which together comprise the unique key for a 1292 Destination Group) does not exist, then the server MUST create the 1293 Destination Group. If a Destination Group with the given name and 1294 registrant ID does exist, then the server MUST replace the current 1295 properties of the Destination Group with the properties passed into 1296 the AddDestGrpsRqstType operation. The XSD declarations of the 1297 operation request object are as follows: 1299 1300 1301 1302 1303 1304 1305 1306 1307 1309 The element passed into the spppUpdateRequest element for this 1310 operation is an element of type AddDestGrpRqsttype, which extends 1311 BasicRqstType and contains a DestGrpType object. The DestGrpType 1312 object structure is defined as follows: 1314 1315 1316 1317 1318 1319 1320 1321 1322 1324 The DestGrpType object is composed of the following elements: 1326 o base: All first class objects extend BasicObjType which contains 1327 the ID of the registrant organization that owns this object, the 1328 ID of the registrar organization that provisioned this object, 1329 the date and time that the object was created by the server, and 1330 the date and time that the object was last modified. If the 1331 client passed in either the created date or the modification 1332 date, the server will ignore them. The server sets these two 1333 date/time values. 1335 o dgName: The character string that contains the name of the 1336 Destination Group. This uniquely identifies this object within 1337 the context of the registrant ID (a child element of the base 1338 element as described above). 1340 o ext: Point of extensibility described in a previous section of 1341 this document. 1343 As with the responses to all update operations, the result of the 1344 AddDestGrpRqstType operation is contained in the generic 1345 spppUpdateResponse data structure described in an earlier sections of 1346 this document. For a detailed description of the spppUpdateResponse 1347 data structure refer to that section of the document. 1349 6.4. Get Destination Groups Operation 1351 The getDestGrpsRqst operation allows a client to get the properties 1352 of Destination Group objects that a registrar organization is 1353 authorized to view. The server will attempt to find a Destination 1354 Group object that has the registrant ID and destination group name 1355 pair contained in each ObjKeyType object instance. If there are no 1356 matching Destination Groups found then an empty result set will be 1357 returned. If the set of ObjKeyType objects passed in is empty then 1358 the server will return the list of Destination Group objects that the 1359 querying registrar has the authority to view. 1361 The element passed into the spppQueryRequest element for this 1362 operation is an instance of type GetDestGrpsRqstType, which extends 1363 BasicQueryRqstType and contains zero or more ObjKeyType objects. Any 1364 limitation on the maximum number of objects that may be passed into 1365 or returned by this operation is a policy decision and not limited by 1366 the protocol. The XSD declaration of the operation is as follows: 1368 1369 1370 1371 1372 1374 1375 1376 1377 1379 As described in an earlier section of this document, the result of 1380 any spppQueryRequest operation is an spppQueryResponse element that 1381 contains the overall response code and the query result set, if any. 1382 Refer to that section of the document for a detailed description of 1383 the spppQueryResponse element. 1385 6.5. Add Route Group Offer Operation 1387 The list of peer organizations whose resolution responses can include 1388 the routing information contained in a given Route Group is 1389 controlled by the organization to which a Route Group object belongs 1390 (its registrant), and the peer organization that submits resolution 1391 requests (a data recipient, also know as a peering organization). 1392 The registrant offers access to a Route Group by submitting a Route 1393 Group Offer. The data recipient can then accept or reject that 1394 offer. Not until access to a Route Group has been offered and 1395 accepted will the data recipient's organization ID be included in the 1396 peeringOrg list in a Route Group object, and that Route Group's 1397 peering information become a candidate for inclusion in the responses 1398 to the resolution requests submitted by that data recipient. The 1399 AddRteGrpOffersRqstType operation creates or overwrites one or more 1400 Route Group Offer objects. If a Route Group Offer for the given 1401 Route Group object key and the offeredToOrg ID does not exist, then 1402 the server creates the Route Group Offer object. If a such a Route 1403 Group Offer does exist, then the server replaces the current object 1404 with the new object. The XSD declarations of the operation request 1405 object are as follows: 1407 1408 1409 1410 1411 1412 1413 1414 1415 1417 The element passed into the spppUpdateRequest element for this 1418 operation is an instance of AddRteGrpOfferRqstType, which extends 1419 BasicRqstType and contains a RteGrpOfferType object. The XSD 1420 declaration of the RteGrpOfferType is as follows: 1422 1423 1424 1425 1426 1428 1429 1430 1431 1432 1433 1434 1435 1437 1438 1439 1440 1441 1442 1444 1445 1446 1447 1448 1449 1450 The RteGrpOfferType object is composed of the following elements: 1452 o base: All first class objects extend BasicObjType which contains 1453 the ID of the registrant organization that owns this object, the 1454 ID of the registrar organization that provisioned this object, 1455 the date and time that the object was created by the server, and 1456 the date and time that the object was last modified. If the 1457 client passed in either the created date or the modification 1458 date, the will ignore them. The server sets these two date/time 1459 values. 1461 o rteGrpOfferKey: The object that identifies the route that is or 1462 has been offered and the organization that it is or has been 1463 offered to. The combination of these three data elements 1464 uniquely identify a Route Group Offer. 1466 o status: The status of the offer, offered or accepted. This 1467 status is controlled by the server. It is automatically set to 1468 "offered" when ever a new Route Group Offer is added, and is 1469 automatically set to "accepted" if and when that offer is 1470 accepted. The value of the element is ignored when passed in by 1471 the client. 1473 o offerDateTime: Date and time in GMT when the Route Group Offer 1474 was added. 1476 o acceptDateTime: Date and time in GMT when the Route Group Offer 1477 was accepted. 1479 As with the responses to all update operations, the result of the 1480 AddRteGrpOfferRqstType operation is contained in the generic 1481 spppUpdateResponse data structure described in an earlier sections of 1482 this document. For a detailed description of the spppUpdateResponse 1483 data structure refer to that section of the document. 1485 6.6. Accept Route Group Offer Operation 1487 Not until access to a Route Group has been offered and accepted will 1488 the data recipient's organization ID will it be included in the 1489 peeringOrg list in that Route Group object, and that Route Group's 1490 peering information become a candidate for inclusion in the responses 1491 to the resolution requests submitted by that data recipient. The 1492 AcceptRteGrpOffersRqstType operation is called by, or on behalf of, 1493 the data recipient to accept a Route Group Offer that is pending in 1494 the "offered" status for the data recipient's organization ID. If a 1495 Route Group Offer for the given Route Group Offer key (route name, 1496 route registrant ID, data recipient's organization ID) exists, then 1497 the server moves the Route Group Offer to the "accepted" status and 1498 adds that data recipient's organization ID into the list of 1499 peerOrgIds for that Route Group. If a such a Route Group Offer does 1500 not exist, then the server returns the appropriate error code, 2105. 1501 The XSD declarations for the operation request object are as follows: 1503 1504 1505 1506 1507 1508 1509 1510 1511 1513 The element passed into the spppUpdateRequest element for this 1514 operation is an instance of AcceptRteGrpOffersRqstType, which extends 1515 BasicRqstType and contains a RteGrpOfferKeyType object. 1517 As with the responses to all update operations, the result of the 1518 AcceptRteGrpOfferRqstType operation is contained in the generic 1519 spppUpdateResponse data structure described in an earlier sections of 1520 this document. For a detailed description of the spppUpdateResponse 1521 data structure refer to that section of the document. 1523 6.7. Reject Route Group Offer Operation 1525 The data recipient to which a Route Group has been offered has the 1526 option of rejecting a Route Group Offer. Furthermore, that offer may 1527 be rejected, regardless of whether or not it has been previously 1528 accepted. The RejectRteGrpOffersRqstType operation is used for these 1529 purposes and is called by, or on behalf of, the data recipient to 1530 accept a Route Group Offer that is pending in the "offered" status or 1531 is in the "accepted" status for the data recipient's organization ID. 1532 If a Route Group Offer for the given Route Group Offer key (route 1533 name, route registrant ID, data recipient's organization ID) exists 1534 in either the offered or accepted status, then the server deletes 1535 that Route Group Offer object, and, if appropriate, removes the data 1536 recipients organization ID from the list of peeringOrg IDs for that 1537 Route Group. If the Route Group Offer does not exist, then the 1538 server returns the appropriate error code, 2105. The XSD 1539 declarations for the operation request object are as follows: 1541 1542 1543 1544 1545 1546 1547 1548 1549 1551 The element passed into the spppUpdateRequest element for this 1552 operation is an instance of RejectRteGrpOffersRqstType, which extends 1553 BasicRqstType and contains a RteGrpOfferKeyType object. 1555 As with the responses to all update operations, the result of the 1556 RejectRteGrpOfferRqstType operation is contained in the generic 1557 spppUpdateResponse data structure described in an earlier sections of 1558 this document. For a detailed description of the spppUpdateResponse 1559 data structure refer to that section of the document. 1561 6.8. Get Route Group Offers Operation 1563 The getRteGrpOffersRqst operation allows a client to get the 1564 properties of zero or more Route Group Offer objects that registrar 1565 is authorized to view. The server will attempt to find Route Group 1566 Offer objects that have all the properties specified in the criteria 1567 passed into the operation. If no criteria is passed in then the 1568 server will return the list of Route Group Offer objects that the 1569 querying client has the authority to view. If there are no matching 1570 Route Group Offers found then an empty result set will be returned. 1572 The element passed into the spppQueryRequest element for this 1573 operation is an instance of GetRteGrpOffersRqstType, which extends 1574 BasicQueryRqstType and contains the criteria that the returned Route 1575 Group Offer objects must match. Any limitation on the maximum number 1576 of objects that may be returned by this operation is a policy 1577 decision and not limited by the protocol. The XSD declaration of the 1578 operation is as follows: 1580 1581 1582 1583 1584 1585 1586 1588 1590 1593 1594 1595 1596 1598 The GetRteGrpOffersRqstType object is composed of the following 1599 elements: 1601 o offeredByPeers: Zero or one boolean value that, if true, 1602 indicates that only offers that are offered by peering 1603 organizations to the querying registrant should be included in 1604 the result set. If this value is false, the offers by peering 1605 organizations to the querying registrant should not be included 1606 in the result set. The result set is also subject to other 1607 query criteria in the request. 1609 o offeredToPeers: Zero or one boolean value that, if true, 1610 indicates that only offers that are offered to peering 1611 organizations by the querying registrant should be included in 1612 the result set. If this value is false, the offers to peering 1613 organizations by the querying registrant should not be included 1614 in the result set. The result set is also subject to other 1615 query criteria in the request. 1617 o status: The status of the offer, offered or accepted. Only 1618 offers in the specified status should be included in the result 1619 set. If this element is not present then the status of the 1620 offer should not be considered in the query. The result set is 1621 also subject to other query criteria in the request. 1623 o peeringOrg: Zero or more organization IDs. Only offers that are 1624 offered to or offered by the organization IDs in this list 1625 should be included in the result set. The result set is also 1626 subject to other query criteria in the request. 1628 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only 1629 offers having one of these keys should be included in the result 1630 set. The result set is also subject to other query criteria in 1631 the request. 1633 As described in an earlier section of this document, the result of 1634 any spppQueryRequest operation is an spppQueryResponse element that 1635 contains the overall response code and the query result set, if any. 1636 Refer to that section of the document for a detailed description of 1637 the spppQueryResponse element. 1639 6.9. Public Identifier Operations 1641 Public Identifier is the search key used for locating the session 1642 establishment data (SED). In many cases, a Public Identifier is 1643 attributed to the end user who has a retail relationship with the 1644 service provider or registrant organization. In SPPP, SED can be 1645 provisioned by the registrant, or by the registrar on behalf of the 1646 registrant. Also, SPPP supports the notion of the carrier-of-record 1647 as defined in RFC 5067. Therefore, the entity adding the Public 1648 Identity in the Registry can optionally claim to be a carrier-of- 1649 record. 1651 SPPP identifies three types of Public Identifiers: telephone number 1652 (TN), email address, and the routing number (RN). SPPP provides 1653 structures to manage a single TN, a contiguous range of TNs, and a TN 1654 prefix. 1656 The XML schema type definition PubIDType is the generalization of the 1657 Public Identifier. PubIDType is an abstract type. In agreement with 1658 the data model, PubIDType member 'dgName' represents the name of the 1659 destination group that a given Public Identifier is associated to. 1660 The PubIDType object structure is defined as follows: 1662 1663 1664 1665 1666 1667 1668 1669 1670 1672 A registrant can add a Public Identifier with the help of a 1673 BasicRqstType called AddPubIdRqstType. To complete the add request, 1674 AddPubIdRqstType XML instance is added to root 1675 element. If there is a conflict and a Public Identifier already 1676 exists in the Registry, the old entry will be replaced with the newly 1677 provisioned entry. For the add or update operation, the destination 1678 group name is a mandatory parameter. Not including a valid 1679 destination group name in the update request will cause the Registry 1680 to return an appropriate error. 1682 Telephone number is identified by TNType, an extension of PubIDType. 1683 TNType is composed of the following attributes: 1685 o tn: Telephone number to be added to the Registry. 1687 o rteRecRef: Optional reference to the route record that is 1688 directly associated with the TN Public Identifier. Following 1689 the SPPP data model, the route record could be a protocol 1690 agnostic URIType or another type. 1692 o corInfo: corInfo is an optional parameter of type CORInfoType 1693 that allows the registrant organization to set forth a claim to 1694 be the carrier-of-record [see RFC 5067]. This is done by 1695 setting the value of element of the CORInfoType 1696 object structure to "true". The other two parameters of the 1697 CORInfoType, and are set by the Registry to 1698 describe the outcome of the carrier-of-record claim by the 1699 registrant. In general, inclusion of parameter is 1700 useful if the Registry has the authority information, such as, 1701 the number portability data, etc., in order to qualify whether 1702 the registrant claim can be satisfied. If the carrier-of-record 1703 claim disagrees with the authority data in the Registry, whether 1704 the TN add operation fails or not is a matter of policy and it 1705 is beyond the scope of this document. In the response message 1706 , the SPPP Server must include the 1707 parameter of the element to let the registrant know 1708 the outcome of the claim. 1710 TNType object definition is as follows: 1712 1713 1714 1715 1716 1717 1719 1721 1722 1723 1724 1726 Routing number is identified by RNType. SSPs that possess the number 1727 portability data may be able to leverage the RN search key to 1728 discover the ingress routes for session establishment. Therefore, 1729 the registrant organization can add the RN and associate it with the 1730 appropriate destination group to share the route information. 1732 RNType is composed of the following attributes: 1734 o rn: Routing Number used as the search key 1736 o corInfo: Optional element of type CORInfoType. 1738 RNType object information is as follows: 1740 1741 1742 1743 1744 1745 1747 1748 1749 1750 1752 A contiguous range of TNs is added with the help of TNRType 1753 structure. The object definition requires a starting TN and the 1754 ending TN that describes the TN range. In addition, TNRType includes 1755 an optional "prefix" attribute to indicate that the given TN range 1756 qualifies for the Open Number Plan (ONP). In order to correctly 1757 expand the number range that qualifies for Open Number Plan, the 1758 Registry must have the required data related to the national 1759 significant number length for the TNs in the TN range object. 1760 Further, is transactional in nature, therefore, 1761 if the Registry encounters an error in adding even a single TN of a 1762 TNRType object, the whole request will be deemed a failure. In other 1763 words, the partial success case is not supported. 1765 TNRType is composed of the following attributes: 1767 o startTn: Starting TN in the TN range 1769 o endTn: The last TN in the TN range 1771 o corInfo: Optional element of type CORInfoType 1773 o prefix: Optional attribute, when set to "true", indicates that 1774 the Open Number Plan applies to a given TN Range 1776 TNPType object structure is as follows: 1778 1779 1780 1781 1782 1783 1784 1786 1787 1788 1789 1790 1791 1793 In some cases, it is useful to describe a set of TNs with the help of 1794 the first few digits of the telephone numbers identified as telephone 1795 number prefix. In many instances, the numbering authority assigns TN 1796 prefix, also referred to as a TN block, to a well-known telephony 1797 service provider. In SPPP, the TNPType structure describes a TN 1798 prefix and it consists of the following attributes: 1800 o tnPrefix: The telephone number prefix 1802 o corInfo: Optional element of type CORInfoType. 1804 TNPType object structure is as follows: 1806 1807 1808 1809 1810 1811 1813 1814 1815 1816 1818 The object structure of AddPubIdRqstType used to add Public 1819 Identifiers is as follows 1821 1822 1823 1824 1825 1826 1827 1828 1829 1831 The client can set the GetPubIdsRqstType in the 1832 structure to obtain information about one or more objects that 1833 were successfully provisioned earlier and that the calling entity is 1834 privileged to see. If the GetPubIdsRqstType object does not include 1835 data, then all authorized Public Identity data will be returned 1836 by the Registry in the response. If no matching Public Identifiers 1837 are found, then an empty result set will be returned. 1839 GetPubIdsRqstType object structure is as follows: 1841 1842 1843 1844 1845 1847 1848 1849 1850 1852 As described in an earlier section of this document, the result of 1853 any spppQueryRequest operation is a spppQueryResponse that contains 1854 the response code and the query result set, if any. 1856 6.10. Egress Route Operations 1858 The egress route add operation allows a call originating SSP to 1859 define a preferred egress route in an attempt to reach the ingress 1860 SBE of the target SSP. The need arises when there is a choice of 1861 egress SBE and an SSP wants to exercise greater control in deciding 1862 how to route the outbound session establishment request. 1864 As a first step, it is assumed that the target SSP has offered to 1865 share the route group that consists of the ingress route information 1866 to the SBE(s) and the originating SSP has accepted the offer. Next, 1867 the originating SSP can add the egress route in the Registry, with 1868 appropriate regular expression, to rewrite ingress route information 1869 from the target SSP and include the egress SBE information. In high- 1870 availability configurations, the originating SSP will likely add a 1871 secondary egress route object re-writing the same ingress route from 1872 the target SSP with a secondary choice of egress SBE as a backup. In 1873 this case, the backup egress route definition will carry the higher 1874 integer value for the "pref" parameter to indicate a lower priority. 1876 An egress route is identified by type EgrRteType and its object 1877 structure is shown below: 1879 1880 1881 1882 1883 1884 1885 1886 1888 1889 1890 1891 1892 1894 The EgrRteType object is composed of the following elements: 1896 o base: All first class objects extend BasicObjType which contains 1897 the ID of the registrant organization that owns this object, the 1898 ID of the registrar organization that provisioned this object, 1899 the date and time that the object was created by the server, and 1900 the date and time that the object was last modified. If the 1901 client passes in either the created date or the modification 1902 date, the server will ignore them. The server sets these two 1903 date/time values. 1905 o egrRteName: The name of the egress route. 1907 o pref: The preference of this egress route relative to other 1908 egress routes that may get selected when responding to a 1909 resolution request. 1911 o regxRewriteRule: The regular expression re-write rule that 1912 should be applied to the regular expression of the ingress 1913 NAPTR(s) that belong to the ingress route. 1915 o ingrRteRec: The ingress route records that the egress route 1916 should be used for. 1918 o ext: Point of extensibility described in a previous section of 1919 this document. 1921 The AddEgrRteRqstType request is used to create or overwrite an 1922 egress route. 1924 1925 1926 1927 1928 1929 1930 1931 1932 1934 An instance of AddEgrRtesRqstType is added in the spppUpdateRequest 1935 element in order to send a valid request to the server. Any 1936 limitation on the maximum number of AddEgrRteRqstType instances is a 1937 matter of policy and is not limited by the specification. 1939 The response from the server is returned in addEgrRteRspns element, 1940 which is defined as the element of type BasicRspnsType. 1942 The GetEgrRtesRqstType is used by an authorized entity to fetch the 1943 well-known egress route data. 1945 1946 1947 1948 1949 1951 1952 1953 1954 1956 6.11. Add Route Record Operation 1958 As described in the introductory sections, a Route Group represents a 1959 combined grouping of Route Records that define route information. 1960 However, Route Records need not be created to just server a single 1961 Route Group. Route Records can be created and managed to serve 1962 multiple Route Groups. As a result, a change to the properties of a 1963 network node, for example, that is used for multiple routes, would 1964 necessitate just a single update operation to change the properties 1965 of that node. The change would then be reflected in all the Route 1966 Groups whose route record set contains a reference to that node. 1968 The AddRteRecRqstType operation creates or overwrites a Route Record 1969 object. If a Route Record with the given name and registrant ID 1970 (which together comprise the unique key or a Route Record) does not 1971 exist, then the server MUST create the Route Record. If a Route 1972 Record with the given name and registrant ID does exist, then the 1973 server MUST replace the current properties of the Route Record with 1974 the properties passed into the AddRteRecRqstType operation. The XSD 1975 declarations of the AddRteRecRqstType operation request object are as 1976 follows: 1978 1979 1980 1981 1982 1983 1984 1985 1986 1988 The element passed into the spppUpdateRequest element for this 1989 operation is an instance of AddRteRecRqstType, which extends 1990 BasicRqstType and contains one RteRecType object. The RteRecType 1991 object structure is defined as follows: 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2004 The RteRecType object is composed of the following elements: 2006 o base: All first class objects extend BasicObjType which contains 2007 the ID of the registrant organization that owns this object, the 2008 ID of the registrar organization that provisioned this object, 2009 the date and time that the object was created by the server, and 2010 the date and time that the object was last modified. If the 2011 client passes in either the created date or the modification 2012 date, the server will ignore them. The server sets these two 2013 date/time values. 2015 o rrName: The character string that contains the name of the Route 2016 Record. It uniquely identifies this object within the context 2017 of the registrant ID (a child element of the base element as 2018 described above). 2020 o priority: Zero or one priority value that can be used to provide 2021 a relative value weighting of one Route Record over another. 2022 The manner in which this value is used, perhaps in conjunction 2023 with other factors, is a matter of policy. 2025 o ext: Point of extensibility described in a previous section of 2026 this document. 2028 As described above, route records are based on an abstract type: 2029 RteRecType. The concrete types that use RteRecType as an extension 2030 base are NAPTRType, NSType, and URIType. The definitions of these 2031 types are included below. The NAPTRType object is comprised of the 2032 data elements necessary for a NAPTR that contains routing information 2033 for a Route Group. The NSType object is comprised of the data 2034 elements necessary for a Name Server that points to another DNS 2035 server that contains the desired routing information. The URIType 2036 object is comprised of the data elements necessary to house a URI. 2038 The data provisioned in a Registry can be leveraged for many purposes 2039 and queried using various protocols including SIP, ENUM and others. 2040 It is for this reason that a route record type offers a choice of URI 2041 and DNS resource record types. URIType fulfills the need for both 2042 SIP and ENUM protocols. When a given URIType is associated to a 2043 destination group, the user part of the replacement string that 2044 may require the Public Identifier cannot be preset. As a SIP 2045 Redirect, the resolution server will apply pattern on the input 2046 Public Identifier in the query and process the replacement string by 2047 substituting any back reference(s) in the to arrive at the 2048 final URI that is returned in the SIP Contact header. For an ENUM 2049 query, the resolution server will simply return the value of the 2050 and members of the URIType in the NAPTR REGEX parameter. 2052 2053 2054 2055 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2068 2069 2070 2071 2072 2073 2074 2076 2077 2078 2079 2080 2081 2083 2084 2085 2086 2087 2088 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2102 2103 2104 2105 2106 2107 2108 2110 2111 2112 2113 2114 2115 2117 The NAPTRType object is composed of the following elements: 2119 o order: Order value in an ENUM NAPTR, relative to other NAPTRType 2120 objects in the same Route Group. 2122 o svcs: ENUM service(s) that are served by the SBE. This field's 2123 value must be of the form specified in [RFC3761] (e.g., E2U+ 2124 pstn:sip+sip). The allowable values are a matter of policy and 2125 not limited by this protocol. 2127 o regx: NAPTR's regular expression field. If this is not included 2128 then the Repl field must be included. 2130 o repl: NAPTR replacement field, should only be provided if the 2131 Regex field is not provided, otherwise it will be ignored by the 2132 server. 2134 o ttl: Number of seconds that an addressing server may cache this 2135 NAPTR. 2137 o ext: Point of extensibility described in a previous section of 2138 this document. 2140 The NSType object is composed of the following elements: 2142 o hostName: Fully qualified host name of the name server. 2144 o ipAddr: Zero or more objects of type IpAddrType. Each object 2145 holds an IP Address and the IP Address type, IPv4 or IP v6. 2147 o ttl: Number of seconds that an addressing server may cache this 2148 Name Server. 2150 o ext: Point of extensibility described in a previous section of 2151 this document. 2153 The URIType object is composed of the following elements: 2155 o ere: The POSIX Extended Regular Expression (ere) as defined in 2156 [RFC3986]. 2158 o uri: the URI as defined in [RFC3986]. In some cases, this will 2159 serve as the replacement string and it will be left to the 2160 resolution server to arrive at the final usable URI. 2162 As with the responses to all update operations, the result of the 2163 AddRteRecRqstType operation is contained in the generic 2164 spppUpdateResponse data structure described in an earlier sections of 2165 this document. For a detailed description of the spppUpdateResponse 2166 data structure refer to that section of the document. 2168 6.12. Get Route Records Operation 2170 The getRteRecsRqst operation allows a client to get the properties of 2171 Route Record objects that a registrar organization is authorized to 2172 view. The server will attempt to find a Route Record object that has 2173 the registrant ID and route record name pair contained in each 2174 ObjKeyType object instance. If the set of ObjKeyType objects is 2175 empty then the server will return the list of Route Record objects 2176 that the querying client has the authority to view. If there are no 2177 matching Route Record found then an empty result set will be 2178 returned. 2180 The element passed into the spppQueryRequest element for this 2181 operation is an instance of type GetRteRecsRqstType, which extends 2182 BasicRqstType and contains zero or more ObjKeyType objects. Any 2183 limitation on the maximum number of objects that may be passed into 2184 or returned by this operation is a policy decision and not limited by 2185 the protocol. The XSD declaration of the operation is as follows: 2187 2188 2189 2190 2191 2193 2194 2195 2197 2199 As described in an earlier section of this document, the result of 2200 any spppQueryRequest operation is an spppQueryResponse element that 2201 contains the overall response code and the query result set, if any. 2202 Refer to that section of the document for a detailed description of 2203 the spppQueryResponse element. 2205 6.13. Delete Operation 2207 In order to remove an object from the Registry, an authorized entity 2208 can send the to the Registry with a corresponding 2209 delete BasicRqstType object. If the entity that issued the command 2210 is not authorized to perform this operation or if the public 2211 identifier doesn't exist, an appropriate error code will be returned 2212 in the message. 2214 As an example, DelPubIdRqstType aids in identifying the Public 2215 Identifier that is used to delete a Public Identifier from the 2216 Registry. DelPubIdsRqstType object definition is shown below: 2218 2219 2220 2221 2222 2223 2224 2225 2226 2228 Similarly, each 'Add' operation in the SP protocol has a 2229 corresponding 'Del' operation used to delete the respective object 2230 type from the Registry. 2232 7. SPPP Examples 2234 This section shows XML message exchange between two SIP Service 2235 Providers (SSP) and a Registry. For the sake of simplicity, the 2236 transport wrapper for the SPPP protocol is left out. The SPPP 2237 protocol messages in this section are valid XML instances that 2238 conform to the SPPP schema version within this document. 2240 In this sample use case scenario, SSP1 and SSP2 provision resource 2241 data in the registry and use SPPP constructs to selectively share the 2242 route groups. In the figure below, SSP2 has two ingress SBE 2243 instances that are associated with the public identities that SSP2 2244 has the retail relationship with. Also, the two SBE instances for 2245 SSP1 are used to show how to use SPPP protocol to associate route 2246 preferences for the destination ingress routes and exercise greater 2247 control on outbound traffic to the peer's ingress SBEs. 2249 ---------------+ +------------------ 2250 | | 2251 +------+ +------+ 2252 | sbe1 | | sbe2 | 2253 +------+ +------+ 2254 SSP1 | | SSP2 2255 +------+ +------+ 2256 | sbe3 | | sbe4 | 2257 +------+ +------+ 2258 iana-en:111 | | iana-en:222 2259 ---------------+ +------------------ 2260 | | 2261 | | 2262 | SPPP +------------------+ SPPP | 2263 +------->| Registry |<--------+ 2264 +------------------+ 2266 7.1. Add Destination Group 2268 SSP2 adds a destination group to the Registry for use later. The 2269 SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for 2270 tracking purposes. The name of the destination group is set to 2271 DEST_GRP_SSP2_1 2272 2273 2277 txid-5555 2278 2280 2281 iana-en:222 2282 iana-en:222 2283 DEST_GRP_SSP2_1 2284 2285 2286 2288 The Registry processes the request and return a favorable response 2289 confirming successful creation of the named destination group. Also, 2290 besides returning a unique transaction identifier, Registry also 2291 returns the matching client transaction identifier from the request 2292 message back to the SPPP client. 2294 2295 2299 tx_7777 2300 tx_id_12346 2301 2302 1000 2303 success 2304 2305 2307 7.2. Add Route Records 2309 SSP2 adds an ingress routes in the Registry. 2311 2312 2316 2318 2320 iana-en:222 2321 iana-en:222 2322 RTE_SSP2_SBE2 2323 10 2324 u 2325 E2U+sip 2326 2327 ^(.*)$ 2328 sip:\1@sbe2.ssp2.example.com 2329 2330 2331 2332 2334 The Registry returns a success response. 2336 2337 2341 tx_id_11145 2342 2343 1000 2344 Request successful 2345 2346 2348 7.3. Add Route Records -- URIType 2350 SSP2 adds another ingress routes in the Registry and makes use of 2351 URIType 2352 2353 2357 2359 2361 iana-en:222 2362 iana-en:222 2363 RTE_SSP2_SBE4 2364 ^(.*)$ 2365 sip:\1;npdi@sbe4.ssp2.example.com 2366 2367 2368 2370 The Registry returns a success response. 2372 2373 2377 tx_id_11145 2378 2379 1000 2380 Request successful 2381 2382 2384 7.4. Add Route Group 2386 SSP2 creates the grouping of the ingress routes and choses higher 2387 precedence for RTE_SSP2_SBE2 by setting a lower number for the 2388 "priority" attribute, a protocol agnostic precedence indicator. 2390 2391 2395 2397 2398 iana-en:222 2399 iana-en:222 2400 RTE_GRP_SSP2_1 2401 2402 2403 iana-en:222 2404 RTE_SSP2_SBE2 2405 2406 100 2407 2408 DEST_GRP_SSP2_1 2409 true 2410 10 2411 2412 2413 2415 To confirm successful processing of this request, Registry returns a 2416 well-known resolution code '1000' to the SSP2 client. 2418 2419 2423 tx_id_12345 2424 2425 1000 2426 Request successful 2427 2428 2430 7.5. Add Public Identity -- Successful COR claim 2432 SSP2 activates a TN public identity by associating it with a valid 2433 destination group. Further, SSP2 puts forth a claim that it is the 2434 carrier-of-record for the TN. 2436 2437 2440 txid-5577 2441 2443 2445 iana-en:222 2446 iana-en:222 2447 2010-05-30T09:30:10Z 2448 DEST_GRP_SSP2_1 2449 +12025556666 2450 2451 true 2452 2453 2454 2455 2457 Assuming that the Registry has access to TN authority data and it 2458 performs the required checks to verify that SSP2 is in fact the 2459 service provider of record for the given TN, the request was 2460 processed successfully. element confirms SSP2 claim to be the 2461 carrier of record has been accepted and the processing time is 2462 reflected by data element. 2464 2465 2469 txid-5577 2470 tx_id_12345 2471 2472 1000 2473 success 2474 2475 2476 1000 2477 success 2478 2480 2482 iana-en:222 2483 iana-en:222 2484 2010-05-30T09:30:10Z 2485 DEST_GRP_SSP2_1 2486 +12025556666 2487 2488 true 2489 true 2490 2006-05-04T18:13:51.0Z 2491 2492 2493 2494 2495 2496 2498 7.6. Add LRN 2500 If another entity that SSP2 shares the routes with has access to 2501 Number Portability data, it may choose to perform route lookups by 2502 routing number. Therefore, SSP2 associates a routing number to a 2503 destination group in order to facilitate ingress route discovery. 2505 2506 2509 2511 2513 rantId0 2514 rarId0 2515 DEST_GRP_SSP2_1 2516 2025550000 2517 2518 2519 2521 Registry completes the request successfully and returns a favorable 2522 response to the SPPP client. 2524 2525 2529 tx_id_12345 2530 2531 1000 2532 Request successful 2533 2534 2536 7.7. Add TN Range 2538 Next, SSP2 activates a block of ten thousand TNs and associate it to 2539 a destination group. Since the 'prefix' public identity attribute is 2540 not set to 'true', this means that the TNs belong to a closed number 2541 plan. 2543 2544 2547 2549 2551 iana-en:222 2552 iana-en:222 2553 DEST_GRP_SSP2_1 2554 +12026660000 2555 +12026669999 2556 2557 2558 2560 Registry completes the request successfully and returns a favorable 2561 response. 2563 2564 2568 tx_id_12244498 2569 2570 1000 2571 Request successful 2572 2573 2575 7.8. Add TN Range with Open Number Plan support 2577 In this case, open number plan refers to TN length variance. 2578 Inclusion of "prefix" attribute of TNRType with its value set to true 2579 indicates that the start TN range identified by the element is 2580 not necessarily a subscriber number and the Registry will have to 2581 consult the number plan data for the respective country to know how 2582 to expand the number range. attribute marks the end of the TN 2583 range. 2585 2586 2589 2591 2593 iana-en:222 2594 iana-en:222 2595 DEST_GRP_SSP2_1 2596 +4312315566 2597 +4312315567 2598 2599 2600 2602 Registry completes the request successfully and returns a favorable 2603 response. 2605 2606 2610 tx_id_12255598 2611 2612 1000 2613 Request successful 2614 2615 2617 7.9. Add TN Prefix 2619 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2620 structure and identifying a TN prefix. 2622 2623 2626 2628 2630 iana-en:222 2631 iana-en:222 2632 DEST_GRP_SSP2_1 2633 +1202777 2634 2635 2636 2638 Registry completes the request successfully and returns a favorable 2639 response. 2641 2642 2646 tx_id_12387698 2647 2648 1000 2649 Request successful 2650 2651 2653 7.10. Enable Peering -- Route Group Offer 2655 In order for SSP1 to complete session establishment for a destination 2656 TN where the target subscriber has a retail relationship with SSP2, 2657 it first requires an asynchronous bi-directional handshake to show 2658 mutual consent. To start the process, SSP2 initiates the peering 2659 handshake by offering SSP1 access to its route group. 2661 2662 2665 2667 2668 iana-en:222 2669 iana-en:222 2670 2671 2672 iana-en:222 2673 RTE_GRP_SSP2_1 2674 2675 iana-en:111 2676 2677 offered 2678 2006-05-04T18:13:51.0Z 2679 2680 2681 2683 Registry completes the request successfully and confirms that the 2684 SSP1 will now have the opportunity to weigh in on the offer and 2685 either accept or reject it. The Registry may employ out-of-band 2686 notification mechanisms for quicker updates to SSP1 so they can act 2687 faster, though this topic is beyond the scope of this document. 2689 2690 2694 tx_id_12277798 2695 2696 1000 2697 Request successful 2698 2699 2701 7.11. Enable Peering -- Route Group Offer Accept 2703 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2704 SSP2 ingress routes. 2706 2707 2710 2712 2713 2714 iana-en:222 2715 RTE_GRP_SSP2_1 2716 2717 iana-en:111 2718 2719 2720 2722 Registry confirms that the request has been processed successfully. 2723 From this point forward, if SSP1 looks up a public identity through 2724 the query resolution server, where the public identity is part of the 2725 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2726 ingress SBE information will be shared with SSP1. 2728 2729 2733 tx_id_12333798 2734 2735 1000 2736 success 2737 2738 2740 7.12. Add Egress Route 2742 SSP1 wants to prioritize all outbound traffic to routes associated 2743 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". 2745 2746 2749 tx_9000 2750 2752 2753 iana-en:111 2754 2755 EGR_RTE_01 2756 50 2757 2758 ^(.*@)(.*)$ 2759 \1\2?route=sbe1.ssp1.example.com 2760 2761 2762 iana-en:222 2763 SSP2_RTE_REC_3 2764 2765 2766 2767 2769 Since peering has already been established, the request to add the 2770 egress route has been successfully completed. 2772 2773 2777 tx_9000 2778 tx_id_12388898 2779 2780 1000 2781 Request successful 2782 2784 2786 7.13. Get Destination Group 2788 SSP2 uses the 'GetDestGrpsRqstType' operation to tally the last 2789 provisioned record for destination group DEST_GRP_SSP2_1. 2791 2792 2795 2797 2798 iana-en:222 2799 DEST_GRP_SSP2_1 2800 2801 2802 2804 Registry completes the request successfully and returns a favorable 2805 response. 2807 2808 2811 2812 1000 2813 success 2814 2815 2817 iana-en:222 2818 iana-en:222 2819 DEST_GRP_SSP2_1 2820 2821 2823 7.14. Get Public Identity 2825 SSP2 obtains the last provisioned record associated with a given TN. 2827 2828 2831 2833 2835 iana-en:222 2836 iana-en:222 2837 +12025556666 2838 2839 2840 2842 Registry completes the request successfully and returns a favorable 2843 response. 2845 2846 2849 2850 1000 2851 success 2852 2853 2855 iana-en:222 2856 iana-en:222 2857 DEST_GRP_1 2858 +12025556666 2859 2860 true 2861 true 2862 2010-05-30T09:30:10Z 2863 2864 2865 2867 7.15. Get Route Group Request 2869 SSP2 obtains the last provisioned record for the route group 2870 RTE_GRP_SSP2_1. 2872 2873 2876 2878 2879 iana-en:222 2880 RTE_GRP_SSP2_1 2881 2882 2883 2885 Registry completes the request successfully and returns a favorable 2886 response. 2888 2889 2892 2893 1000 2894 success 2895 2896 2898 iana-en:222 2899 iana-en:222 2900 RTE_GRP_SSP2_1 2901 2902 2903 iana-en:222 2904 RTE_SSP2_SBE2 2905 2906 100 2907 2908 2909 2910 iana-en:222 2911 RTE_SSP2_SBE4 2912 2913 101 2914 2915 DEST_GRP_SSP2_1 2916 true 2917 10 2918 2919 2921 7.16. Get Route Group Offers Request 2923 SSP2 choses to fetch the last provisioned route group sharing offer 2924 to the SSP1. 2926 2927 2930 2932 true 2933 ssp1 2934 2935 2937 Registry completes the request successfully and returns a favorable 2938 response. 2940 2941 2944 2945 1000 2946 success 2947 2948 2950 iana-en:222 2951 iana-en:222 2952 2953 2954 iana-en:222 2955 RTE_GRP_SSP2_1 2956 2957 iana-en:111 2958 2959 offered 2960 2006-05-04T18:13:51.0Z 2961 2962 2964 7.17. Get Egree Route 2966 SSP1 wants to verify the last provisioned record for the egress route 2967 called EGR_RTE_01. 2969 2970 2973 2975 2976 iana-en:111 2977 EGR_RTE_01 2978 2979 2980 2982 Registry completes the request successfully and returns a favorable 2983 response. 2985 2986 2989 2990 1000 2991 success 2992 2993 2995 iana-en:111 2996 iana-en:111 2997 EGR_RTE_01 2998 50 2999 E2U+sip 3000 3001 ^(.*)$ 3002 sip:\1@sbe1.ssp1.example.com 3003 3004 3005 iana-en:222 3006 RTE_GRP_SSP2_1 3007 3008 3009 3011 7.18. Delete Destination Group 3013 SSP2 initiates a request to delete the destination group 3014 DEST_GRP_SSP2_1. 3016 3017 3020 3022 3023 iana-en:222 3024 DEST_GRP_SSP2_1 3025 3026 3027 3029 Registry completes the request successfully and returns a favorable 3030 response. 3032 3033 3036 txid-982543123 3037 3038 1000 3039 Success 3040 3041 3043 7.19. Delete Public Identity 3045 SSP2 choses to de-activate the TN and remove it from the Registry. 3047 3048 3051 3053 3055 iana-en:222 3056 iana-en:222 3057 +12025556666 3058 3059 3060 3062 Registry completes the request successfully and returns a favorable 3063 response. 3065 3066 3069 txid-98298273123 3070 3071 1000 3072 success 3073 3074 3076 7.20. Delete Route Group Request 3078 SSP2 removes the route group called RTE_GRP_SSP2_1. 3080 3081 3084 3086 3087 iana-en:222 3088 RTE_GRP_SSP2_1 3089 3090 3091 3093 Registry completes the request successfully and returns a favorable 3094 response. 3096 3097 3100 txid-982543123 3101 3102 1000 3103 msg 3104 3105 3107 7.21. Delete Route Group Offers Request 3109 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. 3111 3112 3115 3117 3118 3119 iana-en:222 3120 RTE_GRP_SSP2_1 3121 3122 iana-en:111 3123 3124 3125 3127 Registry completes the request successfully and returns a favorable 3128 response. Restoring this resource sharing will require a new route 3129 group offer from SSP2 to SSP1 followed by a successful route group 3130 accept request from SSP1. 3132 3133 3136 txid-982543123 3137 3138 1000 3139 Success 3140 3141 3143 7.22. Delete Egress Route 3145 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3147 3148 3151 3153 3154 iana-en:111 3155 EGR_RTE_01 3156 3157 3158 3160 Registry completes the request successfully and returns a favorable 3161 response. 3163 3164 3167 txid-982543123 3168 3169 1000 3170 Success 3171 3172 3174 8. XML Considerations 3176 XML serves as the encoding format for SPPP, allowing complex 3177 hierarchical data to be expressed in a text format that can be read, 3178 saved, and manipulated with both traditional text tools and tools 3179 specific to XML. 3181 XML is case sensitive. Unless stated otherwise, XML specifications 3182 and examples provided in this document MUST be interpreted in the 3183 character case presented to develop a conforming implementation. 3185 This section discusses a small number of XML-related considerations 3186 pertaining to SPPP. 3188 8.1. Namespaces 3190 All SPPP protocol elements are defined in the namespaces in te IANA 3191 Considerations section and in the Formal Protocol Specification 3192 section of this document. 3194 8.2. Versioning and Character Encoding 3196 All XML instances SHOULD begin with an declaration to 3197 identify the version of XML that is being used, optionally identify 3198 use of the character encoding used, and optionally provide a hint to 3199 an XML parser that an external schema file is needed to validate the 3200 XML instance. 3202 Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) 3203 and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the 3204 RECOMMENDED character encoding for use with SPPP. 3206 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 3207 UTF-8 is the default encoding assumed by XML in the absence of an 3208 "encoding" attribute or a byte order mark (BOM); thus, the "encoding" 3209 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 3210 used. SPPP clients and servers MUST accept a UTF-8 BOM if present, 3211 though emitting a UTF-8 BOM is NOT RECOMMENDED. 3213 Example XML declarations: 3215 version="1.0" encoding="UTF-8" standalone="no"?> 3217 9. Security Considerations 3219 The transport protocol section contains some security properties that 3220 the transport protocol must provide so that authenticated endpoints 3221 can exchange data confidentially and with integrity protection. 3223 More details will be provided in a future revision of this document. 3225 10. IANA Considerations 3227 This document uses URNs to describe XML namespaces and XML schemas 3228 conforming to a registry mechanism described in [RFC3688]. 3230 Two URI assignments are requested. 3232 Registration request for the SPPP XML namespace: 3233 urn:ietf:params:xml:ns:sppp:base:1 3234 Registrant Contact: IESG 3235 XML: None. Namespace URIs do not represent an XML specification. 3237 Registration request for the XML schema: 3238 URI: urn:ietf:params:xml:schema:sppp:1 3239 Registrant Contact: IESG 3240 XML: See the "Formal Specification" section of this document 3241 (Section 11). 3243 IANA is requested to create a new SPPP registry for Organization 3244 Identifiers that will indicate valid strings to be used for well- 3245 known enterprise namespaces. 3246 This document makes the following assignments for the OrgIdType 3247 namespaces: 3249 Namespace OrgIdType namespace string 3250 ---- ---------------------------- 3251 IANA Enterprise Numbers iana-en 3253 11. Formal Specification 3255 This section provides the draft XML Schema Definition for the SPPP 3256 protocol. 3258 3259 3263 3264 3265 ------------------ Object Type Definitions -------------- 3266 3267 3268 3269 3270 3271 3272 3273 3275 3277 3279 3281 3282 3283 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3322 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 3394 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3436 3437 3438 3439 3440 3441 3442 ------------------ Abstract Object and Element 3443 Type Definitions -------------- 3444 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3518 3519 3520 3521 3522 3523 3524 3526 3527 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 -------------- Operation Request and Response 3556 Object Type Definitions ------------ 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3637 3638 3639 3640 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658 3659 3660 3661 3662 3663 3664 3666 3667 3668 3669 3670 3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3713 3714 3715 3716 3717 3718 3719 3720 3721 3723 3724 3725 3726 3727 3728 3729 3730 3731 3733 3734 3735 3736 3737 3738 3739 3740 3741 3743 3745 3747 3749 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3780 3781 3782 3783 3784 3785 -------- Generic Request and Response Definitions 3786 --------------- 3787 3788 3789 3790 3791 3793 3795 3797 3798 3799 3800 3801 3802 3803 3805 3806 3807 3810 3811 3812 3813 3814 3815 3816 3818 3819 3820 3821 3822 3823 3824 3825 3826 3828 3829 3830 3831 3832 3833 3834 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 12. Specification Extensibility 3850 The protocol defined in this specification is extensible. This 3851 section explains how to extend the protocol and what procedures are 3852 necessary to follow in order to ensure proper extensions. 3854 13. Acknowledgments 3856 This document is a result of various discussions held in the DRINKS 3857 working group and within the DRINKS protocol design team, which is 3858 comprised of the following individuals, in alphabetical order: 3859 Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa 3860 Dusseault, Manjul Maharishi, Otmar Lendl, Richard Shockey and Sumanth 3861 Channabasappa. 3863 14. References 3865 14.1. Normative References 3867 [I-D.ietf-drinks-sppp-over-soap] 3868 Cartwright, K., "SPPP Over SOAP and HTTP", 3869 draft-ietf-drinks-sppp-over-soap-00 (work in progress), 3870 June 2010. 3872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3873 Requirement Levels", BCP 14, RFC 2119, March 1997. 3875 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3876 Languages", BCP 18, RFC 2277, January 1998. 3878 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3879 10646", STD 63, RFC 3629, November 2003. 3881 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3882 January 2004. 3884 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3885 Resource Identifier (URI): Generic Syntax", STD 66, 3886 RFC 3986, January 2005. 3888 14.2. Informative References 3890 [I-D.ietf-drinks-usecases-requirements] 3891 Channabasappa, S., "DRINKS Use cases and Protocol 3892 Requirements", draft-ietf-drinks-usecases-requirements-03 3893 (work in progress), May 2010. 3895 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 3896 10646", RFC 2781, February 2000. 3898 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3899 A., Peterson, J., Sparks, R., Handley, M., and E. 3900 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3901 June 2002. 3903 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 3904 Resource Identifiers (URI) Dynamic Delegation Discovery 3905 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 3907 [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation 3908 Architecture", RFC 4725, November 2006. 3910 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3911 October 2008. 3913 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 3914 Interconnect (SPEERMINT) Terminology", RFC 5486, 3915 March 2009. 3917 Authors' Addresses 3919 Jean-Francois Mule 3920 CableLabs 3921 858 Coal Creek Circle 3922 Louisville, CO 80027 3923 USA 3925 Email: jfm@cablelabs.com 3927 Kenneth Cartwright 3928 TNS 3929 1939 Roland Clarke Place 3930 Reston, VA 20191 3931 USA 3933 Email: kcartwright@tnsi.com 3935 Syed Wasim Ali 3936 NeuStar 3937 46000 Center Oak Plaza 3938 Sterling, VA 20166 3939 USA 3941 Email: syed.ali@neustar.biz 3943 Alexander Mayrhofer 3944 enum.at GmbH 3945 Karlsplatz 1/9 3946 Wien, A-1010 3947 Austria 3949 Email: alexander.mayrhofer@enum.at