idnits 2.17.1 draft-ietf-drinks-spprov-04.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 (February 17, 2011) is 4811 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-01 == Outdated reference: A later version (-06) exists of draft-ietf-drinks-usecases-requirements-04 -- 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: August 21, 2011 TNS 6 S. Ali 7 NeuStar 8 A. Mayrhofer 9 enum.at GmbH 10 February 17, 2011 12 Session Peering Provisioning Protocol 13 draft-ietf-drinks-spprov-04 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 August 21, 2011. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 14 69 4.2. Request and Response Model . . . . . . . . . . . . . . . . 14 70 4.3. Connection Lifetime . . . . . . . . . . . . . . . . . . . 15 71 4.4. Authentication . . . . . . . . . . . . . . . . . . . . . . 15 72 4.5. Confidentiality and Integrity . . . . . . . . . . . . . . 15 73 4.6. Near Real Time . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . 16 78 5. Base Protocol Data Structures . . . . . . . . . . . . . . . . 17 79 5.1. Request and Response Structures . . . . . . . . . . . . . 17 80 5.1.1. Update Request and Response Structures . . . . . . . . 17 81 5.1.2. Query Request and Response Structures . . . . . . . . 20 82 5.2. Response Codes and Messages . . . . . . . . . . . . . . . 22 83 5.3. Basic Object Type and Organization Identifiers . . . . . . 24 84 6. Protocol Commands . . . . . . . . . . . . . . . . . . . . . . 26 85 6.1. Add Route Group Operation . . . . . . . . . . . . . . . . 26 86 6.2. Get Route Groups Operation . . . . . . . . . . . . . . . . 30 87 6.3. Add Destination Group Operation . . . . . . . . . . . . . 31 88 6.4. Get Destination Groups Operation . . . . . . . . . . . . . 32 89 6.5. Add Route Group Offer Operation . . . . . . . . . . . . . 33 90 6.6. Accept Route Group Offer Operation . . . . . . . . . . . . 35 91 6.7. Reject Route Group Offer Operation . . . . . . . . . . . . 36 92 6.8. Get Route Group Offers Operation . . . . . . . . . . . . . 37 93 6.9. Public Identifier Operations . . . . . . . . . . . . . . . 39 94 6.10. Egress Route Operations . . . . . . . . . . . . . . . . . 43 95 6.11. Add Route Record Operation . . . . . . . . . . . . . . . . 46 96 6.12. Get Route Records Operation . . . . . . . . . . . . . . . 50 97 6.13. Delete Operation . . . . . . . . . . . . . . . . . . . . . 51 98 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 53 99 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 53 100 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 54 101 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 55 102 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 56 103 7.5. Add Public Identity -- Successful COR claim . . . . . . . 58 104 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 59 105 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 60 106 7.8. Add TN Range with Open Number Plan support . . . . . . . . 61 107 7.9. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 62 108 7.10. Enable Peering -- Route Group Offer . . . . . . . . . . . 63 109 7.11. Enable Peering -- Route Group Offer Accept . . . . . . . . 65 110 7.12. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 66 111 7.13. Get Destination Group . . . . . . . . . . . . . . . . . . 67 112 7.14. Get Public Identity . . . . . . . . . . . . . . . . . . . 68 113 7.15. Get Route Group Request . . . . . . . . . . . . . . . . . 69 114 7.16. Get Route Group Offers Request . . . . . . . . . . . . . . 70 115 7.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 71 116 7.18. Delete Destination Group . . . . . . . . . . . . . . . . . 73 117 7.19. Delete Public Identity . . . . . . . . . . . . . . . . . . 73 118 7.20. Delete Route Group Request . . . . . . . . . . . . . . . . 74 119 7.21. Delete Route Group Offers Request . . . . . . . . . . . . 75 120 7.22. Delete Egress Route . . . . . . . . . . . . . . . . . . . 76 121 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 78 122 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 78 123 8.2. Versioning and Character Encoding . . . . . . . . . . . . 78 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 79 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 126 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 81 127 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 94 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 95 129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 95 130 13.2. Informative References . . . . . . . . . . . . . . . . . . 95 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97 133 1. Introduction 135 Service providers and enterprises use registries to make call or 136 session routing decisions for Voice over IP, SMS and MMS traffic 137 exchanges. This document is narrowly focused on the provisioning 138 protocol for these registries. This protocol prescribes a way for an 139 entity to provision session-related data into a registry. The data 140 being provisioned can be optionally shared with other participating 141 peering entities. The requirements and use cases driving this 142 protocol have been documented in 143 [I-D.ietf-drinks-usecases-requirements]. The reader is expected to 144 be familiar with the terminology defined in the previously mentioned 145 document. 147 Three types of provisioning flows have been described in the use case 148 document: client to registry provisioning, registry to local data 149 repository and registry-to-registry. This document addresses a 150 subset (client-to-registry provisioning) by defining a Session 151 Peering Provisioning Protocol (SPPP) for provisioning Session 152 Establishment Data (SED) into a Registry (arrow "1" in the figure 153 below). While the other "provisioning flows" are shown below as 154 separate message flows, no determination has been made for whether 155 one common baseline protocol could be used for all three, or whether 156 distinct protocols are required. 158 *------------* *------------* 159 (1). Provisioning SED | | (3).Registry | | 160 -----------------------> | Registry |<------------->| Registry | 161 data into Registries| | to Registry | | 162 *------------* exchanges *------------* 163 / \ \ 164 / \ \ 165 / \ \ 166 / \ v 167 / \ ... 168 / \ 169 / (2). \ 170 / Distributing \ 171 / SED \ 172 V V 173 +----------+ +----------+ 174 |Local Data| |Local Data| 175 |Repository| |Repository| 176 +----------+ +----------+ 178 Three Registry Provisioning Flows 180 Figure 1 182 The data provisioned for session establishment is typically used by 183 various downstream SIP signaling systems to route a call to the next 184 hop associated with the called domain. These systems typically use a 185 local data store ("Local Data Repository") as their source of session 186 routing information. More specifically, the SED data is the set of 187 parameters that the outgoing signaling path border elements (SBEs) 188 need to initiate the session. See [RFC5486] for more details. 190 A "terminating" SIP Service Provider (SSP) provisions SED into the 191 registry to be selectively shared with other peer SSPs. 192 Subsequently, a Registry may distribute the provisioned data into 193 local Data Repositories used for look-up queries (identifier -> URI) 194 or for lookup and location resolution (identifier -> URI -> ingress 195 SBE of terminating SSP). In some cases, the Registry may 196 additionally offer a central query resolution service (not shown in 197 the above figure). 199 A key requirement for the SPPP protocol is to be able to accommodate 200 two basic deployment scenarios: 202 1. A Local Data Repository serves a Look-Up Function (LUF) to 203 determine the target domain to assist in call routing (as 204 described in [RFC5486]). In this case, the querying entity may 205 use other means to perform the Location Routing Function (LRF) 206 which in turn helps determine the actual location of the 207 Signaling Function in that domain. 209 2. A Local Data Repository serves both a Look-Up function (LUF) and 210 Location Routing Function (LRF) to locate the SED data fully. 212 In terms of protocol design, SPPP protocol is agnostic to the 213 transport. This document includes the description of the data model 214 and the means to enable protocol operations within a request and 215 response structure. To encourage interoperability, the protocol 216 supports extensibility aspects. 218 Transport requirements are provided in this document to help with the 219 selection of the optimum transport mechanism. 220 ([I-D.ietf-drinks-sppp-over-soap]) identifies a SOAP transport 221 mechanism for SPPP. 223 This document is organized as follows: 225 o Section 2 provides the terminology; 227 o Section 3 provides an overview of the SPPP protocol, including 228 the layering approach, functional entities and data model; 230 o Section 4 specifies requirements for SPPP transport protocols; 232 o Section 5 describes the base protocol data structures including 233 the request and response elements (Section 5.1), the response 234 codes and messages (Section 5.2) and the basic object type most 235 first class objects extend from; 237 o Section 6 and Section 7 describe the main protocol commands and 238 examples; 240 o Section 8 defines XML considerations that XML parsers must meet 241 to conform to this specification; 243 o Section 11 normatively defines the SPPP protocol using its XML 244 Schema Definition. 246 2. Terminology 248 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 249 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 250 document are to be interpreted as described in [RFC2119]. 252 This document reuses terms from [RFC3261], [RFC5486], use cases and 253 requirements documented in [I-D.ietf-drinks-usecases-requirements] 254 and the ENUM Validation Architecture [RFC4725]. 256 In addition, this document specifies the following additional terms: 258 SPPP: Session Peering Provisioning Protocol, the protocol used to 259 provision data into a Registry (see arrow labeled "1." in Figure 1 260 of [I-D.ietf-drinks-usecases-requirements]). It is the primary 261 scope of this document. 263 SPDP: Session Peering Distribution Protocol, the protocol used to 264 distribute data to Local Data Repository (see arrow labeled "2." 265 in Figure 1 of [I-D.ietf-drinks-usecases-requirements]). 267 Client: An application that supports an SPPP Client; it is 268 sometimes referred to as a "Registry Client". 270 Registry: The Registry operates a master database of Session 271 Establishment Data for one or more Registrants. 273 A Registry acts as an SPPP Server. 275 Registrant: In this document, we extend the definition of a 276 Registrant based on [RFC4725]. The Registrant is the end-user, 277 the person or organization who is the "holder" of the Session 278 Establishment Data being provisioned into the Registry. For 279 example, in [I-D.ietf-drinks-usecases-requirements], a Registrant 280 is pictured as a SIP Service Provider in Figure 2. 282 A Registrant is identified by its name and an identifier in the 283 data model. 285 Registrar: In this document, we also extend the definition of a 286 Registrar from [RFC4725]. A Registrar performs provisioning 287 operations on behalf of a Registrant by interacting with the 288 Registry, in our case via the SPPP protocol defined in this 289 document. 291 A Registrar is identified by its name and an identifier in the 292 data model. 294 3. Protocol High Level Design 296 This section introduces the structure of the data model and provides 297 the information framework for the SPPP protocol. An overview of the 298 protocol operations is first provided with a typical deployment 299 scenario. The data model is then defined along with all the objects 300 manipulated by the protocol and their relationships. 302 3.1. Protocol Layering 304 SPPP is a simple request/reply protocol that allows a client 305 application to submit provisioning data and query requests to a 306 server. The SPPP data structures are designed to be protocol 307 agnostic. Concerns regarding encryption, non-repudiation, and 308 authentication are beyond the scope of this document. For more 309 details, please refer to the Transport Protocol Requirements section. 311 Layer Example 312 +-------------+ +-----------------------------+ 313 (5) |Data Objects | | RteGrpType, etc. | 314 +-------------+ +-----------------------------+ 315 | | 316 +-------------+ +-----------------------------+ 317 (4) | Operations | | AddRteGrpRqstType, etc. | 318 +-------------+ +-----------------------------+ 319 | | 320 +-------------+ +-----------------------------+ 321 (3) | Message | | spppUpdateRequest, | 322 | | | spppUpdateResponse, | 323 | | | spppQueryRequest, | 324 | | | spppQueryResponse | 325 +-------------+ +-----------------------------+ 326 | | 327 +-------------+ +-----------------------------+ 328 (2) | Message | | HTTP, SOAP, None, etc. | 329 | Envelope | | | 330 +-------------+ +-----------------------------+ 331 | | 332 +-------------+ +-----------------------------+ 333 (1) | Transport | | TCP, TLS, BEEP, etc. | 334 | Protocol | | | 335 +-------------+ +-----------------------------+ 337 SPPP Layering 339 Figure 2 341 SPPP can be viewed as a set of layers that collectively define the 342 structure of an SPPP request and response. Layers 1 and 2, as 343 detailed below, are left to separate specifications to allow for 344 potentially multiple SPPP transport, envelope, and authentication 345 technologies. This document defines layers 3, 4, and 5 below. 347 1. The transport protocol layer provides a communication mechanism 348 between the client and server. SPPP can be layered over any 349 transport protocol that provides a set of basic requirements 350 defined in the Transport Protocol Requirements section. 352 2. The message envelope layer is optional, but can provide features 353 that are above the transport technology layer but below the 354 application messaging layer. Technologies such as HTTP and SOAP 355 are examples of messaging envelope technologies. 357 3. The message layer provides a simple, envelope-independent and 358 transport-independent, SPPP wrapper for SPPP request and response 359 messages. 361 4. The operation layer defines the set of base SPPP actions that can 362 be invoked for a given object data type using an SPPP message. 363 Operations are encoded using XML encoded actions and objects. 365 5. The data object layer defines the base set of SPPP data objects 366 that can be included in update operations or returned in 367 operation responses. 369 3.2. Protocol Data Model 371 The data model illustrated and described in Figure 3 defines the 372 logical objects and the relationships between these objects that the 373 SPPP protocol supports. SPPP defines the protocol operations through 374 which an SPPP Client populates a Registry with these logical objects. 375 Various clients belonging to different Registrars may use the 376 protocol for populating the Registry's data. 378 The logical structure presented below is consistent with the 379 terminology and requirements defined in 380 [I-D.ietf-drinks-usecases-requirements]. 382 +-------------+ +------------------+ 383 | all object | |Organization: | 384 | types | |orgId, | 385 +------+------+ |orgName, | 386 +------------>|extension | 387 | | 389 All objects are | | 390 associated with 2 | | 391 Organizations to +------------------+ 392 identify the ^ 393 registrant and |A Route Group is 394 the registrar |associated with 395 |zero or more Peering 396 |Organizations 397 | 398 +--------+--------------+ 399 |Route Group: | +-----[abstract]-+ 400 | rant, | | Route Record: | 401 | rar, | | | 402 | rgName, | | rrName, | 403 | destGrpRef, +------->| priority, | 404 | isInSvc, | | extension | 405 | rrRef, | | | 406 | peeringOrg, | +----------------+ 407 | sourceIdent, | ^ 408 | priority, | | 409 | extension | |Various types 410 +-----------------------+ |of Route 411 ^ |Records... 412 | +------+------------... 413 | | | | 414 | +----+ +-------+ +----+ 415 | | URI| | NAPTR | | NS | 416 +----------------+-----+ +----+ +-------+ +----+ 417 |Destination | 418 |Group: | +----------[abstract]-+ 419 | rant, | |Public Identifier: | 420 | rar, | | | 421 | dgName, | | rant, | 422 | extension |<----+ rar, | 423 +----------------------+ | publicIdentifier, | 424 | destGrpRef, | 425 | rrRef, | 426 | extension | 427 +---------------------+ 428 ^ 429 |Various types 430 |of Public 431 |Identifiers... 432 +---------+-------+------------... 433 | | | | 434 +------+ +-----+ +-----+ +-----+ 435 | TN | | TNP | | TNR | | RN | 436 +------+ +-----+ +-----+ +-----+ 437 SPPP Data Model 439 Figure 3 441 The objects and attributes that comprise the data model can be 442 described as follows (objects listed from the bottom up): 444 o Public Identifier: 445 From a broad perspective a public identifier is a well known 446 attribute that is used as the key to perform resolution lookups. 447 Within the context of SPPP, a Public Identifier object can be a 448 telephone number, a range of telephone numbers, a PSTN Routing 449 Number (RN), or a prefix. 451 An SPPP Public Identifier is associated with a Destination Group 452 to create a logical grouping of Public Identifiers that share a 453 common set of Routes. 455 A TN Public Identifier may optionally be associated with zero or 456 more individual Route Records. This ability for a Public 457 Identifier to be directly associated with a set of Route Records 458 (e.g. target URI), as opposed to being associated with a 459 Destination Group, supports the use cases where the target URI 460 contains data specifically tailored to an individual TN Public 461 Identifier. 463 o Destination Group: 464 A named collection of zero or more Public Identifiers that can be 465 associated with one or more Route Groups for the purpose of 466 facilitating the management of their common routing information. 468 o Route Group: 469 A Route Group contains a set of references to Route Records, a set 470 of Destination Group references, and a set of peering organization 471 identifiers. This is used to establish a three part relationships 472 between a set of Public Identifiers and their common routing 473 information (SED), and the list of peering organizations whose 474 query responses may include that routing information in their 475 query responses. To support the use cases defined in [I-D.ietf- 476 drinks-usecases-requirements], this document defines the following 477 types of Route Records: NAPTRType, NSType, and URIType. The 478 sourceIdent element within a Route Group, in concert with the set 479 of peering organization identifiers enables fine grained source 480 based routing. Further details about the Route Group and source 481 based routing refer to the definitions and descriptions of the 482 Route Group operations found later in this document. 484 o Route Record: 485 A Route Record contains the data that a resolution system returns 486 in response to a successful query for a Public Identifier. Route 487 Recoords are associated with a Route Group for SED that is not 488 specific to a Public Identifier. 489 To support the use cases defined in 490 [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines 491 three type of Route Records: URIType, NAPTRType, and NSType. 492 These Route Records extend the abstract type RteRecType and 493 inherit the common attribute 'priority' that is meant for setting 494 precedence across the route records defined within a Route Group 495 in a protocol agnostic fashion. 497 o Organization: 498 An Organization is an entity that may fulfill any combination of 499 three roles: Registrant, Registrar, and Peering Organization. All 500 SPPP objects are associated with two organization identifiers to 501 identify each object's registrant and the registrar. A Route 502 Group object is also associated with a set of zero or more 503 organization identifiers that identify the peering organizations 504 whose query responses may include the routing information (SED) 505 defined in the Route Records within that Route Group. 507 4. Transport Protocol Requirements 509 This section provides requirements for transport protocols suitable 510 for SPPP. More specifically, this section specifies the services, 511 features, and assumptions that SPPP delegates to the chosen transport 512 and envelope technologies. 514 Two different groups of use cases are specified in 515 [I-D.ietf-drinks-usecases-requirements]. One group of use cases 516 describes the provisioning of data by a client into a Registry 517 (Section 3.1 of the above referenced document), while the other group 518 describes the distribution of data into local data repositories 519 (Section 3.2). The current version of this document focuses on the 520 first set of use cases (client to registry provisioning). 522 These use cases may involve the provisioning of very small data sets 523 like the modification or update of a single public identifier. Other 524 provisioning operations may deal with huge datasets like the 525 "download" of a whole local number portability database to a 526 Registry. 528 As a result, a transport protocol for SPPP must be very flexible and 529 accommodate various sizes of data set sizes. 531 For the reasons outlined above, it is conceivable that provisioning 532 and distributing may use different transport protocols. This 533 document focuses on the provisioning protocol. 535 4.1. Connection Oriented 537 The SPPP protocol follows a model where a Client establishes a 538 connection to a Server in order to further exchange provisioning 539 transactions over such point-to-point connection. A transport 540 protocol for SPPP MUST therefore be connection oriented. 542 Note that the role of the "Client" and the "Server" only applies to 543 the connection, and those roles are not related in any way to the 544 type of entity that participates in a protocol exchange. For 545 example, a Registry might also include a "Client" when such a 546 Registry initiates a connection (for example, for data distribution 547 to SSP). 549 4.2. Request and Response Model 551 Provisioning operations in SPPP follow the request - response model, 552 where a transaction is initiated by a Client using a Request command, 553 and the Server responds to the Client by means of a Response. 555 Multiple subsequent request-response exchanges MAY be performed over 556 a single connection. 558 Therefore, a transport protocol for SPPP MUST follow the request- 559 response model by allowing a response to be sent to the request 560 initiator. 562 4.3. Connection Lifetime 564 Some use cases involve provisioning a single request to a network 565 element - connections supporting such provisioning requests might be 566 short-lived, and only established on demand. 568 Other use cases involve either provisioning a huge set of data, or a 569 constant stream of small updates, which would require long-lived 570 connections. 572 Therefore, a protocol suitable for SPPP SHOULD support short lived as 573 well as long lived connections. 575 4.4. Authentication 577 Many use cases require the Server to authenticate the Client, and 578 potentially also the Client to authenticate the Server. While 579 authentication of the Server by the Client is expected to be used 580 only to prevent impersonation of the Server, authentication of the 581 Client by the Server is expected to be used to identify and further 582 authorize the Client to certain resources on the Server. 584 Therefore, an SPPP transport protocol MUST provide means for a Server 585 to authenticate and authorize a Client, and MAY provide means for 586 Clients to authenticate a Server. 588 4.5. Confidentiality and Integrity 590 Data that is transported over the protocol is deemed confidential. 591 Therefore, a transport protocol suitable for SPPP MUST ensure 592 confidentiality and integrity protection by providing encryption 593 capabilities. 595 Additionally, a DRINKS protocol MUST NOT use an unreliable lower- 596 layer transport protocol that does not provide confidentiality and 597 integrity protection. 599 4.6. Near Real Time 601 Many use cases require near real-time responses from the Server. 602 Therefore, a DRINKS transport protocol MUST support near-real-time 603 response to requests submitted by the Client. 605 4.7. Request and Response Sizes 607 SPPP covers a range of use cases - from cases where provisioning a 608 single public identifier will create very small request and response 609 sizes to cases where millions of data records are submitted or 610 retrieved in one transaction. Therefore, a transport protocol 611 suitable for SPPP MUST support a great variety of request and 612 response sizes. 614 A transport protocol MAY allow splitting large chunks of data into 615 several smaller chunks. 617 4.8. Request and Response Correlation 619 A transport protocol suitable for SPPP MUST allow responses to be 620 correlated with requests. 622 4.9. Request Acknowledgement 624 Data transported in the SPPP protocol is likely crucial for the 625 operation of the communication network that is being provisioned. 627 Failed transactions can lead to situations where a subset of public 628 identifiers (or even SSPs) might not be reachable, or situations 629 where the provisioning state of the network is inconsistent. 631 Therefore, a transport protocol for SPPP MUST provide a Response for 632 each Request, so that a Client can identify whether a Request 633 succeeded or failed. 635 4.10. Mandatory Transport 637 As of this writing of this revision, one transport protocol proposal 638 has been provided in [I-D.ietf-drinks-sppp-over-soap]. 640 This section will define a mandatory transport protocol to be 641 compliant with this RFC. 643 5. Base Protocol Data Structures 645 SPPP uses a common model and a common set of data structures for most 646 of the supported operations and object types. This section describes 647 these common data structures. 649 5.1. Request and Response Structures 651 An SPPP client interacts with an SPPP server by using one of the 652 supported transport mechanisms to send one or more requests to the 653 server and receive corresponding replies from the server. There are 654 two generalized types of operations that an SPPP client can submit to 655 an SPPP server, updates and queries. The following two sub-sections 656 describe the generalized data structures that are used for each of 657 these two types of operations. 659 5.1.1. Update Request and Response Structures 661 An SPPP update request is wrapped within the 662 element while an SPPP update response is wrapped within an 663 element. The following two sub-sections 664 describe these two elements. 666 5.1.1.1. Update Request 668 An SPPP update request object is contained within the generic 669 element. 671 672 673 674 676 678 680 681 682 684 685 686 687 688 689 691 The data elements within the element are 692 described as follows: 694 o clientTransId: Zero or one client generated transaction ID that, 695 within the context of the SPPP client, identifies this request. 696 This value can be used at the discretion of the SPPP client to 697 track, log or correlate requests and their responses. This 698 value is also echoed back to the client in the SPPP update 699 response. An SPPP server will not check this value for 700 uniqueness. 702 o minorVer: Zero or one minor version identifier, indicating the 703 minor version of the SPPP API that the client is attempting to 704 use. This is used in conjunction with the major version 705 identifier in the XML namespace to identify the version of SPPP 706 that the client is using. If the element is not present, the 707 server assumes that the client is using the latest minor version 708 supported by the SPPP server for the given major version. The 709 versions supported by a given SPPP server can be retrieved by 710 the client using the SPPP server menu operation described later 711 in the document. 713 o rqst: One or more BasicRqstType objects. These are the actions 714 that the client is requesting the SPPP server perform. They are 715 processed by the SPPP server in the order in which they are 716 included in the request. And with respect to handling error 717 conditions, it is a matter of policy whether the objects are 718 processed in a "stop and rollback" fashion or in a "stop and 719 commit" fashion. In the "stop and rollback" scenario, the SPPP 720 server would stop processing BasicRqstType object instances in 721 the request at the first error and roll back any BasicRqstType 722 object instances that had already been processed for that update 723 request. In the "stop and commit" scenario the SPPP server 724 would stop processing BasicRqstType object instances in the 725 request at the first error but commit any BasicRqstType object 726 instances that had already been processed for that update 727 request. 729 All update request objects extend the base type BasicRqstType. This 730 base type is defined as follows: 732 733 734 735 736 738 The BasicRqstType object primarily acts as an abstract base type, and 739 its only data element is described as follows: 741 o ext: This is the standard extension element for this object. 742 Refer to the Extensibility section of this document for more 743 details. 745 5.1.1.2. Update Response 747 An SPPP update response object is contained within the generic 748 element. 750 751 752 753 754 756 758 759 760 761 763 764 765 766 767 768 770 771 772 773 774 775 776 778 779 781 An contains the elements necessary for the SPPP 782 client to precisely determine the overal result of the request, and 783 if an error occurred, it provides information about the specific 784 object, data element, or condition caused the error. 786 The data elements within the SPPP update response are described as 787 follows: 789 o clientTransId: Zero or one client transaction ID. This value is 790 simply an echo of the client transaction ID that SPPP client 791 passed into the SPPP update request. 793 o serverTransId: Exactly one server transaction ID that identifies 794 this request for tracking purposes. This value is guaranteed to 795 be unique for a given SPPP server. 797 o overallResult: Exactly one response code and message pair that 798 explicitly identifies the result of the request. See the 799 Response Code section for further details. 801 o rqstObjResult: An optional response code, response message, and 802 BasicRqstObject triplet. This element will be present only if 803 an object level error condition occurs, and indicates exactly 804 which error condition occurred and exactly which request object 805 that was passed in caused the error condition. The contained 806 BasicRqstObject is simply an echo of the request object instance 807 that caused the error, while the response code and message 808 indicate the error condition for this object. See the Response 809 Code section for further details. 811 o ext: This is the standard extension element for this object. 812 Refer to the Extensibility section for more details. 814 5.1.2. Query Request and Response Structures 816 An SPPP query request is wrapped within the 817 element while an SPPP query response is wrapped within an 818 element. The following two sub-sections describe 819 these two element structures. 821 5.1.2.1. Query Request 823 An SPPP query request object is contained within the generic 824 element. 826 827 828 829 831 832 833 834 836 The data elements within the element are described 837 as follows: 839 o minorVer: Zero or one minor version identifier, indicating the 840 minor version of the SPPP API that the client is attempting to 841 use. This is used in conjunction with the major version 842 identifier in the XML namespace to identify the version of SPPP 843 that the client is using. If the element is not present, the 844 server assumes that the client is using the latest minor version 845 supported by the SPPP server for the given major version. The 846 versions supported by a given SPPP server can be retrieved by 847 the client using the SPPP server menu operation described later 848 in the document. 850 o rqst: One BasicQueryRqstType objects. This is the query that 851 the client is requesting the SPPP server perform. 853 All query request objects extend the base type BasicQueryRqstType. 854 This base type is defined as follows: 856 857 858 859 860 862 The BasicQueryRqstType object primarily acts as an abstract base 863 type, and its only data element is described as follows: 865 o ext: This is the standard extension element for this object. 866 Refer to the Extensibility section of this document for more 867 details. 869 5.1.2.2. Query Response 871 An SPPP query response object is contained within the generic 872 element. 874 875 876 877 878 880 881 882 884 An contains the elements necessary for the SPPP 885 client to precisely determine the overal result of the query, and if 886 an error occurred, exactly what condition caused the error. 888 The data elements within the SPPP query response are described as 889 follows: 891 o overallResult: Exactly one response code and message pair that 892 explicitly identifies the result of the request. See the 893 Response Code section for further details. 895 o resultSet: The set of zero or more objects that matched the 896 query criteria. If no objects matched the query criteria then 897 this result set MUST be empty and the overallResult value MUST 898 indicate success (if no matches are found for the query 899 criteria, the response is considered a success). 901 5.2. Response Codes and Messages 903 This section contains the listing of response codes and their 904 corresponding human-readable text. 906 The response code numbering scheme generally adheres to the theory 907 formalized in section 4.2.1 of [RFC5321]: 909 o The first digit of the response code can only be 1 or 2: 1 = a 910 positive result, 2 = a negative result. 912 o The second digit of the response code indicates the category: 0 913 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 914 = Security, 3 = Server System. 916 o The third and fourth digits of the response code indicate the 917 individual message event within the category defines by the 918 first two digits. 920 The response codes are also categorized as to whether they are 921 overall response codes that may only be returned in the 922 "overallResult" data element in SPPP responses, of object level 923 response codes that may only be returned in the "rqstObjResult" 924 element of the SPPP responses. 926 +--------+--------------------------+-------------------------------+ 927 | Result | Text | Overall or Object Level | 928 | Code | | | 929 +--------+--------------------------+-------------------------------+ 930 | 1000 | Request Succeeded. | Overall Response Code | 931 | | | | 932 | 2001 | Request syntax invalid. | Overall Response Code | 933 | | | | 934 | 2002 | Request too large. | Overall Response Code | 935 | | | | 936 | 2003 | Version not supported. | Overall Response Code | 937 | | | | 938 | 2103 | Command invalid. | Overall Response Code | 939 | | | | 940 | 2301 | System temporarily | Overall Response Code | 941 | | unavailable. | | 942 | | | | 943 | 2302 | Unexpected internal | Overall Response Code | 944 | | system or server error. | | 945 | | | | 946 | 2104 | Attribute value invalid. | Object Level Response Code | 947 | | | | 948 | | AttrName:[AttributeName] | | 949 | | AttrVal:[AttributeValue] | | 950 | | | | 951 | 2105 | Object does not exist. | Object Level Response Code | 952 | | AttrName:[AttributeName] | | 953 | | AttrVal:[AttributeValue] | | 954 | | | | 955 | 2106 | Object status or | Object Level Response Code | 956 | | ownership does not allow | | 957 | | for operation. | | 958 | | AttrName:[AttributeName] | | 959 | | AttrVal:[AttributeValue] | | 960 +--------+--------------------------+-------------------------------+ 962 Table 1: Response Codes Numbering Scheme and Messages 964 Each of the object level response messages are "parameterized" with 965 the following parameters: "AttributeName" and "AttributeValue". 967 The use of these parameters MUST adhere to the following rules: 969 o All parameters within a response message are mandatory and MUST 970 be present. 972 o Any value provided for the "AttributeName" parameter MUST be an 973 exact XSD element name of the protocol data element that the 974 response message is referring to. For example, valid values for 975 "attribute name" are "dgName", "rgName", "rteRec", etc. 977 o The value for "AttributeValue" MUST be the value of the data 978 element to which the preceding "AttributeName" refers. 980 o Result code 2104 SHOULD be used whenever an element value does 981 not adhere to data validation rules. 983 o Result codes 2104 and 2105 MUST NOT be used interchangeably. 984 Response code 2105 SHOULD be returned by an update operation 985 when the data element(s) used to uniquely identify a pre- 986 existing object do not exist. If the data elements used to 987 uniquely identify an object are malformed, then response code 988 2104 SHOULD be returned. 990 5.3. Basic Object Type and Organization Identifiers 992 This section introduces the basic object type that most first class 993 objects derive from. 995 All first class objects extend the basic object type BasicObjType 996 which contains the identifier of the registrant organization that 997 owns this object, the identifier of the registrar organization that 998 provisioned this object, the date and time that the object was 999 created by the server, and the date and time that the object was last 1000 modified. 1002 1003 1004 1005 1006 1007 1008 1009 1010 1012 The identifiers used for registrants (rant), registrars (rar) and 1013 peering organizations (peeringOrg) are instances of OrgIdType. The 1014 OrgIdType is defined as a string and all OrgIdType instances SHOULD 1015 follow the textual convention: "namespace:value" (for example "iana- 1016 en:32473"). See the IANA Consideration section for more details. 1018 6. Protocol Commands 1020 This section provides a description of each supported protocol 1021 command. 1023 6.1. Add Route Group Operation 1025 As described in the introductory sections, a Route Group represents a 1026 combined grouping of Route Records that define route information, 1027 Destination Groups that contain a set of Public Identifiers with 1028 common routing information, and the list of peer organizations that 1029 have access to these public identifiers using this route information. 1030 It is this indirect linking of public identifiers to their route 1031 information that significantly improves the scalability and 1032 manageability of the peering data. Additions and changes to routing 1033 information are reduced to a single operation on a Route Group or 1034 Route Record , rather than millions of data updates to individual 1035 public identifier records that individually contain their peering 1036 data. 1038 The AddRteGrpRqstType operation creates or overwrites a Route Group 1039 object. If a Route Group with the given name and registrant ID 1040 (which together comprise the unique key or a Route Group) does not 1041 exist, then the server MUST create the Route Group. If a Route Group 1042 with the given name and registrant ID does exist, then the server 1043 MUST replace the current properties of the Route Group with the 1044 properties passed into the AddRteGrpRqstType operation. The XSD 1045 declarations of the AddRteGrpRqstType operation request object are as 1046 follows: 1048 1049 1050 1051 1052 1053 1054 1055 1056 1058 The element passed into the spppUpdateRequest element for this 1059 operation is an instance of AddRteGrpRqstType, which extends 1060 BasicRqstType and contains one RteGrpType object. The RteGrpType 1061 object structure is defined as follows: 1063 1064 1065 1066 1067 1068 1070 1072 1074 1076 1077 1078 1079 1080 1081 1082 1084 1085 1086 1087 1088 1089 1090 1092 The RteGrpType object is composed of the following elements: 1094 o base: All first class objects extend BasicObjType which contains 1095 the ID of the registrant organization that owns this object, the 1096 ID of the registrar organization that provisioned this object, 1097 the date and time that the object was created by the server, and 1098 the date and time that the object was last modified. If the 1099 client passes in either the created date or the modification 1100 date, the server will ignore them. The server sets these two 1101 date/time values. 1103 o rgName: The character string that contains the name of the Route 1104 Group. It uniquely identifies this object within the context of 1105 the registrant ID (a child element of the base element as 1106 described above). 1108 o rrRef: Set of zero or more objects of type RteRecRefType that 1109 house the unique keys of the Route Records that the RteGrpType 1110 object refers to and their relative priority within the context 1111 of a given route group. The associated Route Records contain 1112 the routing information, sometimes called SED, associated with 1113 this Route Group. 1115 o dgName: Set of zero or more names of DestGrpType object 1116 instances. Each dgName name, in association with this Route 1117 Group's registrant ID, uniquely identifies a DestGrpType object 1118 instance whose public identifiers are reachable using the 1119 routing information housed in this Route Group. An intended 1120 side affect of this is that a Route Group cannot provide routing 1121 information for a Destination Group belonging to another 1122 registrant. 1124 o peeringOrg: Set of zero or more peering organization IDs that 1125 have accepted an offer to receive this Route Group's 1126 information. The set of peering organizations in this list is 1127 not directly settable or modifiable using the addRteGrpsRqst 1128 operation. This set is instead controlled using the route offer 1129 and accept operations. 1131 o sourceIdent: Set of zero or more SourceIdentType object 1132 instances. These objects, described further below, house the 1133 source identification schemes and identifiers that are applied 1134 at resolution time as part of source based routing algorithms 1135 for the Route Group. 1137 o isInSvc: A boolean element that defines whether this Route Group 1138 is in service. The routing information contained in a Route 1139 Group that is in service is a candidate for inclusion in 1140 resolution responses for public identities residing in the 1141 Destination Group associated with this Route Group. The routing 1142 information contained in a Route Group that is not in service is 1143 not a candidate for inclusion in resolution responses. 1145 o priority: Zero or one priority value that can be used to provide 1146 a relative value weighting of one Route Group over another. The 1147 manner in which this value is used, perhaps in conjunction with 1148 other factors, is a matter of policy. 1150 o ext: Point of extensibility described in a previous section of 1151 this document. 1153 As described above, the Route Group contains a set of references to 1154 route record objects. A route record object is based on an abstract 1155 type: RteRecType. The concrete types that use RteRecType as an 1156 extension base are NAPTRType, NSType, and URIType. The definitions 1157 of these types are included the Route Record section of this 1158 document. 1160 The RteGrpType object provides support for source-based routing via 1161 the peeringOrg data element and more granular source base routing via 1162 the source identity element. The source identity element provides 1163 the ability to specify zero or more of the following in association 1164 with a given Route Group: a regular expression that is matched 1165 against the resolution client IP address, a regular expression that 1166 is matched against the root domain name(s), and/or a regular 1167 expression that is matched against the calling party URI(s). The 1168 result will be that, after identifying the visible Route Groups whose 1169 associated Destination Group(s) contain the lookup key being queried 1170 and whose peeringOrg list contains the querying organizations 1171 organization ID, the resolution server will evaluate the 1172 characteristics of the Source URI, and Source IP address, and root 1173 domain of the lookup key being queried. The resolution server then 1174 compares these criteria against the source identity criteria 1175 associated with the Route Groups. The routing information contained 1176 in Route Groups that have source based routing criteria will only be 1177 included in the resolution response if one or more of the criteria 1178 matches the source criteria from the resolution request. The Source 1179 Identity data element is of type SourceIdentType, whose structure is 1180 defined as follows: 1182 1183 1184 1185 1187 1188 1189 1191 1192 1193 1194 1195 1196 1197 1199 The SourceIdentType object is composed of the following data 1200 elements: 1202 o sourceIdentScheme: The source identification scheme that this 1203 source identification criteria applies to and that the 1204 associated sourceIdentRegex should be matched against. 1206 o sourceIdentRegex: The regular expression that should be used to 1207 test for a match against the portion of the resolution request 1208 that is dictated by the associated sourceIdentScheme. 1210 o ext: Point of extensibility described in a previous section of 1211 this document. 1213 As with the responses to all update operations, the result of the 1214 AddRteGrpRqstType operation is contained in the generic 1215 spppUpdateResponse data structure described in an earlier sections of 1216 this document. For a detailed description of the spppUpdateResponse 1217 data structure refer to that section of the document. 1219 6.2. Get Route Groups Operation 1221 The getRteGrpsRqst operation allows a client to get the properties of 1222 Route Group objects that a registrar organization is authorized to 1223 view. The server will attempt to find a Route Group object that has 1224 the registrant ID and route group name pair contained in each 1225 ObjKeyType object instance. If the set of ObjKeyType objects is 1226 empty then the server will return the list of Route Group objects 1227 that the querying client has the authority to view. If there are no 1228 matching Route Groups found then an empty result set will be 1229 returned. 1231 The element passed into the spppQueryRequest element for this 1232 operation is an instance of type GetRteGrpsRqstType, which extends 1233 BasicRqstType and contains zero or more ObjKeyType objects. Any 1234 limitation on the maximum number of objects that may be passed into 1235 or returned by this operation is a policy decision and not limited by 1236 the protocol. The XSD declaration of the operation is as follows: 1238 1239 1240 1241 1242 1244 1245 1246 1247 1249 As described in an earlier section of this document, the result of 1250 any spppQueryRequest operation is an spppQueryResponse element that 1251 contains the overall response code and the query result set, if any. 1252 Refer to that section of the document for a detailed description of 1253 the spppQueryResponse element. 1255 6.3. Add Destination Group Operation 1257 As described in the introductory sections, a Destination Group 1258 represents a set of Public Identifiers with common routing 1259 information. 1261 The AddDestGrpRqstType operation creates or overwrites a Destination 1262 Group object. If a Destination Group with the given name and 1263 registrant ID (which together comprise the unique key for a 1264 Destination Group) does not exist, then the server MUST create the 1265 Destination Group. If a Destination Group with the given name and 1266 registrant ID does exist, then the server MUST replace the current 1267 properties of the Destination Group with the properties passed into 1268 the AddDestGrpsRqstType operation. The XSD declarations of the 1269 operation request object are as follows: 1271 1272 1273 1274 1275 1276 1277 1278 1279 1281 The element passed into the spppUpdateRequest element for this 1282 operation is an element of type AddDestGrpRqsttype, which extends 1283 BasicRqstType and contains a DestGrpType object. The DestGrpType 1284 object structure is defined as follows: 1286 1287 1288 1289 1290 1291 1292 1293 1294 1296 The DestGrpType object is composed of the following elements: 1298 o base: All first class objects extend BasicObjType which contains 1299 the ID of the registrant organization that owns this object, the 1300 ID of the registrar organization that provisioned this object, 1301 the date and time that the object was created by the server, and 1302 the date and time that the object was last modified. If the 1303 client passed in either the created date or the modification 1304 date, the server will ignore them. The server sets these two 1305 date/time values. 1307 o dgName: The character string that contains the name of the 1308 Destination Group. This uniquely identifies this object within 1309 the context of the registrant ID (a child element of the base 1310 element as described above). 1312 o ext: Point of extensibility described in a previous section of 1313 this document. 1315 As with the responses to all update operations, the result of the 1316 AddDestGrpRqstType operation is contained in the generic 1317 spppUpdateResponse data structure described in an earlier sections of 1318 this document. For a detailed description of the spppUpdateResponse 1319 data structure refer to that section of the document. 1321 6.4. Get Destination Groups Operation 1323 The getDestGrpsRqst operation allows a client to get the properties 1324 of Destination Group objects that a registrar organization is 1325 authorized to view. The server will attempt to find a Destination 1326 Group object that has the registrant ID and destination group name 1327 pair contained in each ObjKeyType object instance. If there are no 1328 matching Destination Groups found then an empty result set will be 1329 returned. If the set of ObjKeyType objects passed in is empty then 1330 the server will return the list of Destination Group objects that the 1331 querying registrar has the authority to view. 1333 The element passed into the spppQueryRequest element for this 1334 operation is an instance of type GetDestGrpsRqstType, which extends 1335 BasicQueryRqstType and contains zero or more ObjKeyType objects. Any 1336 limitation on the maximum number of objects that may be passed into 1337 or returned by this operation is a policy decision and not limited by 1338 the protocol. The XSD declaration of the operation is as follows: 1340 1341 1342 1343 1344 1346 1347 1348 1349 1351 As described in an earlier section of this document, the result of 1352 any spppQueryRequest operation is an spppQueryResponse element that 1353 contains the overall response code and the query result set, if any. 1354 Refer to that section of the document for a detailed description of 1355 the spppQueryResponse element. 1357 6.5. Add Route Group Offer Operation 1359 The list of peer organizations whose resolution responses can include 1360 the routing information contained in a given Route Group is 1361 controlled by the organization to which a Route Group object belongs 1362 (its registrant), and the peer organization that submits resolution 1363 requests (a data recipient, also know as a peering organization). 1364 The registrant offers access to a Route Group by submitting a Route 1365 Group Offer. The data recipient can then accept or reject that 1366 offer. Not until access to a Route Group has been offered and 1367 accepted will the data recipient's organization ID be included in the 1368 peeringOrg list in a Route Group object, and that Route Group's 1369 peering information become a candidate for inclusion in the responses 1370 to the resolution requests submitted by that data recipient. The 1371 AddRteGrpOffersRqstType operation creates or overwrites one or more 1372 Route Group Offer objects. If a Route Group Offer for the given 1373 Route Group object key and the offeredTo Org ID does not exist, then 1374 the server creates the Route Group Offer object. If a such a Route 1375 Group Offer does exist, then the server replaces the current object 1376 with the new object. The XSD declarations of the operation request 1377 object are as follows: 1379 1380 1381 1382 1383 1384 1385 1386 1387 1389 The element passed into the spppUpdateRequest element for this 1390 operation is an instance of AddRteGrpOfferRqstType, which extends 1391 BasicRqstType and contains a RteGrpOfferType object. The XSD 1392 declaration of the RteGrpOfferType is as follows: 1394 1395 1396 1397 1398 1400 1401 1402 1403 1404 1405 1406 1407 1409 1410 1411 1412 1413 1414 1416 1417 1418 1419 1420 1421 1422 The RteGrpOfferType object is composed of the following elements: 1424 o base: All first class objects extend BasicObjType which contains 1425 the ID of the registrant organization that owns this object, the 1426 ID of the registrar organization that provisioned this object, 1427 the date and time that the object was created by the server, and 1428 the date and time that the object was last modified. If the 1429 client passed in either the created date or the modification 1430 date, the will ignore them. The server sets these two date/time 1431 values. 1433 o rteGrpOfferKey: The object that identifies the route that is or 1434 has been offered and the organization that it is or has been 1435 offered to. The combination of these three data elements 1436 uniquely identify a Route Group Offer. 1438 o status: The status of the offer, offered or accepted. This 1439 status is controlled by the server. It is automatically set to 1440 "offered" when ever a new Route Group Offer is added, and is 1441 automatically set to "accepted" if and when that offer is 1442 accepted. The value of the element is ignored when passed in by 1443 the client. 1445 o offerDateTime: Date and time in GMT when the Route Group Offer 1446 was added. 1448 o acceptDateTime: Date and time in GMT when the Route Group Offer 1449 was accepted. 1451 As with the responses to all update operations, the result of the 1452 AddRteGrpOfferRqstType operation is contained in the generic 1453 spppUpdateResponse data structure described in an earlier sections of 1454 this document. For a detailed description of the spppUpdateResponse 1455 data structure refer to that section of the document. 1457 6.6. Accept Route Group Offer Operation 1459 Not until access to a Route Group has been offered and accepted will 1460 the data recipient's organization ID will it be included in the 1461 peeringOrg list in that Route Group object, and that Route Group's 1462 peering information become a candidate for inclusion in the responses 1463 to the resolution requests submitted by that data recipient. The 1464 AcceptRteGrpOffersRqstType operation is called by, or on behalf of, 1465 the data recipient to accept a Route Group Offer that is pending in 1466 the "offered" status for the data recipient's organization ID. If a 1467 Route Group Offer for the given Route Group Offer key (route name, 1468 route registrant ID, data recipient's organization ID) exists, then 1469 the server moves the Route Group Offer to the "accepted" status and 1470 adds that data recipient's organization ID into the list of 1471 peerOrgIds for that Route Group. If a such a Route Group Offer does 1472 not exist, then the server returns the appropriate error code, 2105. 1473 The XSD declarations for the operation request object are as follows: 1475 1476 1477 1478 1479 1480 1481 1482 1483 1485 The element passed into the spppUpdateRequest element for this 1486 operation is an instance of AcceptRteGrpOffersRqstType, which extends 1487 BasicRqstType and contains a RteGrpOfferKeyType object. 1489 As with the responses to all update operations, the result of the 1490 AcceptRteGrpOfferRqstType operation is contained in the generic 1491 spppUpdateResponse data structure described in an earlier sections of 1492 this document. For a detailed description of the spppUpdateResponse 1493 data structure refer to that section of the document. 1495 6.7. Reject Route Group Offer Operation 1497 The data recipient to which a Route Group has been offered has the 1498 option of rejecting a Route Group Offer. Furthermore, that offer may 1499 be rejected, regardless of whether or not it has been previously 1500 accepted. The RejectRteGrpOffersRqstType operation is used for these 1501 purposes and is called by, or on behalf of, the data recipient to 1502 accept a Route Group Offer that is pending in the "offered" status or 1503 is in the "accepted" status for the data recipient's organization ID. 1504 If a Route Group Offer for the given Route Group Offer key (route 1505 name, route registrant ID, data recipient's organization ID) exists 1506 in either the offered or accepted status, then the server deletes 1507 that Route Group Offer object, and, if appropriate, removes the data 1508 recipients organization ID from the list of peeringOrg IDs for that 1509 Route Group. If the Route Group Offer does not exist, then the 1510 server returns the appropriate error code, 2105. The XSD 1511 declarations for the operation request object are as follows: 1513 1514 1515 1516 1517 1518 1519 1520 1521 1523 The element passed into the spppUpdateRequest element for this 1524 operation is an instance of RejectRteGrpOffersRqstType, which extends 1525 BasicRqstType and contains a RteGrpOfferKeyType object. 1527 As with the responses to all update operations, the result of the 1528 RejectRteGrpOfferRqstType operation is contained in the generic 1529 spppUpdateResponse data structure described in an earlier sections of 1530 this document. For a detailed description of the spppUpdateResponse 1531 data structure refer to that section of the document. 1533 6.8. Get Route Group Offers Operation 1535 The getRteGrpOffersRqst operation allows a client to get the 1536 properties of zero or more Route Group Offer objects that registrar 1537 is authorized to view. The server will attempt to find Route Group 1538 Offer objects that have all the properties specified in the criteria 1539 passed into the operation. If no criteria is passed in then the 1540 server will return the list of Route Group Offer objects that the 1541 querying client has the authority to view. If there are no matching 1542 Route Group Offers found then an empty result set will be returned. 1544 The element passed into the spppQueryRequest element for this 1545 operation is an instance of GetRteGrpOffersRqstType, which extends 1546 BasicQueryRqstType and contains the criteria that the returned Route 1547 Group Offer objects must match. Any limitation on the maximum number 1548 of objects that may be returned by this operation is a policy 1549 decision and not limited by the protocol. The XSD declaration of the 1550 operation is as follows: 1552 1553 1554 1555 1556 1558 1560 1562 1565 1566 1567 1568 1570 The GetRteGrpOffersRqstType object is composed of the following 1571 elements: 1573 o offeredBy: Zero or more organization IDs. Only offers that are 1574 offered to the organization IDs in this list should be included 1575 in the result set. The result set is also subject to other 1576 query criteria in the request. 1578 o offeredTo: Zero or more organization IDs. Only offers that are 1579 offered by the organization IDs in this list should be included 1580 in the result set. The result set is also subject to other 1581 query criteria in the request. 1583 o status: The status of the offer, offered or accepted. Only 1584 offers in the specified status should be included in the result 1585 set. If this element is not present then the status of the 1586 offer should not be considered in the query. The result set is 1587 also subject to other query criteria in the request. 1589 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only 1590 offers having one of these keys should be included in the result 1591 set. The result set is also subject to other query criteria in 1592 the request. 1594 As described in an earlier section of this document, the result of 1595 any spppQueryRequest operation is an spppQueryResponse element that 1596 contains the overall response code and the query result set, if any. 1597 Refer to that section of the document for a detailed description of 1598 the spppQueryResponse element. 1600 6.9. Public Identifier Operations 1602 Public Identifier is the search key used for locating the session 1603 establishment data (SED). In many cases, a Public Identifier is 1604 attributed to the end user who has a retail relationship with the 1605 service provider or registrant organization. In SPPP, SED can be 1606 provisioned by the registrant, or by the registrar on behalf of the 1607 registrant. Also, SPPP supports the notion of the carrier-of-record 1608 as defined in RFC 5067. Therefore, the entity adding the Public 1609 Identity in the Registry can optionally claim to be a carrier-of- 1610 record. 1612 SPPP identifies three types of Public Identifiers: telephone number 1613 (TN), and the routing number (RN). SPPP provides structures to 1614 manage a single TN, a contiguous range of TNs, and a TN prefix. 1616 The XML schema type definition PubIDType is the generalization of the 1617 Public Identifier. PubIDType is an abstract type. In agreement with 1618 the data model, PubIDType member 'dgName' represents the name of the 1619 destination group that a given Public Identifier is associated to. 1620 The PubIDType object structure is defined as follows: 1622 1623 1624 1625 1626 1627 1628 1629 1630 1632 A registrant can add a Public Identifier with the help of a 1633 BasicRqstType called AddPubIdRqstType. To complete the add request, 1634 AddPubIdRqstType XML instance is added to root 1635 element. If there is a conflict and a Public Identifier already 1636 exists in the Registry, the old entry will be replaced with the newly 1637 provisioned entry. For the add or update operation, the destination 1638 group name is a mandatory parameter. Not including a valid 1639 destination group name in the update request will cause the Registry 1640 to return an appropriate error. 1642 Telephone number is identified by TNType, an extension of PubIDType. 1643 Schema definition of TNType is as follows: 1645 1646 1647 1648 1649 1650 1652 1654 1655 1656 1657 1659 TNType consists of the following attributes: 1661 o tn: Telephone number to be added to the Registry. 1663 o rrRef: Optional reference to the route record that is directly 1664 associated with the TN Public Identifier. Following the SPPP 1665 data model, the route record could be a protocol agnostic 1666 URIType or another type. 1668 o corInfo: corInfo is an optional parameter of type CORInfoType 1669 that allows the registrant organization to set forth a claim to 1670 be the carrier-of-record [see RFC 5067]. This is done by 1671 setting the value of element of the CORInfoType 1672 object structure to "true". The other two parameters of the 1673 CORInfoType, and are set by the Registry to 1674 describe the outcome of the carrier-of-record claim by the 1675 registrant. In general, inclusion of parameter is 1676 useful if the Registry has the authority information, such as, 1677 the number portability data, etc., in order to qualify whether 1678 the registrant claim can be satisfied. If the carrier-of-record 1679 claim disagrees with the authority data in the Registry, whether 1680 the TN add operation fails or not is a matter of policy and it 1681 is beyond the scope of this document. In the response message 1682 , the SPPP Server must include the 1683 parameter of the element to let the registrant know 1684 the outcome of the claim. 1686 Routing number is identified by RNType. SSPs that possess the number 1687 portability data may be able to leverage the RN search key to 1688 discover the ingress routes for session establishment. Therefore, 1689 the registrant organization can add the RN and associate it with the 1690 appropriate destination group to share the route information. RNType 1691 is defined as follows: 1693 1694 1695 1696 1697 1698 1700 1701 1702 1703 1705 RNType has the following attributes: 1707 o rn: Routing Number used as the search key 1709 o corInfo: Optional element of type CORInfoType. 1711 TNRType structure is used to add contiguous range of TNs. The object 1712 definition requires a starting TN and the ending TN that describes 1713 the TN range. In addition, TNRType includes an optional "prefix" 1714 attribute to indicate that the given TN range qualifies for the Open 1715 Number Plan (ONP). In order for the resolution server to correctly 1716 respond to the queries for TNs in the TNRType object, the Registry 1717 and/or the resolution server will need the national significant 1718 number length data for the TN blocks included in the TNRType object. 1719 Further, is transactional in nature, therefore, 1720 if the Registry encounters an error in adding even a single TN that 1721 is included in the TNRType object, the whole request will be deemed a 1722 failure. In other words, the partial success case is not supported. 1723 TNPType object structure is as follows: 1725 1726 1727 1728 1729 1730 1731 1733 1734 1735 1736 1737 1739 1741 TNRType has the following attributes: 1743 o startTn: Starting TN in the TN range 1745 o endTn: The last TN in the TN range 1747 o corInfo: Optional element of type CORInfoType 1749 o prefix: Optional attribute, when set to "true", indicates that 1750 the Open Number Plan applies to a given TN Range 1752 In some cases, it is useful to describe a set of TNs with the help of 1753 the first few digits of the telephone number, also referred to as the 1754 telephone number prefix or a block. In SPPP, the TNPType structure 1755 is reserved for use of TN prefix as defined below: 1757 1758 1759 1760 1761 1762 1764 1765 1766 1767 1769 TNPType consists of the following attributes: 1771 o tnPrefix: The telephone number prefix 1773 o corInfo: Optional element of type CORInfoType. 1775 The object structure of AddPubIdRqstType used to add Public 1776 Identifiers is as follows 1777 1778 1779 1780 1781 1782 1783 1784 1785 1787 The SPPP client can use the GetPubIdsRqstType in the 1788 structure to obtain information about one or more 1789 valid objects. If the GetPubIdsRqstType object does not include 1790 data, then all applicable Public Identity data will be returned 1791 in the response message. If no matching Public Identifiers are 1792 found, then an empty result set is returned. 1794 GetPubIdsRqstType object structure is as follows: 1796 1797 1798 1799 1800 1802 1803 1804 1805 1807 As described earlier in the document, the result of any 1808 spppQueryRequest operation is a spppQueryResponse that contains the 1809 response code and the query result set, if any. 1811 6.10. Egress Route Operations 1813 In a high-availability environment, the originating SSP likely has 1814 more than one egress paths to the ingress SBE of the target SSP. If 1815 the originating SSP wants to exercise greater control and choose a 1816 specific egress SBE to be associated to the target ingress SBE, it 1817 can do so using the AddEgrRteRqstType object. 1819 Lets assume that the target SSP has offered to share one or more 1820 ingress route information and that the originating SSP has accepted 1821 the offer. In order to add the egress route to the Registry, the 1822 originating SSP uses a valid regular expression to rewrite ingress 1823 route in order to include the egress SBE information. Also, more 1824 than one egress route can be associated with a given ingress route in 1825 support of fault-tolerant configurations. The supporting SPPP 1826 protocol structure provides a way to include route precedence 1827 information to help manage traffic to more than one outbound egress 1828 SBE. 1830 An egress route is identified by type EgrRteType and its object 1831 structure is shown below: 1833 1834 1835 1836 1837 1838 1839 1840 1842 1843 1844 1845 1846 1848 The EgrRteType object is composed of the following elements: 1850 o base: All first class objects extend BasicObjType which contains 1851 the ID of the registrant organization that owns this object, the 1852 ID of the registrar organization that provisioned this object, 1853 the date and time that the object was created by the server, and 1854 the date and time that the object was last modified. If the 1855 client passes in either the created date or the modification 1856 date, the server will ignore them. The server sets these two 1857 date/time values. 1859 o egrRteName: The name of the egress route. 1861 o pref: The preference of this egress route relative to other 1862 egress routes that may get selected when responding to a 1863 resolution request. 1865 o regxRewriteRule: The regular expression re-write rule that 1866 should be applied to the regular expression of the ingress 1867 NAPTR(s) that belong to the ingress route. 1869 o ingrRteRec: The ingress route records that the egress route 1870 should be used for. 1872 o ext: Point of extensibility described in a previous section of 1873 this document. 1875 The AddEgrRteRqstType request is used to create or overwrite an 1876 egress route. 1878 1879 1880 1881 1882 1883 1884 1885 1886 1888 An instance of AddEgrRtesRqstType is added in the spppUpdateRequest 1889 element in order to send a valid request to the server. Any 1890 limitation on the maximum number of AddEgrRteRqstType instances is a 1891 matter of policy and is not limited by the specification. 1893 The response from the server is returned in addEgrRteRspns element, 1894 which is defined as the element of type BasicRspnsType. 1896 The GetEgrRtesRqstType is used by an authorized entity to fetch the 1897 well-known egress route data. 1899 1900 1901 1902 1903 1905 1906 1907 1909 1911 6.11. Add Route Record Operation 1913 As described in the introductory sections, a Route Group represents a 1914 combined grouping of Route Records that define route information. 1915 However, Route Records need not be created to just serve a single 1916 Route Group. Route Records can be created and managed to serve 1917 multiple Route Groups. As a result, a change to the properties of a 1918 network node, for example, that is used for multiple routes, would 1919 necessitate just a single update operation to change the properties 1920 of that node. The change would then be reflected in all the Route 1921 Groups whose route record set contains a reference to that node. 1923 The AddRteRecRqstType operation creates or overwrites a Route Record 1924 object. If a Route Record with the given name and registrant ID 1925 (which together comprise the unique key or a Route Record) does not 1926 exist, then the server MUST create the Route Record. If a Route 1927 Record with the given name and registrant ID does exist, then the 1928 server MUST replace the current properties of the Route Record with 1929 the properties passed into the AddRteRecRqstType operation. The XSD 1930 declarations of the AddRteRecRqstType operation request object are as 1931 follows: 1933 1934 1935 1936 1937 1938 1939 1940 1941 1943 The element passed into the spppUpdateRequest element for this 1944 operation is an instance of AddRteRecRqstType, which extends 1945 BasicRqstType and contains one RteRecType object. The RteRecType 1946 object structure is defined as follows: 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1959 The RteRecType object is composed of the following elements: 1961 o base: All first class objects extend BasicObjType which contains 1962 the ID of the registrant organization that owns this object, the 1963 ID of the registrar organization that provisioned this object, 1964 the date and time that the object was created by the server, and 1965 the date and time that the object was last modified. If the 1966 client passes in either the created date or the modification 1967 date, the server will ignore them. The server sets these two 1968 date/time values. 1970 o rrName: The character string that contains the name of the Route 1971 Record. It uniquely identifies this object within the context 1972 of the registrant ID (a child element of the base element as 1973 described above). 1975 o priority: Zero or one priority value that can be used to provide 1976 a relative value weighting of one Route Record over another. 1977 The manner in which this value is used, perhaps in conjunction 1978 with other factors, is a matter of policy. 1980 o ext: Point of extensibility described in a previous section of 1981 this document. 1983 As described above, route records are based on an abstract type: 1984 RteRecType. The concrete types that use RteRecType as an extension 1985 base are NAPTRType, NSType, and URIType. The definitions of these 1986 types are included below. The NAPTRType object is comprised of the 1987 data elements necessary for a NAPTR that contains routing information 1988 for a Route Group. The NSType object is comprised of the data 1989 elements necessary for a Name Server that points to another DNS 1990 server that contains the desired routing information. The URIType 1991 object is comprised of the data elements necessary to house a URI. 1993 The data provisioned in a Registry can be leveraged for many purposes 1994 and queried using various protocols including SIP, ENUM and others. 1996 It is for this reason that a route record type offers a choice of URI 1997 and DNS resource record types. URIType fulfills the need for both 1998 SIP and ENUM protocols. When a given URIType is associated to a 1999 destination group, the user part of the replacement string that 2000 may require the Public Identifier cannot be preset. As a SIP 2001 Redirect, the resolution server will apply pattern on the input 2002 Public Identifier in the query and process the replacement string by 2003 substituting any back reference(s) in the to arrive at the 2004 final URI that is returned in the SIP Contact header. For an ENUM 2005 query, the resolution server will simply return the value of the 2006 and members of the URIType in the NAPTR REGEX parameter. 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2023 2024 2025 2026 2027 2028 2029 2031 2032 2033 2034 2035 2036 2038 2039 2040 2041 2043 2044 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2058 2059 2060 2061 2062 2063 2064 2066 2067 2068 2069 2070 2071 2073 The NAPTRType object is composed of the following elements: 2075 o order: Order value in an ENUM NAPTR, relative to other NAPTRType 2076 objects in the same Route Group. 2078 o svcs: ENUM service(s) that are served by the SBE. This field's 2079 value must be of the form specified in [RFC3761] (e.g., E2U+ 2080 pstn:sip+sip). The allowable values are a matter of policy and 2081 not limited by this protocol. 2083 o regx: NAPTR's regular expression field. If this is not included 2084 then the Repl field must be included. 2086 o repl: NAPTR replacement field, should only be provided if the 2087 Regex field is not provided, otherwise it will be ignored by the 2088 server. 2090 o ttl: Number of seconds that an addressing server may cache this 2091 NAPTR. 2093 o ext: Point of extensibility described in a previous section of 2094 this document. 2096 The NSType object is composed of the following elements: 2098 o hostName: Fully qualified host name of the name server. 2100 o ipAddr: Zero or more objects of type IpAddrType. Each object 2101 holds an IP Address and the IP Address type, IPv4 or IP v6. 2103 o ttl: Number of seconds that an addressing server may cache this 2104 Name Server. 2106 o ext: Point of extensibility described in a previous section of 2107 this document. 2109 The URIType object is composed of the following elements: 2111 o ere: The POSIX Extended Regular Expression (ere) as defined in 2112 [RFC3986]. 2114 o uri: the URI as defined in [RFC3986]. In some cases, this will 2115 serve as the replacement string and it will be left to the 2116 resolution server to arrive at the final usable URI. 2118 As with the responses to all update operations, the result of the 2119 AddRteRecRqstType operation is contained in the generic 2120 spppUpdateResponse data structure described in an earlier sections of 2121 this document. For a detailed description of the spppUpdateResponse 2122 data structure refer to that section of the document. 2124 6.12. Get Route Records Operation 2126 The getRteRecsRqst operation allows a client to get the properties of 2127 Route Record objects that a registrar organization is authorized to 2128 view. The server will attempt to find a Route Record object that has 2129 the registrant ID and route record name pair contained in each 2130 ObjKeyType object instance. If the set of ObjKeyType objects is 2131 empty then the server will return the list of Route Record objects 2132 that the querying client has the authority to view. If there are no 2133 matching Route Record found then an empty result set will be 2134 returned. 2136 The element passed into the spppQueryRequest element for this 2137 operation is an instance of type GetRteRecsRqstType, which extends 2138 BasicRqstType and contains zero or more ObjKeyType objects. Any 2139 limitation on the maximum number of objects that may be passed into 2140 or returned by this operation is a policy decision and not limited by 2141 the protocol. The XSD declaration of the operation is as follows: 2143 2144 2145 2146 2147 2149 2150 2151 2152 2154 As described in an earlier section of this document, the result of 2155 any spppQueryRequest operation is an spppQueryResponse element that 2156 contains the overall response code and the query result set, if any. 2157 Refer to that section of the document for a detailed description of 2158 the spppQueryResponse element. 2160 6.13. Delete Operation 2162 In order to remove an object from the Registry, an authorized entity 2163 can send the to the Registry with a corresponding 2164 delete BasicRqstType object. If the entity that issued the command 2165 is not authorized to perform this operation or if the public 2166 identifier doesn't exist, an appropriate error code will be returned 2167 in the message. 2169 As an example, DelPubIdRqstType aids in identifying the Public 2170 Identifier that is used to delete a Public Identifier from the 2171 Registry. DelPubIdsRqstType object definition is shown below: 2173 2174 2175 2176 2177 2178 2179 2180 2182 2184 Similarly, each 'Add' operation in the SP protocol has a 2185 corresponding 'Del' operation used to delete the respective object 2186 type from the Registry. 2188 7. SPPP Examples 2190 This section shows XML message exchange between two SIP Service 2191 Providers (SSP) and a Registry. For the sake of simplicity, the 2192 transport wrapper for the SPPP protocol is left out. The SPPP 2193 protocol messages in this section are valid XML instances that 2194 conform to the SPPP schema version within this document. 2196 In this sample use case scenario, SSP1 and SSP2 provision resource 2197 data in the registry and use SPPP constructs to selectively share the 2198 route groups. In the figure below, SSP2 has two ingress SBE 2199 instances that are associated with the public identities that SSP2 2200 has the retail relationship with. Also, the two SBE instances for 2201 SSP1 are used to show how to use SPPP protocol to associate route 2202 preferences for the destination ingress routes and exercise greater 2203 control on outbound traffic to the peer's ingress SBEs. 2205 ---------------+ +------------------ 2206 | | 2207 +------+ +------+ 2208 | sbe1 | | sbe2 | 2209 +------+ +------+ 2210 SSP1 | | SSP2 2211 +------+ +------+ 2212 | sbe3 | | sbe4 | 2213 +------+ +------+ 2214 iana-en:111 | | iana-en:222 2215 ---------------+ +------------------ 2216 | | 2217 | | 2218 | SPPP +------------------+ SPPP | 2219 +------->| Registry |<--------+ 2220 +------------------+ 2222 7.1. Add Destination Group 2224 SSP2 adds a destination group to the Registry for use later. The 2225 SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for 2226 tracking purposes. The name of the destination group is set to 2227 DEST_GRP_SSP2_1 2228 2229 2233 txid-5555 2234 2236 2237 iana-en:222 2238 iana-en:222 2239 DEST_GRP_SSP2_1 2240 2241 2242 2244 The Registry processes the request and return a favorable response 2245 confirming successful creation of the named destination group. Also, 2246 besides returning a unique transaction identifier, Registry also 2247 returns the matching client transaction identifier from the request 2248 message back to the SPPP client. 2250 2251 2255 tx_5555 2256 tx_id_12346 2257 2258 1000 2259 success 2260 2261 2263 7.2. Add Route Records 2265 SSP2 adds an ingress routes in the Registry. 2267 2268 2272 2274 2276 iana-en:222 2277 iana-en:222 2278 RTE_SSP2_SBE2 2279 10 2280 u 2281 E2U+sip 2282 2283 ^(.*)$ 2284 sip:\1@sbe2.ssp2.example.com 2285 2286 2287 2288 2290 The Registry returns a success response. 2292 2293 2297 tx_id_11145 2298 2299 1000 2300 Request successful 2301 2302 2304 7.3. Add Route Records -- URIType 2306 SSP2 adds another ingress routes in the Registry and makes use of 2307 URIType 2308 2309 2310 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 2311 xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 2312 xmlns="urn:ietf:params:xml:ns:sppp:base:1"> 2313 2315 2316 iana-en:222 2317 iana-en:222 2318 RTE_SSP2_SBE4 2319 ^(.*)$ 2320 sip:\1;npdi@sbe4.ssp2.example.com 2321 2322 2323 2325 The Registry returns a success response. 2327 2328 2332 tx_id_11145 2333 2334 1000 2335 Request successful 2336 2337 2339 7.4. Add Route Group 2341 SSP2 creates the grouping of the ingress routes and choses higher 2342 precedence for RTE_SSP2_SBE2 by setting a lower number for the 2343 "priority" attribute, a protocol agnostic precedence indicator. 2345 2346 2350 2352 2353 iana-en:222 2354 iana-en:222 2355 RTE_GRP_SSP2_1 2356 2357 2358 iana-en:222 2359 RTE_SSP2_SBE2 2360 2361 100 2362 2363 DEST_GRP_SSP2_1 2364 true 2365 10 2366 2367 2368 2370 To confirm successful processing of this request, Registry returns a 2371 well-known resolution code '1000' to the SSP2 client. 2373 2374 2378 tx_id_12345 2379 2380 1000 2381 Request successful 2382 2383 2385 7.5. Add Public Identity -- Successful COR claim 2387 SSP2 activates a TN public identity by associating it with a valid 2388 destination group. Further, SSP2 puts forth a claim that it is the 2389 carrier-of-record for the TN. 2391 2392 2395 txid-5577 2396 2398 2399 iana-en:222 2400 iana-en:222 2401 2010-05-30T09:30:10Z 2402 DEST_GRP_SSP2_1 2403 +12025556666 2404 2405 true 2406 2407 2408 2409 2411 Assuming that the Registry has access to TN authority data and it 2412 performs the required checks to verify that SSP2 is in fact the 2413 service provider of record for the given TN, the request is processed 2414 successfully. In the response message, the Registry sets the value 2415 of to "true" in order to confirm SSP2 claim as the carrier of 2416 record and the reflects the time when the carrier of record 2417 claim is processed. 2419 2420 2424 txid-5577 2425 tx_id_12345 2426 2427 1000 2428 success 2429 2430 2431 1000 2432 success 2433 2435 2436 iana-en:222 2437 iana-en:222 2438 2010-05-30T09:30:10Z 2439 DEST_GRP_SSP2_1 2440 +12025556666 2441 2442 true 2443 true 2444 2010-05-30T09:30:11Z 2445 2446 2447 2448 2449 2451 7.6. Add LRN 2453 If another entity that SSP2 shares the routes with has access to 2454 Number Portability data, it may choose to perform route lookups by 2455 routing number. Therefore, SSP2 associates a routing number to a 2456 destination group in order to facilitate ingress route discovery. 2458 2459 2462 2464 2466 iana-en:222 2467 iana-en:222 2468 DEST_GRP_SSP2_1 2469 2025550000 2470 2471 2472 2474 Registry completes the request successfully and returns a favorable 2475 response to the SPPP client. 2477 2478 2482 tx_id_12345 2483 2484 1000 2485 Request successful 2486 2487 2489 7.7. Add TN Range 2491 Next, SSP2 activates a block of ten thousand TNs and associate it to 2492 a destination group. Since the 'prefix' public identity attribute is 2493 not set to 'true', this means that the TNs belong to a closed number 2494 plan. 2496 2497 2500 2502 2503 iana-en:222 2504 iana-en:222 2505 DEST_GRP_SSP2_1 2506 +12026660000 2507 +12026669999 2508 2509 2510 2512 Registry completes the request successfully and returns a favorable 2513 response. 2515 2516 2520 tx_id_12244498 2521 2522 1000 2523 Request successful 2524 2525 2527 7.8. Add TN Range with Open Number Plan support 2529 In this case, open number plan refers to TN length variance. 2530 Inclusion of "prefix" attribute of TNRType with its value set to true 2531 indicates that the start TN range identified by the element is 2532 not necessarily a subscriber number and the Registry will have to 2533 consult the number plan data for the respective country to know how 2534 to expand the number range. attribute marks the end of the TN 2535 range. 2537 2538 2541 2543 2544 iana-en:222 2545 iana-en:222 2546 DEST_GRP_SSP2_1 2547 +4312315566 2548 +4312315567 2549 2550 2551 2553 Registry completes the request successfully and returns a favorable 2554 response. 2556 2557 2561 tx_id_12255598 2562 2563 1000 2564 Request successful 2565 2566 2568 7.9. Add TN Prefix 2570 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2571 structure and identifying a TN prefix. 2573 2574 2577 2579 2580 iana-en:222 2581 iana-en:222 2582 DEST_GRP_SSP2_1 2583 +1202777 2584 2585 2586 2588 Registry completes the request successfully and returns a favorable 2589 response. 2591 2592 2596 tx_id_12387698 2597 2598 1000 2599 Request successful 2600 2601 2603 7.10. Enable Peering -- Route Group Offer 2605 In order for SSP1 to complete session establishment for a destination 2606 TN where the target subscriber has a retail relationship with SSP2, 2607 it first requires an asynchronous bi-directional handshake to show 2608 mutual consent. To start the process, SSP2 initiates the peering 2609 handshake by offering SSP1 access to its route group. 2611 2612 2615 2617 2618 iana-en:222 2619 iana-en:222 2620 2621 2622 iana-en:222 2623 RTE_GRP_SSP2_1 2624 2625 iana-en:111 2626 2627 offered 2628 2006-05-04T18:13:51.0Z 2629 2630 2631 2633 Registry completes the request successfully and confirms that the 2634 SSP1 will now have the opportunity to weigh in on the offer and 2635 either accept or reject it. The Registry may employ out-of-band 2636 notification mechanisms for quicker updates to SSP1 so they can act 2637 faster, though this topic is beyond the scope of this document. 2639 2640 2644 tx_id_12277798 2645 2646 1000 2647 Request successful 2648 2649 2651 7.11. Enable Peering -- Route Group Offer Accept 2653 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2654 SSP2 ingress routes. 2656 2657 2660 2662 2663 2664 iana-en:222 2665 RTE_GRP_SSP2_1 2666 2667 iana-en:111 2668 2669 2670 2672 Registry confirms that the request has been processed successfully. 2673 From this point forward, if SSP1 looks up a public identity through 2674 the query resolution server, where the public identity is part of the 2675 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2676 ingress SBE information will be shared with SSP1. 2678 2679 2683 tx_id_12333798 2684 2685 1000 2686 success 2687 2688 2690 7.12. Add Egress Route 2692 SSP1 wants to prioritize all outbound traffic to routes associated 2693 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". 2695 2696 2699 tx_9000 2700 2702 2703 iana-en:111 2704 2705 EGR_RTE_01 2706 50 2707 2708 ^(.*@)(.*)$ 2709 \1\2?route=sbe1.ssp1.example.com 2710 2711 2712 iana-en:222 2713 SSP2_RTE_REC_3 2714 2715 2716 2717 2719 Since peering has already been established, the request to add the 2720 egress route has been successfully completed. 2722 2723 2727 tx_9000 2728 tx_id_12388898 2729 2730 1000 2731 Request successful 2732 2734 2736 7.13. Get Destination Group 2738 SSP2 uses the 'GetDestGrpsRqstType' operation to tally the last 2739 provisioned record for destination group DEST_GRP_SSP2_1. 2741 2742 2745 2747 2748 iana-en:222 2749 DEST_GRP_SSP2_1 2750 2751 2752 2754 Registry completes the request successfully and returns a favorable 2755 response. 2757 2758 2761 2762 1000 2763 success 2764 2765 2767 iana-en:222 2768 iana-en:222 2769 DEST_GRP_SSP2_1 2770 2771 2773 7.14. Get Public Identity 2775 SSP2 obtains the last provisioned record associated with a given TN. 2777 2778 2781 2783 2785 iana-en:222 2786 iana-en:222 2787 +12025556666 2788 2789 2790 2792 Registry completes the request successfully and returns a favorable 2793 response. 2795 2796 2799 2800 1000 2801 success 2802 2803 2805 iana-en:222 2806 iana-en:222 2807 DEST_GRP_1 2808 +12025556666 2809 2810 true 2811 true 2812 2010-05-30T09:30:10Z 2813 2814 2815 2817 7.15. Get Route Group Request 2819 SSP2 obtains the last provisioned record for the route group 2820 RTE_GRP_SSP2_1. 2822 2823 2826 2828 2829 iana-en:222 2830 RTE_GRP_SSP2_1 2831 2832 2833 2835 Registry completes the request successfully and returns a favorable 2836 response. 2838 2839 2842 2843 1000 2844 success 2845 2846 2848 iana-en:222 2849 iana-en:222 2850 RTE_GRP_SSP2_1 2851 2852 2853 iana-en:222 2854 RTE_SSP2_SBE2 2855 2856 100 2857 2858 2859 2860 iana-en:222 2861 RTE_SSP2_SBE4 2862 2863 101 2864 2865 DEST_GRP_SSP2_1 2866 true 2867 10 2868 2869 2871 7.16. Get Route Group Offers Request 2873 SSP2 fetches the last provisioned route group offer to the 2874 SSP1. 2876 2877 2880 2882 iana-en:111 2884 2885 2887 Registry processes the request successfully and returns a favorable 2888 response. 2890 2891 2894 2895 1000 2896 success 2897 2898 2900 iana-en:222 2901 iana-en:222 2902 2903 2904 iana-en:222 2905 RTE_GRP_SSP2_1 2906 2907 iana-en:111 2908 2909 offered 2910 2006-05-04T18:13:51.0Z 2911 2912 2914 7.17. Get Egress Route 2916 SSP1 wants to verify the last provisioned record for the egress route 2917 called EGR_RTE_01. 2919 2920 2923 2925 2926 iana-en:111 2927 EGR_RTE_01 2928 2929 2930 2932 Registry completes the request successfully and returns a favorable 2933 response. 2935 2936 2939 2940 1000 2941 success 2942 2943 2945 iana-en:111 2946 iana-en:111 2947 EGR_RTE_01 2948 50 2949 E2U+sip 2950 2951 ^(.*)$ 2952 sip:\1@sbe1.ssp1.example.com 2953 2954 2955 iana-en:222 2956 RTE_GRP_SSP2_1 2957 2958 2959 2961 7.18. Delete Destination Group 2963 SSP2 initiates a request to delete the destination group 2964 DEST_GRP_SSP2_1. 2966 2967 2970 2972 2973 iana-en:222 2974 DEST_GRP_SSP2_1 2975 2976 2977 2979 Registry completes the request successfully and returns a favorable 2980 response. 2982 2983 2986 txid-982543123 2987 2988 1000 2989 Success 2990 2991 2993 7.19. Delete Public Identity 2995 SSP2 choses to de-activate the TN and remove it from the Registry. 2997 2998 3001 3003 3005 iana-en:222 3006 iana-en:222 3007 +12025556666 3008 3009 3010 3012 Registry completes the request successfully and returns a favorable 3013 response. 3015 3016 3019 txid-98298273123 3020 3021 1000 3022 success 3023 3024 3026 7.20. Delete Route Group Request 3028 SSP2 removes the route group called RTE_GRP_SSP2_1. 3030 3031 3034 3036 3037 iana-en:222 3038 RTE_GRP_SSP2_1 3039 3040 3041 3043 Registry completes the request successfully and returns a favorable 3044 response. 3046 3047 3050 txid-982543123 3051 3052 1000 3053 msg 3054 3055 3057 7.21. Delete Route Group Offers Request 3059 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. 3061 3062 3065 3067 3068 3069 iana-en:222 3070 RTE_GRP_SSP2_1 3071 3072 iana-en:111 3073 3074 3075 3077 Registry completes the request successfully and returns a favorable 3078 response. Restoring this resource sharing will require a new route 3079 group offer from SSP2 to SSP1 followed by a successful route group 3080 accept request from SSP1. 3082 3083 3086 txid-982543123 3087 3088 1000 3089 Success 3090 3091 3093 7.22. Delete Egress Route 3095 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3097 3098 3101 3103 3104 iana-en:111 3105 EGR_RTE_01 3106 3107 3108 3110 Registry completes the request successfully and returns a favorable 3111 response. 3113 3114 3117 txid-982543123 3118 3119 1000 3120 Success 3121 3122 3124 8. XML Considerations 3126 XML serves as the encoding format for SPPP, allowing complex 3127 hierarchical data to be expressed in a text format that can be read, 3128 saved, and manipulated with both traditional text tools and tools 3129 specific to XML. 3131 XML is case sensitive. Unless stated otherwise, XML specifications 3132 and examples provided in this document MUST be interpreted in the 3133 character case presented to develop a conforming implementation. 3135 This section discusses a small number of XML-related considerations 3136 pertaining to SPPP. 3138 8.1. Namespaces 3140 All SPPP protocol elements are defined in the namespaces in the IANA 3141 Considerations section and in the Formal Protocol Specification 3142 section of this document. 3144 8.2. Versioning and Character Encoding 3146 All XML instances SHOULD begin with an declaration to 3147 identify the version of XML that is being used, optionally identify 3148 use of the character encoding used, and optionally provide a hint to 3149 an XML parser that an external schema file is needed to validate the 3150 XML instance. 3152 Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) 3153 and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the 3154 RECOMMENDED character encoding for use with SPPP. 3156 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 3157 UTF-8 is the default encoding assumed by XML in the absence of an 3158 "encoding" attribute or a byte order mark (BOM); thus, the "encoding" 3159 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 3160 used. SPPP clients and servers MUST accept a UTF-8 BOM if present, 3161 though emitting a UTF-8 BOM is NOT RECOMMENDED. 3163 Example XML declarations: 3165 version="1.0" encoding="UTF-8" standalone="no"?> 3167 9. Security Considerations 3169 The transport protocol section contains some security properties that 3170 the transport protocol must provide so that authenticated endpoints 3171 can exchange data confidentially and with integrity protection. 3173 More details will be provided in a future revision of this document. 3175 10. IANA Considerations 3177 This document uses URNs to describe XML namespaces and XML schemas 3178 conforming to a registry mechanism described in [RFC3688]. 3180 Two URI assignments are requested. 3182 Registration request for the SPPP XML namespace: 3183 urn:ietf:params:xml:ns:sppp:base:1 3184 Registrant Contact: IESG 3185 XML: None. Namespace URIs do not represent an XML specification. 3187 Registration request for the XML schema: 3188 URI: urn:ietf:params:xml:schema:sppp:1 3189 Registrant Contact: IESG 3190 XML: See the "Formal Specification" section of this document 3191 (Section 11). 3193 IANA is requested to create a new SPPP registry for Organization 3194 Identifiers that will indicate valid strings to be used for well- 3195 known enterprise namespaces. 3196 This document makes the following assignments for the OrgIdType 3197 namespaces: 3199 Namespace OrgIdType namespace string 3200 ---- ---------------------------- 3201 IANA Enterprise Numbers iana-en 3203 11. Formal Specification 3205 This section provides the draft XML Schema Definition for the SPPP 3206 protocol. 3208 3209 3213 3214 3215 ------------------ Object Type Definitions -------------- 3216 3217 3218 3219 3220 3221 3222 3223 3225 3227 3229 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3263 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 3288 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 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 3377 3378 3379 3380 3381 3382 3383 ------------------ Abstract Object and Element 3384 Type Definitions -------------- 3385 3386 3387 3388 3389 3390 3391 3392 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3445 3446 3447 3448 3449 3450 3451 3452 3453 3454 3455 3456 3457 3458 3460 3461 3462 3463 3464 3465 3466 3468 3469 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3491 3492 3493 3494 3495 3496 3497 3498 -------------- Operation Request and Response 3499 Object Type Definitions ------------ 3500 3501 3502 3503 3504 3505 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 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 3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3656 3657 3658 3659 3660 3661 3662 3663 3664 3666 3667 3668 3669 3670 3671 3672 3673 3674 3676 3677 3678 3679 3680 3681 3682 3683 3684 3686 3688 3690 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3721 3722 3723 3724 3725 3726 -------- Generic Request and Response Definitions 3727 --------------- 3728 3729 3730 3731 3732 3734 3736 3738 3739 3740 3741 3742 3743 3744 3746 3747 3748 3751 3752 3753 3754 3755 3756 3757 3759 3760 3761 3762 3763 3764 3765 3766 3767 3769 3770 3771 3772 3773 3774 3775 3777 3778 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 12. Acknowledgments 3792 This document is a result of various discussions held in the DRINKS 3793 working group and within the DRINKS protocol design team, which is 3794 comprised of the following individuals, in alphabetical order: 3795 Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa 3796 Dusseault, Manjul Maharishi, Otmar Lendl, Richard Shockey and Sumanth 3797 Channabasappa. 3799 13. References 3801 13.1. Normative References 3803 [I-D.ietf-drinks-sppp-over-soap] 3804 Cartwright, K., "SPPP Over SOAP and HTTP", 3805 draft-ietf-drinks-sppp-over-soap-01 (work in progress), 3806 October 2010. 3808 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3809 Requirement Levels", BCP 14, RFC 2119, March 1997. 3811 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3812 Languages", BCP 18, RFC 2277, January 1998. 3814 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3815 10646", STD 63, RFC 3629, November 2003. 3817 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3818 January 2004. 3820 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3821 Resource Identifier (URI): Generic Syntax", STD 66, 3822 RFC 3986, January 2005. 3824 13.2. Informative References 3826 [I-D.ietf-drinks-usecases-requirements] 3827 Channabasappa, S., "DRINKS Use cases and Protocol 3828 Requirements", draft-ietf-drinks-usecases-requirements-04 3829 (work in progress), October 2010. 3831 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 3832 10646", RFC 2781, February 2000. 3834 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3835 A., Peterson, J., Sparks, R., Handley, M., and E. 3836 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3837 June 2002. 3839 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 3840 Resource Identifiers (URI) Dynamic Delegation Discovery 3841 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 3843 [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation 3844 Architecture", RFC 4725, November 2006. 3846 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3847 October 2008. 3849 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 3850 Interconnect (SPEERMINT) Terminology", RFC 5486, 3851 March 2009. 3853 Authors' Addresses 3855 Jean-Francois Mule 3856 CableLabs 3857 858 Coal Creek Circle 3858 Louisville, CO 80027 3859 USA 3861 Email: jfm@cablelabs.com 3863 Kenneth Cartwright 3864 TNS 3865 1939 Roland Clarke Place 3866 Reston, VA 20191 3867 USA 3869 Email: kcartwright@tnsi.com 3871 Syed Wasim Ali 3872 NeuStar 3873 46000 Center Oak Plaza 3874 Sterling, VA 20166 3875 USA 3877 Email: syed.ali@neustar.biz 3879 Alexander Mayrhofer 3880 enum.at GmbH 3881 Karlsplatz 1/9 3882 Wien, A-1010 3883 Austria 3885 Email: alexander.mayrhofer@enum.at