idnits 2.17.1 draft-ietf-drinks-spprov-06.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 (March 11, 2011) is 4788 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-02 == 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: September 12, 2011 TNS 6 S. Ali 7 NeuStar 8 A. Mayrhofer 9 enum.at GmbH 10 March 11, 2011 12 Session Peering Provisioning Protocol 13 draft-ietf-drinks-spprov-06 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 September 12, 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 Destination Group Operation . . . . . . . . . . . . . 26 86 6.2. Get Destination Groups Operation . . . . . . . . . . . . . 27 87 6.3. Add Public Identifier Operation . . . . . . . . . . . . . 28 88 6.4. Get Public Identifiers Operation . . . . . . . . . . . . . 33 89 6.5. Add Route Group Operation . . . . . . . . . . . . . . . . 33 90 6.6. Get Route Groups Operation . . . . . . . . . . . . . . . . 38 91 6.7. Add Route Record Operation . . . . . . . . . . . . . . . . 39 92 6.8. Get Route Records Operation . . . . . . . . . . . . . . . 43 93 6.9. Add Route Group Offer Operation . . . . . . . . . . . . . 44 94 6.10. Accept Route Group Offer Operation . . . . . . . . . . . . 47 95 6.11. Reject Route Group Offer Operation . . . . . . . . . . . . 48 96 6.12. Get Route Group Offers Operation . . . . . . . . . . . . . 49 97 6.13. Egress Route Operations . . . . . . . . . . . . . . . . . 50 98 6.14. Delete Operation . . . . . . . . . . . . . . . . . . . . . 52 99 7. SPPP Examples . . . . . . . . . . . . . . . . . . . . . . . . 55 100 7.1. Add Destination Group . . . . . . . . . . . . . . . . . . 55 101 7.2. Add Route Records . . . . . . . . . . . . . . . . . . . . 56 102 7.3. Add Route Records -- URIType . . . . . . . . . . . . . . . 57 103 7.4. Add Route Group . . . . . . . . . . . . . . . . . . . . . 58 104 7.5. Add Public Identity -- Successful COR claim . . . . . . . 60 105 7.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . . 61 106 7.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . . 62 107 7.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . . 63 108 7.9. Enable Peering -- Route Group Offer . . . . . . . . . . . 64 109 7.10. Enable Peering -- Route Group Offer Accept . . . . . . . . 66 110 7.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . . 67 111 7.12. Get Destination Group . . . . . . . . . . . . . . . . . . 68 112 7.13. Get Public Identity . . . . . . . . . . . . . . . . . . . 69 113 7.14. Get Route Group Request . . . . . . . . . . . . . . . . . 70 114 7.15. Get Route Group Offers Request . . . . . . . . . . . . . . 71 115 7.16. Get Egress Route . . . . . . . . . . . . . . . . . . . . . 72 116 7.17. Delete Destination Group . . . . . . . . . . . . . . . . . 74 117 7.18. Delete Public Identity . . . . . . . . . . . . . . . . . . 74 118 7.19. Delete Route Group Request . . . . . . . . . . . . . . . . 75 119 7.20. Delete Route Group Offers Request . . . . . . . . . . . . 76 120 7.21. Delete Egress Route . . . . . . . . . . . . . . . . . . . 77 121 8. XML Considerations . . . . . . . . . . . . . . . . . . . . . . 79 122 8.1. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 79 123 8.2. Versioning and Character Encoding . . . . . . . . . . . . 79 124 9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 126 11. Formal Specification . . . . . . . . . . . . . . . . . . . . . 82 127 12. 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 uniquely identified by its ID. 284 Registrar: In this document, we also extend the definition of a 285 Registrar from [RFC4725]. A Registrar performs provisioning 286 operations on behalf of a Registrant by interacting with the 287 Registry, in our case via the SPPP protocol defined in this 288 document. 290 A Registrar is identified by its ID. 292 3. Protocol High Level Design 294 This section introduces the structure of the data model and provides 295 the information framework for the SPPP protocol. An overview of the 296 protocol operations is first provided with a typical deployment 297 scenario. The data model is then defined along with all the objects 298 manipulated by the protocol and their relationships. 300 3.1. Protocol Layering 302 SPPP is a simple request/reply protocol that allows a client 303 application to submit provisioning data and query requests to a 304 server. The SPPP data structures are designed to be protocol 305 agnostic. Concerns regarding encryption, non-repudiation, and 306 authentication are beyond the scope of this document. For more 307 details, please refer to the Transport Protocol Requirements section. 309 Layer Example 310 +-------------+ +-----------------------------+ 311 (5) |Data Objects | | RteGrpType, etc. | 312 +-------------+ +-----------------------------+ 313 | | 314 +-------------+ +-----------------------------+ 315 (4) | Operations | | AddRteGrpRqstType, etc. | 316 +-------------+ +-----------------------------+ 317 | | 318 +-------------+ +-----------------------------+ 319 (3) | Message | | spppUpdateRequest, | 320 | | | spppUpdateResponse, | 321 | | | spppQueryRequest, | 322 | | | spppQueryResponse | 323 +-------------+ +-----------------------------+ 324 | | 325 +-------------+ +-----------------------------+ 326 (2) | Message | | HTTP, SOAP, None, etc. | 327 | Envelope | | | 328 +-------------+ +-----------------------------+ 329 | | 330 +-------------+ +-----------------------------+ 331 (1) | Transport | | TCP, TLS, BEEP, etc. | 332 | Protocol | | | 333 +-------------+ +-----------------------------+ 335 SPPP Layering 337 Figure 2 339 SPPP can be viewed as a set of layers that collectively define the 340 structure of an SPPP request and response. Layers 1 and 2, as 341 detailed below, are left to separate specifications to allow for 342 potentially multiple SPPP transport, envelope, and authentication 343 technologies. This document defines layers 3, 4, and 5 below. 345 1. The transport protocol layer provides a communication mechanism 346 between the client and server. SPPP can be layered over any 347 transport protocol that provides a set of basic requirements 348 defined in the Transport Protocol Requirements section. 350 2. The message envelope layer is optional, but can provide features 351 that are above the transport technology layer but below the 352 application messaging layer. Technologies such as HTTP and SOAP 353 are examples of messaging envelope technologies. 355 3. The message layer provides a simple, envelope-independent and 356 transport-independent, SPPP wrapper for SPPP request and response 357 messages. 359 4. The operation layer defines the set of base SPPP actions that can 360 be invoked for a given object data type using an SPPP message. 361 Operations are encoded using XML encoded actions and objects. 363 5. The data object layer defines the base set of SPPP data objects 364 that can be included in update operations or returned in 365 operation responses. 367 3.2. Protocol Data Model 369 The data model illustrated and described in Figure 3 defines the 370 logical objects and the relationships between these objects that the 371 SPPP protocol supports. SPPP defines the protocol operations through 372 which an SPPP Client populates a Registry with these logical objects. 373 Various clients belonging to different Registrars may use the 374 protocol for populating the Registry's data. 376 The logical structure presented below is consistent with the 377 terminology and requirements defined in 378 [I-D.ietf-drinks-usecases-requirements]. 380 +-------------+ +------------------+ 381 | all object | |Organization: | 382 | types | |orgId | 383 +------+------+ | | 384 +------------>| | 385 All objects are +------------------+ 386 associated with 2 ^ 387 Organizations to |A Route Group is 388 identify the |associated with 389 registrant and |zero or more Peering 390 the registrar |Organizations 391 | 392 +--------+--------------+ 393 |Route Group: | +-----[abstract]-+ 394 | rant, | | Route Record: | 395 | rar, | | | 396 | rgName, | | rrName, | 397 | destGrpRef, +------->| priority, | 398 | isInSvc, | | extension | 399 | rrRef, | | | 400 | peeringOrg, | +----------------+ 401 | sourceIdent, | ^ 402 | priority, | | 403 | extension | |Various types 404 +-----------------------+ |of Route 405 | |Records... 406 | +------+------------... 407 | | | | 408 | +----+ +-------+ +----+ 409 v | URI| | NAPTR | | NS | 410 +----------------+-----+ +----+ +-------+ +----+ 411 |Destination | 412 |Group: | +----------[abstract]-+ 413 | rant, | |Public Identifier: | 414 | rar, | | | 415 | dgName, | | rant, | 416 | extension |<----+ rar, | 417 +----------------------+ | publicIdentifier, | 418 | destGrpRef, | 419 | rrRef, | 420 | extension | 421 +---------------------+ 422 ^ 423 |Various types 424 |of Public 425 |Identifiers... 426 +---------+-------+------------... 427 | | | | 428 +------+ +-----+ +-----+ +-----+ 429 | TN | | TNP | | TNR | | RN | 430 +------+ +-----+ +-----+ +-----+ 432 SPPP Data Model 433 Figure 3 435 The objects and attributes that comprise the data model can be 436 described as follows (objects listed from the bottom up): 438 o Public Identifier: 439 From a broad perspective a public identifier is a well known 440 attribute that is used as the key to perform resolution lookups. 441 Within the context of SPPP, a Public Identifier object can be a 442 telephone number, a range of telephone numbers, a PSTN Routing 443 Number (RN), or a TN prefix. 445 An SPPP Public Identifier is associated with a Destination Group 446 to create a logical grouping of Public Identifiers that share a 447 common set of Routes. 449 A TN Public Identifier may optionally be associated with zero or 450 more individual Route Records. This ability for a Public 451 Identifier to be directly associated with a set of Route Records 452 (e.g. target URI), as opposed to being associated with a 453 Destination Group, supports the use cases where the target URI 454 contains data specifically tailored to an individual TN Public 455 Identifier. 457 o Destination Group: 458 A named collection of zero or more Public Identifiers that can be 459 associated with one or more Route Groups for the purpose of 460 facilitating the management of their common routing information. 462 o Route Group: 463 A Route Group contains a set of references to Route Records, a set 464 of Destination Group references, and a set of peering organization 465 identifiers. This is used to establish a three part relationships 466 between a set of Public Identifiers and their common routing 467 information (SED), and the list of peering organizations whose 468 query responses may include that routing information in their 469 query responses. To support the use cases defined in [I-D.ietf- 470 drinks-usecases-requirements], this document defines the following 471 types of Route Records: NAPTRType, NSType, and URIType. The 472 sourceIdent element within a Route Group, in concert with the set 473 of peering organization identifiers enables fine grained source 474 based routing. Further details about the Route Group and source 475 based routing refer to the definitions and descriptions of the 476 Route Group operations found later in this document. 478 o Route Record: 479 A Route Record contains the data that a resolution system returns 480 in response to a successful query for a Public Identifier. Route 481 Recoords are associated with a Route Group for SED that is not 482 specific to a Public Identifier. 483 To support the use cases defined in 484 [I-D.ietf-drinks-usecases-requirements], SPPP protocol defines 485 three type of Route Records: URIType, NAPTRType, and NSType. 486 These Route Records extend the abstract type RteRecType and 487 inherit the common attribute 'priority' that is meant for setting 488 precedence across the route records defined within a Route Group 489 in a protocol agnostic fashion. 491 o Organization: 492 An Organization is an entity that may fulfill any combination of 493 three roles: Registrant, Registrar, and Peering Organization. All 494 SPPP objects are associated with two organization identifiers to 495 identify each object's registrant and registrar. A Route Group 496 object is also associated with a set of zero or more organization 497 identifiers that identify the peering organizations whose query 498 responses may include the routing information (SED) defined in the 499 Route Records within that Route Group. 501 4. Transport Protocol Requirements 503 This section provides requirements for transport protocols suitable 504 for SPPP. More specifically, this section specifies the services, 505 features, and assumptions that SPPP delegates to the chosen transport 506 and envelope technologies. 508 Two different groups of use cases are specified in 509 [I-D.ietf-drinks-usecases-requirements]. One group of use cases 510 describes the provisioning of data by a client into a Registry 511 (Section 3.1 of the above referenced document), while the other group 512 describes the distribution of data into local data repositories 513 (Section 3.2). The current version of this document focuses on the 514 first set of use cases (client to registry provisioning). 516 These use cases may involve the provisioning of very small data sets 517 like the modification or update of a single public identifier. Other 518 provisioning operations may deal with huge datasets like the 519 "download" of a whole local number portability database to a 520 Registry. 522 As a result, a transport protocol for SPPP must be very flexible and 523 accommodate various sizes of data set sizes. 525 For the reasons outlined above, it is conceivable that provisioning 526 and distributing may use different transport protocols. This 527 document focuses on the provisioning protocol. 529 4.1. Connection Oriented 531 The SPPP protocol follows a model where a Client establishes a 532 connection to a Server in order to further exchange provisioning 533 transactions over such point-to-point connection. A transport 534 protocol for SPPP MUST therefore be connection oriented. 536 Note that the role of the "Client" and the "Server" only applies to 537 the connection, and those roles are not related in any way to the 538 type of entity that participates in a protocol exchange. For 539 example, a Registry might also include a "Client" when such a 540 Registry initiates a connection (for example, for data distribution 541 to SSP). 543 4.2. Request and Response Model 545 Provisioning operations in SPPP follow the request - response model, 546 where a transaction is initiated by a Client using a Request command, 547 and the Server responds to the Client by means of a Response. 549 Multiple subsequent request-response exchanges MAY be performed over 550 a single connection. 552 Therefore, a transport protocol for SPPP MUST follow the request- 553 response model by allowing a response to be sent to the request 554 initiator. 556 4.3. Connection Lifetime 558 Some use cases involve provisioning a single request to a network 559 element - connections supporting such provisioning requests might be 560 short-lived, and only established on demand. 562 Other use cases involve either provisioning a huge set of data, or a 563 constant stream of small updates, which would require long-lived 564 connections. 566 Therefore, a protocol suitable for SPPP SHOULD support short lived as 567 well as long lived connections. 569 4.4. Authentication 571 Many use cases require the Server to authenticate the Client, and 572 potentially also the Client to authenticate the Server. While 573 authentication of the Server by the Client is expected to be used 574 only to prevent impersonation of the Server, authentication of the 575 Client by the Server is expected to be used to identify and further 576 authorize the Client to certain resources on the Server. 578 Therefore, an SPPP transport protocol MUST provide means for a Server 579 to authenticate and authorize a Client, and MAY provide means for 580 Clients to authenticate a Server. 582 4.5. Confidentiality and Integrity 584 Data that is transported over the protocol is deemed confidential. 585 Therefore, a transport protocol suitable for SPPP MUST ensure 586 confidentiality and integrity protection by providing encryption 587 capabilities. 589 Additionally, a DRINKS protocol MUST NOT use an unreliable lower- 590 layer transport protocol that does not provide confidentiality and 591 integrity protection. 593 4.6. Near Real Time 595 Many use cases require near real-time responses from the Server. 596 Therefore, a DRINKS transport protocol MUST support near-real-time 597 response to requests submitted by the Client. 599 4.7. Request and Response Sizes 601 SPPP covers a range of use cases - from cases where provisioning a 602 single public identifier will create very small request and response 603 sizes to cases where millions of data records are submitted or 604 retrieved in one transaction. Therefore, a transport protocol 605 suitable for SPPP MUST support a great variety of request and 606 response sizes. 608 A transport protocol MAY allow splitting large chunks of data into 609 several smaller chunks. 611 4.8. Request and Response Correlation 613 A transport protocol suitable for SPPP MUST allow responses to be 614 correlated with requests. 616 4.9. Request Acknowledgement 618 Data transported in the SPPP protocol is likely crucial for the 619 operation of the communication network that is being provisioned. 621 Failed transactions can lead to situations where a subset of public 622 identifiers (or even SSPs) might not be reachable, or situations 623 where the provisioning state of the network is inconsistent. 625 Therefore, a transport protocol for SPPP MUST provide a Response for 626 each Request, so that a Client can identify whether a Request 627 succeeded or failed. 629 4.10. Mandatory Transport 631 As of this writing of this revision, one transport protocol proposal 632 has been provided in [I-D.ietf-drinks-sppp-over-soap]. 634 This section will define a mandatory transport protocol to be 635 compliant with this RFC. 637 5. Base Protocol Data Structures 639 SPPP uses a common model and a common set of data structures for most 640 of the supported operations and object types. This section describes 641 these common data structures. 643 5.1. Request and Response Structures 645 An SPPP client interacts with an SPPP server by using one of the 646 supported transport mechanisms to send one or more requests to the 647 server and receive corresponding replies from the server. There are 648 two generalized types of operations that an SPPP client can submit to 649 an SPPP server, updates and queries. The following two sub-sections 650 describe the generalized data structures that are used for each of 651 these two types of operations. 653 5.1.1. Update Request and Response Structures 655 An SPPP update request is wrapped within the 656 element while an SPPP update response is wrapped within an 657 element. The following two sub-sections 658 describe these two elements. 660 5.1.1.1. Update Request 662 An SPPP update request object is contained within the generic 663 element. 665 666 667 668 670 672 674 675 676 678 679 680 681 682 683 685 The data elements within the element are 686 described as follows: 688 o clientTransId: Zero or one client generated transaction ID that, 689 within the context of the SPPP client, identifies this request. 690 This value can be used at the discretion of the SPPP client to 691 track, log or correlate requests and their responses. This 692 value is also echoed back to the client in the SPPP update 693 response. An SPPP server will not check this value for 694 uniqueness. 696 o minorVer: Zero or one minor version identifier, indicating the 697 minor version of the SPPP API that the client is attempting to 698 use. This is used in conjunction with the major version 699 identifier in the XML namespace to identify the version of SPPP 700 that the client is using. If the element is not present, the 701 server assumes that the client is using the latest minor version 702 supported by the SPPP server for the given major version. The 703 versions supported by a given SPPP server can be retrieved by 704 the client using the SPPP server menu operation described later 705 in the document. 707 o rqstObj: One or more BasicUpdateRqstType objects. These are the 708 actions that the client is requesting the SPPP server perform. 709 They are processed by the SPPP server in the order in which they 710 are included in the request. And with respect to handling error 711 conditions, it is a matter of policy whether the objects are 712 processed in a "stop and rollback" fashion or in a "stop and 713 commit" fashion. In the "stop and rollback" scenario, the SPPP 714 server would stop processing BasicUpdateRqstType object 715 instances in the request at the first error and roll back any 716 BasicUpdateRqstType object instances that had already been 717 processed for that update request. In the "stop and commit" 718 scenario the SPPP server would stop processing 719 BasicUpdateRqstType object instances in the request at the first 720 error but commit any BasicUpdateRqstType object instances that 721 had already been processed for that update request. 723 All update request objects extend the base type BasicUpdateRqstType. 724 This base type is defined as follows: 726 727 728 729 730 732 The BasicUpdateRqstType object primarily acts as an abstract base 733 type, and its only data element is described as follows: 735 o ext: This is the standard extension element for this object. 736 Refer to the Extensibility section of this document for more 737 details. 739 5.1.1.2. Update Response 741 An SPPP update response object is contained within the generic 742 element. 744 745 746 747 748 750 752 753 754 755 757 758 759 760 761 762 764 765 766 767 768 769 770 772 773 775 An contains the elements necessary for the SPPP 776 client to precisely determine the overal result of the request, and 777 if an error occurred, it provides information about the specific 778 object, data element, or condition caused the error. 780 The data elements within the SPPP update response are described as 781 follows: 783 o clientTransId: Zero or one client transaction ID. This value is 784 simply an echo of the client transaction ID that SPPP client 785 passed into the SPPP update request. 787 o serverTransId: Exactly one server transaction ID that identifies 788 this request for tracking purposes. This value is guaranteed to 789 be unique for a given SPPP server. 791 o overallResult: Exactly one response code and message pair that 792 explicitly identifies the result of the request. See the 793 Response Code section for further details. 795 o rqstObjResult: An optional response code, response message, and 796 BasicRqstObject triplet. This element will be present only if 797 an object level error condition occurs, and indicates exactly 798 which error condition occurred and exactly which request object 799 that was passed in caused the error condition. The contained 800 BasicRqstObject is simply an echo of the request object instance 801 that caused the error, while the response code and message 802 indicate the error condition for this object. See the Response 803 Code section for further details. 805 o ext: This is the standard extension element for this object. 806 Refer to the Extensibility section for more details. 808 5.1.2. Query Request and Response Structures 810 An SPPP query request is wrapped within the 811 element while an SPPP query response is wrapped within an 812 element. The following two sub-sections describe 813 these two element structures. 815 5.1.2.1. Query Request 817 An SPPP query request object is contained within the generic 818 element. 820 821 822 823 825 826 827 828 830 The data elements within the element are described 831 as follows: 833 o minorVer: Zero or one minor version identifier, indicating the 834 minor version of the SPPP API that the client is attempting to 835 use. This is used in conjunction with the major version 836 identifier in the XML namespace to identify the version of SPPP 837 that the client is using. If the element is not present, the 838 server assumes that the client is using the latest minor version 839 supported by the SPPP server for the given major version. The 840 versions supported by a given SPPP server can be retrieved by 841 the client using the SPPP server menu operation described later 842 in the document. 844 o rqstObj: One BasicQueryRqstType objects. This is the query that 845 the client is requesting the SPPP server perform. 847 All query request objects extend the base type BasicQueryRqstType. 848 This base type is defined as follows: 850 851 852 853 854 856 The BasicQueryRqstType object primarily acts as an abstract base 857 type, and its only data element is described as follows: 859 o ext: This is the standard extension element for this object. 860 Refer to the Extensibility section of this document for more 861 details. 863 5.1.2.2. Query Response 865 An SPPP query response object is contained within the generic 866 element. 868 869 870 871 872 874 875 876 878 An contains the elements necessary for the SPPP 879 client to precisely determine the overal result of the query, and if 880 an error occurred, exactly what condition caused the error. 882 The data elements within the SPPP query response are described as 883 follows: 885 o overallResult: Exactly one response code and message pair that 886 explicitly identifies the result of the request. See the 887 Response Code section for further details. 889 o resultSet: The set of zero or more objects that matched the 890 query criteria. If no objects matched the query criteria then 891 this result set MUST be empty and the overallResult value MUST 892 indicate success (if no matches are found for the query 893 criteria, the response is considered a success). 895 5.2. Response Codes and Messages 897 This section contains the listing of response codes and their 898 corresponding human-readable text. 900 The response code numbering scheme generally adheres to the theory 901 formalized in section 4.2.1 of [RFC5321]: 903 o The first digit of the response code can only be 1 or 2: 1 = a 904 positive result, 2 = a negative result. 906 o The second digit of the response code indicates the category: 0 907 = Protocol Syntax, 1 = Implementation Specific Business Rule, 2 908 = Security, 3 = Server System. 910 o The third and fourth digits of the response code indicate the 911 individual message event within the category defines by the 912 first two digits. 914 The response codes are also categorized as to whether they are 915 overall response codes that may only be returned in the 916 "overallResult" data element in SPPP responses, of object level 917 response codes that may only be returned in the "rqstObjResult" 918 element of the SPPP responses. 920 +--------+--------------------------+-------------------------------+ 921 | Result | Result Message | Overall or Object Level | 922 | Code | | | 923 +--------+--------------------------+-------------------------------+ 924 | 1000 | Request Succeeded. | Overall Response Code | 925 | | | | 926 | 2001 | Request syntax invalid. | Overall Response Code | 927 | | | | 928 | 2002 | Request too large. | Overall Response Code | 929 | | | | 930 | 2003 | Version not supported. | Overall Response Code | 931 | | | | 932 | 2103 | Command invalid. | Overall Response Code | 933 | | | | 934 | 2301 | System temporarily | Overall Response Code | 935 | | unavailable. | | 936 | | | | 937 | 2302 | Unexpected internal | Overall Response Code | 938 | | system or server error. | | 939 | | | | 940 | 2104 | Attribute value invalid. | Object Level Response Code | 941 | | | | 942 | | AttrName:[AttributeName] | | 943 | | AttrVal:[AttributeValue] | | 944 | | | | 945 | 2105 | Object does not exist. | Object Level Response Code | 946 | | AttrName:[AttributeName] | | 947 | | AttrVal:[AttributeValue] | | 948 | | | | 949 | 2106 | Object status or | Object Level Response Code | 950 | | ownership does not allow | | 951 | | for operation. | | 952 | | AttrName:[AttributeName] | | 953 | | AttrVal:[AttributeValue] | | 954 +--------+--------------------------+-------------------------------+ 956 Table 1: Response Codes Numbering Scheme and Messages 958 Each of the object level response messages are "parameterized" with 959 the following parameters: "AttributeName" and "AttributeValue". 961 The use of these parameters MUST adhere to the following rules: 963 o All parameters within a response message are mandatory and MUST 964 be present. 966 o Any value provided for the "AttributeName" parameter MUST be an 967 exact XSD element name of the protocol data element that the 968 response message is referring to. For example, valid values for 969 "attribute name" are "dgName", "rgName", "rteRec", etc. 971 o The value for "AttributeValue" MUST be the value of the data 972 element to which the preceding "AttributeName" refers. 974 o Result code 2104 SHOULD be used whenever an element value does 975 not adhere to data validation rules. 977 o Result codes 2104 and 2105 MUST NOT be used interchangeably. 978 Response code 2105 SHOULD be returned by an update operation 979 when the data element(s) used to uniquely identify a pre- 980 existing object do not exist. If the data elements used to 981 uniquely identify an object are malformed, then response code 982 2104 SHOULD be returned. 984 5.3. Basic Object Type and Organization Identifiers 986 This section introduces the basic object type that most first class 987 objects derive from. 989 All first class objects extend the basic object type BasicObjType 990 which contains the identifier of the registrant organization that 991 owns this object, the identifier of the registrar organization that 992 provisioned this object, the date and time that the object was 993 created by the server, and the date and time that the object was last 994 modified. 996 997 998 999 1000 1001 1002 1003 1004 1006 The identifiers used for registrants (rant), registrars (rar) and 1007 peering organizations (peeringOrg) are instances of OrgIdType. The 1008 OrgIdType is defined as a string and all OrgIdType instances SHOULD 1009 follow the textual convention: "namespace:value" (for example "iana- 1010 en:32473"). See the IANA Consideration section for more details. 1012 6. Protocol Commands 1014 This section provides a description of each supported protocol 1015 command. 1017 6.1. Add Destination Group Operation 1019 As described in the introductory sections, a Destination Group 1020 represents a set of Public Identifiers with common routing 1021 information. 1023 The AddDestGrpRqstType operation creates or overwrites a Destination 1024 Group object. If a Destination Group with the given name and 1025 registrant ID (which together comprise the unique key for a 1026 Destination Group) does not exist, then the server MUST create the 1027 Destination Group. If a Destination Group with the given name and 1028 registrant ID does exist, then the server MUST replace the current 1029 properties of the Destination Group with the properties passed into 1030 the AddDestGrpsRqstType operation. The XSD declarations of the 1031 operation request object are as follows: 1033 1034 1035 1036 1037 1038 1039 1040 1041 1043 The element passed into the spppUpdateRequest element for this 1044 operation is an element of type AddDestGrpRqsttype, which extends 1045 BasicUpdateRqstType and contains a DestGrpType object. The 1046 DestGrpType object structure is defined as follows: 1048 1049 1050 1051 1052 1053 1054 1056 1057 1059 The DestGrpType object is composed of the following elements: 1061 o base: All first class objects extend BasicObjType which contains 1062 the ID of the registrant organization that owns this object, the 1063 ID of the registrar organization that provisioned this object, 1064 the date and time that the object was created by the server, and 1065 the date and time that the object was last modified. If the 1066 client passed in either the created date or the modification 1067 date, the server will ignore them. The server sets these two 1068 date/time values. 1070 o dgName: The character string that contains the name of the 1071 Destination Group. This uniquely identifies this object within 1072 the context of the registrant ID (a child element of the base 1073 element as described above). 1075 o ext: Point of extensibility described in a previous section of 1076 this document. 1078 As with the responses to all update operations, the result of the 1079 AddDestGrpRqstType operation is contained in the generic 1080 spppUpdateResponse data structure described in an earlier sections of 1081 this document. For a detailed description of the spppUpdateResponse 1082 data structure refer to that section of the document. 1084 6.2. Get Destination Groups Operation 1086 The getDestGrpsRqst operation allows a client to get the properties 1087 of Destination Group objects that a registrar organization is 1088 authorized to view. The server will attempt to find a Destination 1089 Group object that has the registrant ID and destination group name 1090 pair contained in each ObjKeyType object instance. If there are no 1091 matching Destination Groups found then an empty result set will be 1092 returned. If the set of ObjKeyType objects passed in is empty then 1093 the server will return the list of Destination Group objects that the 1094 querying registrar has the authority to view. 1096 The element passed into the spppQueryRequest element for this 1097 operation is an instance of type GetDestGrpsRqstType, which extends 1098 BasicQueryRqstType and contains zero or more ObjKeyType objects. Any 1099 limitation on the maximum number of objects that may be passed into 1100 or returned by this operation is a policy decision and not limited by 1101 the protocol. The XSD declaration of the operation is as follows: 1103 1104 1105 1106 1107 1109 1110 1111 1112 1114 As described in an earlier section of this document, the result of 1115 any spppQueryRequest operation is an spppQueryResponse element that 1116 contains the overall response code and the query result set, if any. 1117 Refer to that section of the document for a detailed description of 1118 the spppQueryResponse element. 1120 6.3. Add Public Identifier Operation 1122 A Public Identifier is the search key used for locating the session 1123 establishment data (SED). In many cases, a Public Identifier is 1124 attributed to the end user who has a retail relationship with the 1125 service provider or registrant organization. SPPP supports the 1126 notion of the carrier-of-record as defined in RFC 5067. Therefore, 1127 the Registrant under which the Public Identity is being created can 1128 optionally claim to be a carrier-of-record. 1130 SPPP identifies two types of Public Identifiers: telephone numbers 1131 (TN), and the routing numbers (RN). SPPP provides structures to 1132 manage a single TN, a contiguous range of TNs, and a TN prefix. 1134 The abstract XML schema type definition PubIDType is a generalization 1135 for the concrete the Public Identifier schema types. PubIDType 1136 element 'dgName' represents the name of the destination group that a 1137 given Public Identifier is a member of. Because a Destination Group 1138 is uniquely identified by its composite business key, which is 1139 comprised of its Registrant ID, rantId, and its name, dgName, the 1140 Public Identity's containing Destination Group is identified by the 1141 Public Identity's dgName element and the Public Identity's registrant 1142 ID, rantId, element. The PubIDType object structure is defined as 1143 follows: 1145 1146 1147 1148 1149 1150 1151 1152 1153 1155 A registrant can add a Public Identifier using the AddPubIdRqstType 1156 operation. To complete the add request, AddPubIdRqstType XML 1157 instance is populated into the element. A Public 1158 Identifier may provisioned as a member of a Destination Group or 1159 provisioned outside of a Destination Group. A Public Identifier that 1160 is provisioned as a member of a Destionation Group is intended to be 1161 associated with its SED through the Route Group(s) that are 1162 associated with its containing Destination Group. A Public 1163 Identifier that is not provisioned as a member of a Destionation 1164 Group is intended to be associated with its SED through the Route 1165 Records that are directly associated with the Public Identifier. If 1166 a Public Identifier being added already exists then that Public 1167 Identifier will be replaced with the newly provisioned Public 1168 Identifier. 1170 A telephone number is provisioned using the TNType, an extension of 1171 PubIDType. Each TNType object is uniquely identified by the 1172 combination of its tn element, and the unique key of its parent 1173 Destination Group (dgName and rantId). In other words a given 1174 telephone number string may exist within one or more Destination 1175 Groups, but must not exist more than once within a Destination Group. 1176 TNType is defined as follows: 1178 1179 1180 1181 1182 1183 1185 1187 1188 1189 1191 1193 TNType consists of the following attributes: 1195 o tn: Telephone number to be added to the Registry. 1197 o rrRef: Optional reference to route records that are directly 1198 associated with the TN Public Identifier. Following the SPPP 1199 data model, the route record could be a protocol agnostic 1200 URIType or another type. 1202 o corInfo: corInfo is an optional parameter of type CORInfoType 1203 that allows the registrant organization to set forth a claim to 1204 be the carrier-of-record [see RFC 5067]. This is done by 1205 setting the value of element of the CORInfoType 1206 object structure to "true". The other two parameters of the 1207 CORInfoType, and are set by the Registry to 1208 describe the outcome of the carrier-of-record claim by the 1209 registrant. In general, inclusion of parameter is 1210 useful if the Registry has the authority information, such as, 1211 the number portability data, etc., in order to qualify whether 1212 the registrant claim can be satisfied. If the carrier-of-record 1213 claim disagrees with the authority data in the Registry, whether 1214 the TN add operation fails or not is a matter of policy and it 1215 is beyond the scope of this document. In the response message 1216 , the SPPP Server must include the 1217 parameter of the element to let the registrant know 1218 the outcome of the claim. 1220 A routing number is provisioned using the RNType, an extension of 1221 PubIDType. SSPs that possess the number portability data may be able 1222 to leverage the RN search key to discover the ingress routes for 1223 session establishment. Therefore, the registrant organization can 1224 add the RN and associate it with the appropriate destination group to 1225 share the route information. Each RNType object is uniquely 1226 identified by the combination of its rn element, and the unique key 1227 of its parent Destination Group (dgName and rantId). In other words 1228 a given routing number string may exist within one or more 1229 Destination Groups, but must not exist more than once within a 1230 Destination Group. RNType is defined as follows: 1232 1233 1234 1235 1236 1237 1239 1240 1241 1242 1244 RNType has the following attributes: 1246 o rn: Routing Number used as the search key 1248 o corInfo: Optional element of type CORInfoType. 1250 TNRType structure is used to provision a contiguous range of 1251 telephone numbers. The object definition requires a starting TN and 1252 an ending TN that together define the span of the TN range. Use of 1253 TNRType is particularly useful when expressing a TN range that does 1254 not include all the TNs within a TN block or prefix. The TNRType 1255 definition accommodates the open number plan as well such that the 1256 TNs that fall between the start and end TN range may include TNs with 1257 different length variance. Whether the Registry can accommodate the 1258 open number plan semantics is a matter of policy and is beyond the 1259 scope of this document. Each TNRType object is uniquely identified 1260 by the combination of its startTn and endTn elements, and the unique 1261 key of its parent Destination Group (dgName and rantId). In other 1262 words a given TN Range may exist within one or more Destination 1263 Groups, but must not exist more than once within a Destination Group. 1264 TNRType object structure definition is as follows: 1266 1267 1268 1269 1270 1271 1272 1274 1275 1276 1278 1280 TNRType has the following attributes: 1282 o startTn: Starting TN in the TN range 1284 o endTn: The last TN in the TN range 1286 o corInfo: Optional element of type CORInfoType 1288 In some cases, it is useful to describe a set of TNs with the help of 1289 the first few digits of the telephone number, also referred to as the 1290 telephone number prefix or a block. A given TN prefix may include 1291 TNs with different length variance in support of open number plan. 1292 Once again, whether the Registry supports the open number plan 1293 semantics is a matter of policy and it is beyond the scope of this 1294 document. The TNPType data structure is used to provision a TN 1295 prefix. Each TNPType object is uniquely identified by the 1296 combination of its tnPrefix element, and the unique key of its parent 1297 Destination Group (dgName and rantId). TNPType is defined as 1298 follows: 1300 1301 1302 1303 1304 1305 1307 1308 1309 1310 1312 TNPType consists of the following attributes: 1314 o tnPrefix: The telephone number prefix 1316 o corInfo: Optional element of type CORInfoType. 1318 The object structure of AddPubIdRqstType is used to add Public 1319 Identifiers is as follows 1320 1321 1322 1323 1324 1325 1326 1327 1328 1330 6.4. Get Public Identifiers Operation 1332 The SPPP client can use the GetPubIdsRqstType in the 1333 structure to obtain information about one or more 1334 objects. If no matching Public Identifiers are found, then an 1335 empty result set is returned. 1337 GetPubIdsRqstType object structure is as follows: 1339 1340 1341 1342 1343 1345 1346 1347 1348 1350 As described earlier in the document, the result of any 1351 spppQueryRequest operation is a spppQueryResponse that contains the 1352 response code and the query result set, if any. 1354 6.5. Add Route Group Operation 1356 As described in the introductory sections, a Route Group represents a 1357 combined grouping of Route Records that define route information, 1358 Destination Groups that contain a set of Public Identifiers with 1359 common routing information, and the list of peer organizations that 1360 have access to these public identifiers using this route information. 1361 It is this indirect linking of public identifiers to their route 1362 information that significantly improves the scalability and 1363 manageability of the peering data. Additions and changes to routing 1364 information are reduced to a single operation on a Route Group or 1365 Route Record , rather than millions of data updates to individual 1366 public identifier records that individually contain their peering 1367 data. 1369 The AddRteGrpRqstType operation creates or overwrites a Route Group 1370 object. If a Route Group with the given name and registrant ID 1371 (which together comprise the unique key or a Route Group) does not 1372 exist, then the server MUST create the Route Group. If a Route Group 1373 with the given name and registrant ID does exist, then the server 1374 MUST replace the current properties of the Route Group with the 1375 properties passed into the AddRteGrpRqstType operation. The XSD 1376 declarations of the AddRteGrpRqstType operation request object are as 1377 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 AddRteGrpRqstType, which extends 1391 BasicUpdateRqstType and contains one RteGrpType object. The 1392 RteGrpType object structure is defined as follows: 1394 1395 1396 1397 1398 1399 1401 1403 1405 1407 1408 1409 1410 1411 1412 1413 1415 1416 1417 1418 1419 1420 1421 1423 The RteGrpType object is composed of the following elements: 1425 o base: All first class objects extend BasicObjType which contains 1426 the ID of the registrant organization that owns this object, the 1427 ID of the registrar organization that provisioned this object, 1428 the date and time that the object was created by the server, and 1429 the date and time that the object was last modified. If the 1430 client passes in either the created date or the modification 1431 date, the server will ignore them. The server sets these two 1432 date/time values. 1434 o rgName: The character string that contains the name of the Route 1435 Group. It uniquely identifies this object within the context of 1436 the registrant ID (a child element of the base element as 1437 described above). 1439 o rrRef: Set of zero or more objects of type RteRecRefType that 1440 house the unique keys of the Route Records that the RteGrpType 1441 object refers to and their relative priority within the context 1442 of a given route group. The associated Route Records contain 1443 the routing information, sometimes called SED, associated with 1444 this Route Group. 1446 o dgName: Set of zero or more names of DestGrpType object 1447 instances. Each dgName name, in association with this Route 1448 Group's registrant ID, uniquely identifies a DestGrpType object 1449 instance whose public identifiers are reachable using the 1450 routing information housed in this Route Group. An intended 1451 side affect of this is that a Route Group cannot provide routing 1452 information for a Destination Group belonging to another 1453 registrant. 1455 o peeringOrg: Set of zero or more peering organization IDs that 1456 have accepted an offer to receive this Route Group's 1457 information. The set of peering organizations in this list is 1458 not directly settable or modifiable using the addRteGrpsRqst 1459 operation. This set is instead controlled using the route offer 1460 and accept operations. 1462 o sourceIdent: Set of zero or more SourceIdentType object 1463 instances. These objects, described further below, house the 1464 source identification schemes and identifiers that are applied 1465 at resolution time as part of source based routing algorithms 1466 for the Route Group. 1468 o isInSvc: A boolean element that defines whether this Route Group 1469 is in service. The routing information contained in a Route 1470 Group that is in service is a candidate for inclusion in 1471 resolution responses for public identities residing in the 1472 Destination Group associated with this Route Group. The routing 1473 information contained in a Route Group that is not in service is 1474 not a candidate for inclusion in resolution responses. 1476 o priority: Zero or one priority value that can be used to provide 1477 a relative value weighting of one Route Group over another. The 1478 manner in which this value is used, perhaps in conjunction with 1479 other factors, is a matter of policy. 1481 o ext: Point of extensibility described in a previous section of 1482 this document. 1484 As described above, the Route Group contains a set of references to 1485 route record objects. A route record object is based on an abstract 1486 type: RteRecType. The concrete types that use RteRecType as an 1487 extension base are NAPTRType, NSType, and URIType. The definitions 1488 of these types are included the Route Record section of this 1489 document. 1491 The RteGrpType object provides support for source-based routing via 1492 the peeringOrg data element and more granular source base routing via 1493 the source identity element. The source identity element provides 1494 the ability to specify zero or more of the following in association 1495 with a given Route Group: a regular expression that is matched 1496 against the resolution client IP address, a regular expression that 1497 is matched against the root domain name(s), and/or a regular 1498 expression that is matched against the calling party URI(s). The 1499 result will be that, after identifying the visible Route Groups whose 1500 associated Destination Group(s) contain the lookup key being queried 1501 and whose peeringOrg list contains the querying organizations 1502 organization ID, the resolution server will evaluate the 1503 characteristics of the Source URI, and Source IP address, and root 1504 domain of the lookup key being queried. The resolution server then 1505 compares these criteria against the source identity criteria 1506 associated with the Route Groups. The routing information contained 1507 in Route Groups that have source based routing criteria will only be 1508 included in the resolution response if one or more of the criteria 1509 matches the source criteria from the resolution request. The Source 1510 Identity data element is of type SourceIdentType, whose structure is 1511 defined as follows: 1513 1514 1515 1516 1518 1519 1520 1522 1523 1524 1525 1526 1527 1528 1530 The SourceIdentType object is composed of the following data 1531 elements: 1533 o sourceIdentScheme: The source identification scheme that this 1534 source identification criteria applies to and that the 1535 associated sourceIdentRegex should be matched against. 1537 o sourceIdentRegex: The regular expression that should be used to 1538 test for a match against the portion of the resolution request 1539 that is dictated by the associated sourceIdentScheme. 1541 o ext: Point of extensibility described in a previous section of 1542 this document. 1544 As with the responses to all update operations, the result of the 1545 AddRteGrpRqstType operation is contained in the generic 1546 spppUpdateResponse data structure described in an earlier sections of 1547 this document. For a detailed description of the spppUpdateResponse 1548 data structure refer to that section of the document. 1550 6.6. Get Route Groups Operation 1552 The getRteGrpsRqst operation allows a client to get the properties of 1553 Route Group objects that a registrar organization is authorized to 1554 view. The server will attempt to find a Route Group object that has 1555 the registrant ID and route group name pair contained in each 1556 ObjKeyType object instance. If the set of ObjKeyType objects is 1557 empty then the server will return the list of Route Group objects 1558 that the querying client has the authority to view. If there are no 1559 matching Route Groups found then an empty result set will be 1560 returned. 1562 The element passed into the spppQueryRequest element for this 1563 operation is an instance of type GetRteGrpsRqstType, which extends 1564 BasicUpdateRqstType and contains zero or more ObjKeyType objects. 1565 Any limitation on the maximum number of objects that may be passed 1566 into or returned by this operation is a policy decision and not 1567 limited by the protocol. The XSD declaration of the operation is as 1568 follows: 1570 1571 1572 1573 1574 1576 1577 1578 1580 1582 As described in an earlier section of this document, the result of 1583 any spppQueryRequest operation is an spppQueryResponse element that 1584 contains the overall response code and the query result set, if any. 1585 Refer to that section of the document for a detailed description of 1586 the spppQueryResponse element. 1588 6.7. Add Route Record Operation 1590 As described in the introductory sections, a Route Group represents a 1591 combined grouping of Route Records that define route information. 1592 However, Route Records need not be created to just serve a single 1593 Route Group. Route Records can be created and managed to serve 1594 multiple Route Groups. As a result, a change to the properties of a 1595 network node, for example, that is used for multiple routes, would 1596 necessitate just a single update operation to change the properties 1597 of that node. The change would then be reflected in all the Route 1598 Groups whose route record set contains a reference to that node. 1600 The AddRteRecRqstType operation creates or overwrites a Route Record 1601 object. If a Route Record with the given name and registrant ID 1602 (which together comprise the unique key or a Route Record) does not 1603 exist, then the server MUST create the Route Record. If a Route 1604 Record with the given name and registrant ID does exist, then the 1605 server MUST replace the current properties of the Route Record with 1606 the properties passed into the AddRteRecRqstType operation. The XSD 1607 declarations of the AddRteRecRqstType operation request object are as 1608 follows: 1610 1611 1612 1613 1614 1615 1616 1617 1618 1620 The element passed into the spppUpdateRequest element for this 1621 operation is an instance of AddRteRecRqstType, which extends 1622 BasicUpdateRqstType and contains one RteRecType object. The 1623 RteRecType object structure is defined as follows: 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1636 The RteRecType object is composed of the following elements: 1638 o base: All first class objects extend BasicObjType which contains 1639 the ID of the registrant organization that owns this object, the 1640 ID of the registrar organization that provisioned this object, 1641 the date and time that the object was created by the server, and 1642 the date and time that the object was last modified. If the 1643 client passes in either the created date or the modification 1644 date, the server will ignore them. The server sets these two 1645 date/time values. 1647 o rrName: The character string that contains the name of the Route 1648 Record. It uniquely identifies this object within the context 1649 of the registrant ID (a child element of the base element as 1650 described above). 1652 o priority: Zero or one priority value that can be used to provide 1653 a relative value weighting of one Route Record over another. 1654 The manner in which this value is used, perhaps in conjunction 1655 with other factors, is a matter of policy. 1657 As described above, route records are based on an abstract type: 1658 RteRecType. The concrete types that use RteRecType as an extension 1659 base are NAPTRType, NSType, and URIType. The definitions of these 1660 types are included below. The NAPTRType object is comprised of the 1661 data elements necessary for a NAPTR that contains routing information 1662 for a Route Group. The NSType object is comprised of the data 1663 elements necessary for a Name Server that points to another DNS 1664 server that contains the desired routing information. The NSType is 1665 relevant only when the resolution protocol is ENUM. The URIType 1666 object is comprised of the data elements necessary to house a URI. 1668 The data provisioned in a Registry can be leveraged for many purposes 1669 and queried using various protocols including SIP, ENUM and others. 1670 It is for this reason that a route record type offers a choice of URI 1671 and DNS resource record types. URIType fulfills the need for both 1672 SIP and ENUM protocols. When a given URIType is associated to a 1673 destination group, the user part of the replacement string that 1674 may require the Public Identifier cannot be preset. As a SIP 1675 Redirect, the resolution server will apply pattern on the input 1676 Public Identifier in the query and process the replacement string by 1677 substituting any back reference(s) in the to arrive at the 1678 final URI that is returned in the SIP Contact header. For an ENUM 1679 query, the resolution server will simply return the value of the 1680 and members of the URIType in the NAPTR REGEX parameter. 1682 1683 1684 1685 1686 1687 1688 1689 1691 1692 1693 1694 1695 1696 1697 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1723 The NAPTRType object is composed of the following elements: 1725 o order: Order value in an ENUM NAPTR, relative to other NAPTRType 1726 objects in the same Route Group. 1728 o svcs: ENUM service(s) that are served by the SBE. This field's 1729 value must be of the form specified in [RFC3761] (e.g., E2U+ 1730 pstn:sip+sip). The allowable values are a matter of policy and 1731 not limited by this protocol. 1733 o regx: NAPTR's regular expression field. If this is not included 1734 then the Repl field must be included. 1736 o repl: NAPTR replacement field, should only be provided if the 1737 Regex field is not provided, otherwise it will be ignored by the 1738 server. 1740 o ttl: Number of seconds that an addressing server may cache this 1741 NAPTR. 1743 o ext: Point of extensibility described in a previous section of 1744 this document. 1746 The NSType object is composed of the following elements: 1748 o hostName: Fully qualified host name of the name server. 1750 o ttl: Number of seconds that an addressing server may cache this 1751 Name Server. 1753 o ext: Point of extensibility described in a previous section of 1754 this document. 1756 The URIType object is composed of the following elements: 1758 o ere: The POSIX Extended Regular Expression (ere) as defined in 1759 [RFC3986]. 1761 o uri: the URI as defined in [RFC3986]. In some cases, this will 1762 serve as the replacement string and it will be left to the 1763 resolution server to arrive at the final usable URI. 1765 As with the responses to all update operations, the result of the 1766 AddRteRecRqstType operation is contained in the generic 1767 spppUpdateResponse data structure described in an earlier sections of 1768 this document. For a detailed description of the spppUpdateResponse 1769 data structure refer to that section of the document. 1771 6.8. Get Route Records Operation 1773 The getRteRecsRqst operation allows a client to get the properties of 1774 Route Record objects that a registrar organization is authorized to 1775 view. The server will attempt to find a Route Record object that has 1776 the registrant ID and route record name pair contained in each 1777 ObjKeyType object instance. If the set of ObjKeyType objects is 1778 empty then the server will return the list of Route Record objects 1779 that the querying client has the authority to view. If there are no 1780 matching Route Record found then an empty result set will be 1781 returned. 1783 The element passed into the spppQueryRequest element for this 1784 operation is an instance of type GetRteRecsRqstType, which extends 1785 BasicUpdateRqstType and contains zero or more ObjKeyType objects. 1786 Any limitation on the maximum number of objects that may be passed 1787 into or returned by this operation is a policy decision and not 1788 limited by the protocol. The XSD declaration of the operation is as 1789 follows: 1791 1792 1793 1794 1795 1797 1798 1799 1800 1802 As described in an earlier section of this document, the result of 1803 any spppQueryRequest operation is an spppQueryResponse element that 1804 contains the overall response code and the query result set, if any. 1805 Refer to that section of the document for a detailed description of 1806 the spppQueryResponse element. 1808 6.9. Add Route Group Offer Operation 1810 The list of peer organizations whose resolution responses can include 1811 the routing information contained in a given Route Group is 1812 controlled by the organization to which a Route Group object belongs 1813 (its registrant), and the peer organization that submits resolution 1814 requests (a data recipient, also know as a peering organization). 1815 The registrant offers access to a Route Group by submitting a Route 1816 Group Offer. The data recipient can then accept or reject that 1817 offer. Not until access to a Route Group has been offered and 1818 accepted will the data recipient's organization ID be included in the 1819 peeringOrg list in a Route Group object, and that Route Group's 1820 peering information become a candidate for inclusion in the responses 1821 to the resolution requests submitted by that data recipient. The 1822 AddRteGrpOffersRqstType operation creates or overwrites one or more 1823 Route Group Offer objects. If a Route Group Offer for the given 1824 Route Group object key and the offeredTo Org ID does not exist, then 1825 the server creates the Route Group Offer object. If a such a Route 1826 Group Offer does exist, then the server replaces the current object 1827 with the new object. The XSD declarations of the operation request 1828 object are as follows: 1830 1831 1832 1833 1834 1835 1836 1837 1838 1840 The element passed into the spppUpdateRequest element for this 1841 operation is an instance of AddRteGrpOfferRqstType, which extends 1842 BasicUpdateRqstType and contains a RteGrpOfferType object. The XSD 1843 declaration of the RteGrpOfferType is as follows: 1845 1846 1847 1848 1849 1851 1852 1853 1854 1855 1856 1857 1858 1860 1861 1862 1863 1864 1865 1867 1868 1869 1870 1871 1872 1874 The RteGrpOfferType object is composed of the following elements: 1876 o base: All first class objects extend BasicObjType which contains 1877 the ID of the registrant organization that owns this object, the 1878 ID of the registrar organization that provisioned this object, 1879 the date and time that the object was created by the server, and 1880 the date and time that the object was last modified. If the 1881 client passed in either the created date or the modification 1882 date, the will ignore them. The server sets these two date/time 1883 values. 1885 o rteGrpOfferKey: The object that identifies the route that is or 1886 has been offered and the organization that it is or has been 1887 offered to. The combination of these three data elements 1888 uniquely identify a Route Group Offer. 1890 o status: The status of the offer, offered or accepted. This 1891 status is controlled by the server. It is automatically set to 1892 "offered" when ever a new Route Group Offer is added, and is 1893 automatically set to "accepted" if and when that offer is 1894 accepted. The value of the element is ignored when passed in by 1895 the client. 1897 o offerDateTime: Date and time in GMT when the Route Group Offer 1898 was added. 1900 o acceptDateTime: Date and time in GMT when the Route Group Offer 1901 was accepted. 1903 As with the responses to all update operations, the result of the 1904 AddRteGrpOfferRqstType operation is contained in the generic 1905 spppUpdateResponse data structure described in an earlier sections of 1906 this document. For a detailed description of the spppUpdateResponse 1907 data structure refer to that section of the document. 1909 6.10. Accept Route Group Offer Operation 1911 Not until access to a Route Group has been offered and accepted will 1912 the data recipient's organization ID will it be included in the 1913 peeringOrg list in that Route Group object, and that Route Group's 1914 peering information become a candidate for inclusion in the responses 1915 to the resolution requests submitted by that data recipient. The 1916 AcceptRteGrpOffersRqstType operation is called by, or on behalf of, 1917 the data recipient to accept a Route Group Offer that is pending in 1918 the "offered" status for the data recipient's organization ID. If a 1919 Route Group Offer for the given Route Group Offer key (route name, 1920 route registrant ID, data recipient's organization ID) exists, then 1921 the server moves the Route Group Offer to the "accepted" status and 1922 adds that data recipient's organization ID into the list of 1923 peerOrgIds for that Route Group. If a such a Route Group Offer does 1924 not exist, then the server returns the appropriate error code, 2105. 1925 The XSD declarations for the operation request object are as follows: 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 The element passed into the spppUpdateRequest element for this 1937 operation is an instance of AcceptRteGrpOffersRqstType, which extends 1938 BasicUpdateRqstType and contains a RteGrpOfferKeyType object. 1940 As with the responses to all update operations, the result of the 1941 AcceptRteGrpOfferRqstType operation is contained in the generic 1942 spppUpdateResponse data structure described in an earlier sections of 1943 this document. For a detailed description of the spppUpdateResponse 1944 data structure refer to that section of the document. 1946 6.11. Reject Route Group Offer Operation 1948 The data recipient to which a Route Group has been offered has the 1949 option of rejecting a Route Group Offer. Furthermore, that offer may 1950 be rejected, regardless of whether or not it has been previously 1951 accepted. The RejectRteGrpOffersRqstType operation is used for these 1952 purposes and is called by, or on behalf of, the data recipient to 1953 accept a Route Group Offer that is pending in the "offered" status or 1954 is in the "accepted" status for the data recipient's organization ID. 1955 If a Route Group Offer for the given Route Group Offer key (route 1956 name, route registrant ID, data recipient's organization ID) exists 1957 in either the offered or accepted status, then the server deletes 1958 that Route Group Offer object, and, if appropriate, removes the data 1959 recipients organization ID from the list of peeringOrg IDs for that 1960 Route Group. If the Route Group Offer does not exist, then the 1961 server returns the appropriate error code, 2105. The XSD 1962 declarations for the operation request object are as follows: 1964 1965 1966 1967 1968 1969 1970 1971 1972 1974 The element passed into the spppUpdateRequest element for this 1975 operation is an instance of RejectRteGrpOffersRqstType, which extends 1976 BasicUpdateRqstType and contains a RteGrpOfferKeyType object. 1978 As with the responses to all update operations, the result of the 1979 RejectRteGrpOfferRqstType operation is contained in the generic 1980 spppUpdateResponse data structure described in an earlier sections of 1981 this document. For a detailed description of the spppUpdateResponse 1982 data structure refer to that section of the document. 1984 6.12. Get Route Group Offers Operation 1986 The getRteGrpOffersRqst operation allows a client to get the 1987 properties of zero or more Route Group Offer objects that registrar 1988 is authorized to view. The server will attempt to find Route Group 1989 Offer objects that have all the properties specified in the criteria 1990 passed into the operation. If no criteria is passed in then the 1991 server will return the list of Route Group Offer objects that the 1992 querying client has the authority to view. If there are no matching 1993 Route Group Offers found then an empty result set will be returned. 1995 The element passed into the spppQueryRequest element for this 1996 operation is an instance of GetRteGrpOffersRqstType, which extends 1997 BasicQueryRqstType and contains the criteria that the returned Route 1998 Group Offer objects must match. Any limitation on the maximum number 1999 of objects that may be returned by this operation is a policy 2000 decision and not limited by the protocol. The XSD declaration of the 2001 operation is as follows: 2003 2004 2005 2006 2007 2009 2011 2013 2016 2017 2018 2019 2021 The GetRteGrpOffersRqstType object is composed of the following 2022 elements: 2024 o offeredBy: Zero or more organization IDs. Only offers that are 2025 offered to the organization IDs in this list should be included 2026 in the result set. The result set is also subject to other 2027 query criteria in the request. 2029 o offeredTo: Zero or more organization IDs. Only offers that are 2030 offered by the organization IDs in this list should be included 2031 in the result set. The result set is also subject to other 2032 query criteria in the request. 2034 o status: The status of the offer, offered or accepted. Only 2035 offers in the specified status should be included in the result 2036 set. If this element is not present then the status of the 2037 offer should not be considered in the query. The result set is 2038 also subject to other query criteria in the request. 2040 o rteGrpOfferKey: Zero or more Route Group Offer Keys. Only 2041 offers having one of these keys should be included in the result 2042 set. The result set is also subject to other query criteria in 2043 the request. 2045 As described in an earlier section of this document, the result of 2046 any spppQueryRequest operation is an spppQueryResponse element that 2047 contains the overall response code and the query result set, if any. 2048 Refer to that section of the document for a detailed description of 2049 the spppQueryResponse element. 2051 6.13. Egress Route Operations 2053 In a high-availability environment, the originating SSP likely has 2054 more than one egress paths to the ingress SBE of the target SSP. If 2055 the originating SSP wants to exercise greater control and choose a 2056 specific egress SBE to be associated to the target ingress SBE, it 2057 can do so using the AddEgrRteRqstType object. 2059 Lets assume that the target SSP has offered to share one or more 2060 ingress route information and that the originating SSP has accepted 2061 the offer. In order to add the egress route to the Registry, the 2062 originating SSP uses a valid regular expression to rewrite ingress 2063 route in order to include the egress SBE information. Also, more 2064 than one egress route can be associated with a given ingress route in 2065 support of fault-tolerant configurations. The supporting SPPP 2066 protocol structure provides a way to include route precedence 2067 information to help manage traffic to more than one outbound egress 2068 SBE. 2070 An egress route is identified by type EgrRteType and its object 2071 structure is shown below: 2073 2074 2075 2076 2077 2078 2079 2080 2082 2083 2084 2085 2086 2088 The EgrRteType object is composed of the following elements: 2090 o base: All first class objects extend BasicObjType which contains 2091 the ID of the registrant organization that owns this object, the 2092 ID of the registrar organization that provisioned this object, 2093 the date and time that the object was created by the server, and 2094 the date and time that the object was last modified. If the 2095 client passes in either the created date or the modification 2096 date, the server will ignore them. The server sets these two 2097 date/time values. 2099 o egrRteName: The name of the egress route. 2101 o pref: The preference of this egress route relative to other 2102 egress routes that may get selected when responding to a 2103 resolution request. 2105 o regxRewriteRule: The regular expression re-write rule that 2106 should be applied to the regular expression of the ingress 2107 NAPTR(s) that belong to the ingress route. 2109 o ingrRteRec: The ingress route records that the egress route 2110 should be used for. 2112 o ext: Point of extensibility described in a previous section of 2113 this document. 2115 The AddEgrRteRqstType request is used to create or overwrite an 2116 egress route. 2118 2119 2120 2121 2122 2123 2124 2125 2126 2128 An instance of AddEgrRtesRqstType is added in the spppUpdateRequest 2129 element in order to send a valid request to the server. Any 2130 limitation on the maximum number of AddEgrRteRqstType instances is a 2131 matter of policy and is not limited by the specification. 2133 The response from the server is returned in addEgrRteRspns element, 2134 which is defined as the element of type BasicRspnsType. 2136 The GetEgrRtesRqstType is used by an authorized entity to fetch the 2137 well-known egress route data. 2139 2140 2141 2142 2143 2145 2146 2147 2148 2150 6.14. Delete Operation 2152 In order to remove an object from the Registry, an authorized entity 2153 can send the to the Registry with a corresponding 2154 delete BasicUpdateRqstType object. Each 'Add' operation in SPPP has 2155 a corresponding 'Del' operation, which is used to delete the 2156 respective object type from the Registry. If the entity that issued 2157 the command is not authorized to perform this operation an 2158 appropriate error code will be returned in the 2159 message. 2161 As an example, DelPubIdRqstType is used to delete Public Identifiers 2162 The DelPubIdsRqstType object definition is shown below: 2164 2165 2166 2167 2168 2169 2170 2171 2172 2174 When an object is deleted, any references to that object must of 2175 course also be removed as the SPPP server implementation fulfills the 2176 deletion request. Furthermore, the deletion of a composite object 2177 must also result in the deletion of the objects it contains. As a 2178 result, the following rules apply to the deletion of SPPP object 2179 types: 2181 o Destination Groups: When a destination group is deleted all 2182 public identifiers within that destination group must also be 2183 automatically deleted by the SPPP implementation as part of 2184 fulfilling the deletion request. And any references between 2185 that destination group and any route group must be automatically 2186 removed by the SPPP implementation as part of fulfilling the 2187 deletion request. 2189 o Route Groups: When a route group is deleted any references 2190 between that route group and any destination group must be 2191 automatically removed by the SPPP implementation as part of 2192 fulfilling the deletion request. Similarly any references 2193 between that route group and any route records must be removed 2194 by the SPPP implementation as part of fulfilling the deletion 2195 request. Furthermore, route group offers relating that route 2196 group must also be deleted as part of fulfilling the deletion 2197 request. 2199 o Route Records: When a route record is deleted any references 2200 between that route record and any route group must be removed by 2201 the SPPP implementation as part of fulfilling the deletion 2202 request. 2204 o Puplic Identifiers: When a public identifier is deleted any 2205 references between that public identifier and its containing 2206 destination group must be removed by the SPPP implementation as 2207 part of fulfilling the deletion request. And any route records 2208 contained directly within that Public Identifier must be deleted 2209 by the SPPP implementation as part of fulfilling the deletion 2210 request. 2212 7. SPPP Examples 2214 This section shows XML message exchange between two SIP Service 2215 Providers (SSP) and a Registry. For the sake of simplicity, the 2216 transport wrapper for the SPPP protocol is left out. The SPPP 2217 protocol messages in this section are valid XML instances that 2218 conform to the SPPP schema version within this document. 2220 In this sample use case scenario, SSP1 and SSP2 provision resource 2221 data in the registry and use SPPP constructs to selectively share the 2222 route groups. In the figure below, SSP2 has two ingress SBE 2223 instances that are associated with the public identities that SSP2 2224 has the retail relationship with. Also, the two SBE instances for 2225 SSP1 are used to show how to use SPPP protocol to associate route 2226 preferences for the destination ingress routes and exercise greater 2227 control on outbound traffic to the peer's ingress SBEs. 2229 ---------------+ +------------------ 2230 | | 2231 +------+ +------+ 2232 | sbe1 | | sbe2 | 2233 +------+ +------+ 2234 SSP1 | | SSP2 2235 +------+ +------+ 2236 | sbe3 | | sbe4 | 2237 +------+ +------+ 2238 iana-en:111 | | iana-en:222 2239 ---------------+ +------------------ 2240 | | 2241 | | 2242 | SPPP +------------------+ SPPP | 2243 +------->| Registry |<--------+ 2244 +------------------+ 2246 7.1. Add Destination Group 2248 SSP2 adds a destination group to the Registry for use later. The 2249 SSP2 SPPP client sets a unique transaction identifier 'tx_7777' for 2250 tracking purposes. The name of the destination group is set to 2251 DEST_GRP_SSP2_1 2252 2253 2257 txid-5555 2258 2260 2261 iana-en:222 2262 iana-en:222 2263 DEST_GRP_SSP2_1 2264 2265 2266 2268 The Registry processes the request and return a favorable response 2269 confirming successful creation of the named destination group. Also, 2270 besides returning a unique transaction identifier, Registry also 2271 returns the matching client transaction identifier from the request 2272 message back to the SPPP client. 2274 2275 2279 tx_5555 2280 tx_id_12346 2281 2282 1000 2283 success 2284 2285 2287 7.2. Add Route Records 2289 SSP2 adds an ingress routes in the Registry. 2291 2292 2296 2298 2300 iana-en:222 2301 iana-en:222 2302 RTE_SSP2_SBE2 2303 10 2304 u 2305 E2U+sip 2306 2307 ^(.*)$ 2308 sip:\1@sbe2.ssp2.example.com 2309 2310 2311 2312 2314 The Registry returns a success response. 2316 2317 2321 tx_id_11145 2322 2323 1000 2324 Request successful 2325 2326 2328 7.3. Add Route Records -- URIType 2330 SSP2 adds another ingress routes in the Registry and makes use of 2331 URIType 2332 2333 2334 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 2335 xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 2336 xmlns="urn:ietf:params:xml:ns:sppp:base:1"> 2337 2339 2340 iana-en:222 2341 iana-en:222 2342 RTE_SSP2_SBE4 2343 ^(.*)$ 2344 sip:\1;npdi@sbe4.ssp2.example.com 2345 2346 2347 2349 The Registry returns a success response. 2351 2352 2356 tx_id_11145 2357 2358 1000 2359 Request successful 2360 2361 2363 7.4. Add Route Group 2365 SSP2 creates the grouping of the ingress routes and choses higher 2366 precedence for RTE_SSP2_SBE2 by setting a lower number for the 2367 "priority" attribute, a protocol agnostic precedence indicator. 2369 2370 2374 2376 2377 iana-en:222 2378 iana-en:222 2379 RTE_GRP_SSP2_1 2380 2381 2382 iana-en:222 2383 RTE_SSP2_SBE2 2384 2385 100 2386 2387 DEST_GRP_SSP2_1 2388 true 2389 10 2390 2391 2392 2394 To confirm successful processing of this request, Registry returns a 2395 well-known resolution code '1000' to the SSP2 client. 2397 2398 2402 tx_id_12345 2403 2404 1000 2405 Request successful 2406 2407 2409 7.5. Add Public Identity -- Successful COR claim 2411 SSP2 activates a TN public identity by associating it with a valid 2412 destination group. Further, SSP2 puts forth a claim that it is the 2413 carrier-of-record for the TN. 2415 2416 2419 txid-5577 2420 2422 2423 iana-en:222 2424 iana-en:222 2425 2010-05-30T09:30:10Z 2426 DEST_GRP_SSP2_1 2427 +12025556666 2428 2429 true 2430 2431 2432 2433 2435 Assuming that the Registry has access to TN authority data and it 2436 performs the required checks to verify that SSP2 is in fact the 2437 service provider of record for the given TN, the request is processed 2438 successfully. In the response message, the Registry sets the value 2439 of to "true" in order to confirm SSP2 claim as the carrier of 2440 record and the reflects the time when the carrier of record 2441 claim is processed. 2443 2444 2448 txid-5577 2449 tx_id_12345 2450 2451 1000 2452 success 2453 2454 2455 1000 2456 success 2457 2459 2460 iana-en:222 2461 iana-en:222 2462 2010-05-30T09:30:10Z 2463 DEST_GRP_SSP2_1 2464 +12025556666 2465 2466 true 2467 true 2468 2010-05-30T09:30:11Z 2469 2470 2471 2472 2473 2475 7.6. Add LRN 2477 If another entity that SSP2 shares the routes with has access to 2478 Number Portability data, it may choose to perform route lookups by 2479 routing number. Therefore, SSP2 associates a routing number to a 2480 destination group in order to facilitate ingress route discovery. 2482 2483 2486 2488 2490 iana-en:222 2491 iana-en:222 2492 DEST_GRP_SSP2_1 2493 2025550000 2494 2495 2496 2498 Registry completes the request successfully and returns a favorable 2499 response to the SPPP client. 2501 2502 2506 tx_id_12345 2507 2508 1000 2509 Request successful 2510 2511 2513 7.7. Add TN Range 2515 Next, SSP2 activates a block of ten thousand TNs and associate it to 2516 a destination group. 2518 2519 2522 2524 2525 iana-en:222 2526 iana-en:222 2527 DEST_GRP_SSP2_1 2528 +12026660000 2529 +12026669999 2530 2531 2532 2534 Registry completes the request successfully and returns a favorable 2535 response. 2537 2538 2542 tx_id_12244498 2543 2544 1000 2545 Request successful 2546 2547 2549 7.8. Add TN Prefix 2551 Next, SSP2 activates a block of ten thousand TNs using the TNPType 2552 structure and identifying a TN prefix. 2554 2555 2558 2560 2561 iana-en:222 2562 iana-en:222 2563 DEST_GRP_SSP2_1 2564 +1202777 2565 2566 2567 2569 Registry completes the request successfully and returns a favorable 2570 response. 2572 2573 2577 tx_id_12387698 2578 2579 1000 2580 Request successful 2581 2582 2584 7.9. Enable Peering -- Route Group Offer 2586 In order for SSP1 to complete session establishment for a destination 2587 TN where the target subscriber has a retail relationship with SSP2, 2588 it first requires an asynchronous bi-directional handshake to show 2589 mutual consent. To start the process, SSP2 initiates the peering 2590 handshake by offering SSP1 access to its route group. 2592 2593 2596 2598 2599 iana-en:222 2600 iana-en:222 2601 2602 2603 iana-en:222 2604 RTE_GRP_SSP2_1 2605 2606 iana-en:111 2607 2608 offered 2609 2006-05-04T18:13:51.0Z 2610 2611 2612 2614 Registry completes the request successfully and confirms that the 2615 SSP1 will now have the opportunity to weigh in on the offer and 2616 either accept or reject it. The Registry may employ out-of-band 2617 notification mechanisms for quicker updates to SSP1 so they can act 2618 faster, though this topic is beyond the scope of this document. 2620 2621 2625 tx_id_12277798 2626 2627 1000 2628 Request successful 2629 2630 2632 7.10. Enable Peering -- Route Group Offer Accept 2634 SSP1 responds to the offer from SSP2 and agrees to have visibility to 2635 SSP2 ingress routes. 2637 2638 2641 2643 2644 2645 iana-en:222 2646 RTE_GRP_SSP2_1 2647 2648 iana-en:111 2649 2650 2651 2653 Registry confirms that the request has been processed successfully. 2654 From this point forward, if SSP1 looks up a public identity through 2655 the query resolution server, where the public identity is part of the 2656 destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 2657 ingress SBE information will be shared with SSP1. 2659 2660 2664 tx_id_12333798 2665 2666 1000 2667 success 2668 2669 2671 7.11. Add Egress Route 2673 SSP1 wants to prioritize all outbound traffic to routes associated 2674 with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com". 2676 2677 2680 tx_9000 2681 2683 2684 iana-en:111 2685 2686 EGR_RTE_01 2687 50 2688 2689 ^(.*@)(.*)$ 2690 \1\2?route=sbe1.ssp1.example.com 2691 2692 2693 iana-en:222 2694 SSP2_RTE_REC_3 2695 2696 2697 2698 2700 Since peering has already been established, the request to add the 2701 egress route has been successfully completed. 2703 2704 2708 tx_9000 2709 tx_id_12388898 2710 2711 1000 2712 Request successful 2713 2715 2717 7.12. Get Destination Group 2719 SSP2 uses the 'GetDestGrpsRqstType' operation to tally the last 2720 provisioned record for destination group DEST_GRP_SSP2_1. 2722 2723 2726 2728 2729 iana-en:222 2730 DEST_GRP_SSP2_1 2731 2732 2733 2735 Registry completes the request successfully and returns a favorable 2736 response. 2738 2739 2742 2743 1000 2744 success 2745 2746 2748 iana-en:222 2749 iana-en:222 2750 DEST_GRP_SSP2_1 2751 2752 2754 7.13. Get Public Identity 2756 SSP2 obtains the last provisioned record associated with a given TN. 2758 2759 2762 2764 2766 iana-en:222 2767 iana-en:222 2768 +12025556666 2769 2770 2771 2773 Registry completes the request successfully and returns a favorable 2774 response. 2776 2777 2780 2781 1000 2782 success 2783 2784 2786 iana-en:222 2787 iana-en:222 2788 DEST_GRP_1 2789 +12025556666 2790 2791 true 2792 true 2793 2010-05-30T09:30:10Z 2794 2795 2796 2798 7.14. Get Route Group Request 2800 SSP2 obtains the last provisioned record for the route group 2801 RTE_GRP_SSP2_1. 2803 2804 2807 2809 2810 iana-en:222 2811 RTE_GRP_SSP2_1 2812 2813 2814 2816 Registry completes the request successfully and returns a favorable 2817 response. 2819 2820 2823 2824 1000 2825 success 2826 2827 2829 iana-en:222 2830 iana-en:222 2831 RTE_GRP_SSP2_1 2832 2833 2834 iana-en:222 2835 RTE_SSP2_SBE2 2836 2837 100 2838 2839 2840 2841 iana-en:222 2842 RTE_SSP2_SBE4 2843 2844 101 2845 2846 DEST_GRP_SSP2_1 2847 true 2848 10 2849 2850 2852 7.15. Get Route Group Offers Request 2854 SSP2 fetches the last provisioned route group offer to the 2855 SSP1. 2857 2858 2861 2863 iana-en:111 2865 2866 2868 Registry processes the request successfully and returns a favorable 2869 response. 2871 2872 2875 2876 1000 2877 success 2878 2879 2881 iana-en:222 2882 iana-en:222 2883 2884 2885 iana-en:222 2886 RTE_GRP_SSP2_1 2887 2888 iana-en:111 2889 2890 offered 2891 2006-05-04T18:13:51.0Z 2892 2893 2895 7.16. Get Egress Route 2897 SSP1 wants to verify the last provisioned record for the egress route 2898 called EGR_RTE_01. 2900 2901 2904 2906 2907 iana-en:111 2908 EGR_RTE_01 2909 2910 2911 2913 Registry completes the request successfully and returns a favorable 2914 response. 2916 2917 2920 2921 1000 2922 success 2923 2924 2926 iana-en:111 2927 iana-en:111 2928 EGR_RTE_01 2929 50 2930 E2U+sip 2931 2932 ^(.*)$ 2933 sip:\1@sbe1.ssp1.example.com 2934 2935 2936 iana-en:222 2937 RTE_GRP_SSP2_1 2938 2939 2940 2942 7.17. Delete Destination Group 2944 SSP2 initiates a request to delete the destination group 2945 DEST_GRP_SSP2_1. 2947 2948 2951 2953 2954 iana-en:222 2955 DEST_GRP_SSP2_1 2956 2957 2958 2960 Registry completes the request successfully and returns a favorable 2961 response. 2963 2964 2967 txid-982543123 2968 2969 1000 2970 Success 2971 2972 2974 7.18. Delete Public Identity 2976 SSP2 choses to de-activate the TN and remove it from the Registry. 2978 2979 2982 2984 2986 iana-en:222 2987 iana-en:222 2988 +12025556666 2989 2990 2991 2993 Registry completes the request successfully and returns a favorable 2994 response. 2996 2997 3000 txid-98298273123 3001 3002 1000 3003 success 3004 3005 3007 7.19. Delete Route Group Request 3009 SSP2 removes the route group called RTE_GRP_SSP2_1. 3011 3012 3015 3017 3018 iana-en:222 3019 RTE_GRP_SSP2_1 3020 3021 3022 3024 Registry completes the request successfully and returns a favorable 3025 response. 3027 3028 3031 txid-982543123 3032 3033 1000 3034 msg 3035 3036 3038 7.20. Delete Route Group Offers Request 3040 SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1. 3042 3043 3046 3048 3049 3050 iana-en:222 3051 RTE_GRP_SSP2_1 3052 3053 iana-en:111 3054 3055 3056 3058 Registry completes the request successfully and returns a favorable 3059 response. Restoring this resource sharing will require a new route 3060 group offer from SSP2 to SSP1 followed by a successful route group 3061 accept request from SSP1. 3063 3064 3067 txid-982543123 3068 3069 1000 3070 Success 3071 3072 3074 7.21. Delete Egress Route 3076 SSP1 decides to remove the egress route with the label EGR_RTE_01. 3078 3079 3082 3084 3085 iana-en:111 3086 EGR_RTE_01 3087 3088 3089 3091 Registry completes the request successfully and returns a favorable 3092 response. 3094 3095 3098 txid-982543123 3099 3100 1000 3101 Success 3102 3103 3105 8. XML Considerations 3107 XML serves as the encoding format for SPPP, allowing complex 3108 hierarchical data to be expressed in a text format that can be read, 3109 saved, and manipulated with both traditional text tools and tools 3110 specific to XML. 3112 XML is case sensitive. Unless stated otherwise, XML specifications 3113 and examples provided in this document MUST be interpreted in the 3114 character case presented to develop a conforming implementation. 3116 This section discusses a small number of XML-related considerations 3117 pertaining to SPPP. 3119 8.1. Namespaces 3121 All SPPP protocol elements are defined in the namespaces in the IANA 3122 Considerations section and in the Formal Protocol Specification 3123 section of this document. 3125 8.2. Versioning and Character Encoding 3127 All XML instances SHOULD begin with an declaration to 3128 identify the version of XML that is being used, optionally identify 3129 use of the character encoding used, and optionally provide a hint to 3130 an XML parser that an external schema file is needed to validate the 3131 XML instance. 3133 Conformant XML parsers recognize both UTF-8 (defined in [RFC3629]) 3134 and UTF-16 (defined in [RFC2781]); per [RFC2277] UTF-8 is the 3135 RECOMMENDED character encoding for use with SPPP. 3137 Character encodings other than UTF-8 and UTF-16 are allowed by XML. 3138 UTF-8 is the default encoding assumed by XML in the absence of an 3139 "encoding" attribute or a byte order mark (BOM); thus, the "encoding" 3140 attribute in the XML declaration is OPTIONAL if UTF-8 encoding is 3141 used. SPPP clients and servers MUST accept a UTF-8 BOM if present, 3142 though emitting a UTF-8 BOM is NOT RECOMMENDED. 3144 Example XML declarations: 3146 version="1.0" encoding="UTF-8" standalone="no"?> 3148 9. Security Considerations 3150 SPPP implementations manage data that is considered confidential and 3151 critical. Furthermor, SPPP implementations can support provisioning 3152 activities for multiple registrars and registrants. As a result any 3153 SPPP implementation must address the requirements for 3154 confidentiality, authentication, and authorization. 3156 With respect to confidentiality and authentication, the transport 3157 protocol section contains some security properties that the transport 3158 protocol must provide so that authenticated endpoints can exchange 3159 data confidentially and with integrity protection. 3161 With respect to authorization, the SPPP server implementation must 3162 define and implement a set of authorization rules that precisely 3163 address (1) which registrars will be authorized to create/modify/ 3164 delete each SPPP object type for given registrant(s) and (2) which 3165 registrars will be authorized to view/get each SPPP object type for a 3166 given registrant(s). These authorization rules are left as a matter 3167 of policy and are not specified within the context of SPPP. However, 3168 any SPPP implementation must specify these authorization rules in 3169 order to function in a realiable and safe manner. 3171 10. IANA Considerations 3173 This document uses URNs to describe XML namespaces and XML schemas 3174 conforming to a registry mechanism described in [RFC3688]. 3176 Two URI assignments are requested. 3178 Registration request for the SPPP XML namespace: 3179 urn:ietf:params:xml:ns:sppp:base:1 3180 Registrant Contact: IESG 3181 XML: None. Namespace URIs do not represent an XML specification. 3183 Registration request for the XML schema: 3184 URI: urn:ietf:params:xml:schema:sppp:1 3185 Registrant Contact: IESG 3186 XML: See the "Formal Specification" section of this document 3187 (Section 11). 3189 IANA is requested to create a new SPPP registry for Organization 3190 Identifiers that will indicate valid strings to be used for well- 3191 known enterprise namespaces. 3192 This document makes the following assignments for the OrgIdType 3193 namespaces: 3195 Namespace OrgIdType namespace string 3196 ---- ---------------------------- 3197 IANA Enterprise Numbers iana-en 3199 11. Formal Specification 3201 This section provides the draft XML Schema Definition for the SPPP 3202 protocol. 3204 3205 3209 3210 3211 ------------------ Object Type Definitions -------------- 3212 3213 3214 3215 3216 3217 3218 3219 3221 3223 3225 3227 3228 3229 3230 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 3259 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3284 3285 3286 3287 3288 3289 3290 3291 3292 3293 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312 3313 3314 3315 3316 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3344 3345 3346 3347 3348 3349 3350 3351 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3370 3371 3372 3373 3374 3375 3376 ------------------ Abstract Object and Element 3377 Type Definitions -------------- 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389 3390 3391 3392 3393 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 3424 3425 3426 3427 3428 3429 3430 3431 3432 3433 3434 3435 3436 3437 3439 3440 3441 3442 3443 3444 3445 3447 3448 3450 3451 3452 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 -------------- Operation Request and Response 3477 Object Type Definitions ------------ 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3506 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3530 3531 3532 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3559 3560 3561 3562 3564 3565 3566 3567 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3616 3617 3618 3619 3620 3621 3622 3623 3624 3625 3626 3627 3628 3629 3630 3631 3632 3633 3635 3636 3637 3638 3639 3640 3641 3642 3643 3645 3646 3647 3648 3649 3650 3651 3652 3653 3655 3656 3657 3658 3659 3660 3661 3662 3663 3665 3667 3669 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3700 3701 3702 3703 3704 3705 -------- Generic Request and Response Definitions 3706 --------------- 3707 3708 3709 3710 3711 3713 3715 3717 3718 3719 3720 3721 3722 3723 3725 3726 3727 3730 3731 3732 3733 3734 3735 3736 3738 3739 3740 3741 3742 3743 3744 3745 3746 3748 3749 3750 3751 3752 3753 3754 3756 3757 3758 3759 3760 3761 3762 3763 3764 3765 3766 3767 3768 12. Acknowledgments 3770 This document is a result of various discussions held in the DRINKS 3771 working group and within the DRINKS protocol design team, which is 3772 comprised of the following individuals, in alphabetical order: 3773 Alexander Mayrhofer, Deborah A Guyton, David Schwartz, Lisa 3774 Dusseault, Manjul Maharishi, Mickael Marrache, Otmar Lendl, Richard 3775 Shockey, Samuel Melloul, and Sumanth Channabasappa. 3777 13. References 3779 13.1. Normative References 3781 [I-D.ietf-drinks-sppp-over-soap] 3782 Cartwright, K., "SPPP Over SOAP and HTTP", 3783 draft-ietf-drinks-sppp-over-soap-02 (work in progress), 3784 February 2011. 3786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3787 Requirement Levels", BCP 14, RFC 2119, March 1997. 3789 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 3790 Languages", BCP 18, RFC 2277, January 1998. 3792 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 3793 10646", STD 63, RFC 3629, November 2003. 3795 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 3796 January 2004. 3798 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 3799 Resource Identifier (URI): Generic Syntax", STD 66, 3800 RFC 3986, January 2005. 3802 13.2. Informative References 3804 [I-D.ietf-drinks-usecases-requirements] 3805 Channabasappa, S., "DRINKS Use cases and Protocol 3806 Requirements", draft-ietf-drinks-usecases-requirements-04 3807 (work in progress), October 2010. 3809 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 3810 10646", RFC 2781, February 2000. 3812 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 3813 A., Peterson, J., Sparks, R., Handley, M., and E. 3814 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 3815 June 2002. 3817 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 3818 Resource Identifiers (URI) Dynamic Delegation Discovery 3819 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 3821 [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation 3822 Architecture", RFC 4725, November 2006. 3824 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 3825 October 2008. 3827 [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia 3828 Interconnect (SPEERMINT) Terminology", RFC 5486, 3829 March 2009. 3831 Authors' Addresses 3833 Jean-Francois Mule 3834 CableLabs 3835 858 Coal Creek Circle 3836 Louisville, CO 80027 3837 USA 3839 Email: jfm@cablelabs.com 3841 Kenneth Cartwright 3842 TNS 3843 1939 Roland Clarke Place 3844 Reston, VA 20191 3845 USA 3847 Email: kcartwright@tnsi.com 3849 Syed Wasim Ali 3850 NeuStar 3851 46000 Center Oak Plaza 3852 Sterling, VA 20166 3853 USA 3855 Email: syed.ali@neustar.biz 3857 Alexander Mayrhofer 3858 enum.at GmbH 3859 Karlsplatz 1/9 3860 Wien, A-1010 3861 Austria 3863 Email: alexander.mayrhofer@enum.at