One document matched: draft-ietf-drinks-sppp-over-soap-07.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3688 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
<!ENTITY rfc5246 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc2617 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY rfc2616 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2818 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY rfc5321 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
]>
<rfc category="std" docName="draft-ietf-drinks-sppp-over-soap-07" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="draft-ietf-drinks-sppp-over-soap">SPPP Over SOAP and HTTP</title>
<author initials='K.C.' surname="Cartwright" fullname='Kenneth Cartwright'>
<organization>TNS</organization>
<address>
<postal>
<street>1939 Roland Clarke Place</street>
<city>Reston</city> <region>VA</region>
<code>20191</code>
<country>USA</country>
</postal>
<email>kcartwright@tnsi.com</email>
</address>
</author>
<author initials='V.B.' surname="Bhatia" fullname='Vikas Bhatia'>
<organization>TNS</organization>
<address>
<postal>
<street>1939 Roland Clarke Place</street>
<city>Reston</city> <region>VA</region>
<code>20191</code>
<country>USA</country>
</postal>
<email>vbhatia@tnsi.com</email>
</address>
</author>
<date year="2011" month="November"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t>The Session Peering Provisioning Protocol (SPPP) is an XML protocol
that exists to enable the provisioning of session establishment data into
Session Data Registries or SIP Service Provider data stores. Sending XML
data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is
a widely used, de-facto standard for messaging between elements of
provisioning systems. Therefore the combination of SOAP and HTTP(s) as
a transport for SPPP is a natural fit. The obvious benefits include
leveraging existing industry expertise, leveraging existing standards,
and a higher probability that existing provisioning systems can be more
easily integrated with this protocol. This document describes the
specification for transporting SPPP XML structures over SOAP and HTTP(s).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>SPPP, defined in <xref target="I-D.draft-ietf-drinks-spprov"/>,
is best supported by a transport and messaging infrastructure
that is connection oriented, request-response oriented, easily secured,
supports propagation through firewalls in a standard fashion, and that
is easily integrated into back-office systems. This is due to the fact that
the client side of SPPP is likely to be integrated with organizations'
operational support systems that facilitate transactional provisioning of user
addresses and their associated session establishment data. While the server
side of SPPP is likely to reside in a separate organization's network, resulting
the SPPP provisioning transactions traversing the Internet as
they are propagated from the SPPP client to the SPPP server. Given the
current state of industry practice and technologies,
SOAP and HTTP(s) are well suited for this type of environment. This document
describes the specification for transporting SPPP XML structures over
SOAP and HTTP(s).</t>
<t>The specification in this document for transporting SPPP XML structures
over SOAP and HTTP(s) is primarily comprised of five subjects: (1) a
description of any applicable SOAP features, (2) any applicable HTTP
features, (3) security considerations, and perhaps most importantly,
(4) the Web Services Description Language (WSDL) definition for SPPP over
SOAP, and (5) "transport" specific XML schema type definitions</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section anchor="SOAPFeatures" title="SOAP Features and Protocol Layering">
<t>The list of SOAP features that are explicitly used and required for SPPP are limited. Most SOAP features are not necessary for SPPP. SPPP primarily uses SOAP simply as a standard message envelope technology. The SOAP message envelope is comprised of the SOAP header and body. As described in the SOAP specifications, the SOAP header can contain optional, application specific, information about the message. The SOAP body contains the SPPP message itself, whose structure is defined by the combination of one of the WSDL operations defined in this document and the SPPP XML data structures defined in this document and the SPPP protocol document. SPPP does not rely on any data elements in the SOAP header. All relevant data elements are defined in the SPPP XML schema described in <xref target="I-D.draft-ietf-drinks-spprov"/> and the SPPP WSDL types specification described in this document.</t>
<t>WSDL is a widely standardized and adopted technology for defining the top-level structures of the messages that are transported within the body of a SOAP message. The WSDL definition for the SPPP SOAP messages is defined later in this document, which imports by reference the XML data types contained in the SPPP schema. The IANA registry where the SPPP schema resides is described in The IETF XML Registry <xref target="RFC3688"/>.</t>
<t>There are multiple structural styles that SOAP WSDL allows. But the best practice for this type of application is what is sometimes referred to as the Document Literal Wrapped style of designing SOAP WSDL. This style is generally regarded as an optimal approach that enhances maintainability, comprehension, portability, and, to a certain extent, performance. It is characterized by setting the soapAction binding style as _document_, the soapAction encoding style as _literal_, and then defining the SOAP messages to simply contain a single data element that _wraps_ a data structure containing all the required input or output data elements. The figure below illustrates this high level technical structure as conceptual layers 3 through 6.</t>
<figure anchor="TechnicalStructureofSPPP"
title="Layering and Technical Structure of the SPPP SOAP Messages">
<artwork align="left"><![CDATA[
+-------------+
(1) | Transport |Example:
| Protocol | TCP, TLS, BEEP, etc.
+-------------+
|
V
+-------------+
(2) | Message |Example:
| Envelope | HTTP, SOAP, None, etc.
+-------------+
|
V
+--------------+
+------| SOAP |-----+
| (3) | Operation | |
Contains | +--------------+ | Contains
| Example: |
V submitAddRqst V
+--------------+ +-------------+
|SOAP Request | |SOAP Response|
Example:| Message | (4) | Message | Example:
spppAdd | (Operation | | (Operation | spppAdd
RequestMsg | Input) | | Output) | ResponseMsg
+--------------+ +-------------+
| |
Contains | | Contains
| |
V V
+---------------+ +---------------+
Example:| Wrapped | (5) | Wrapped | Example:
spppAdd |Request Object | |Response Object| spppAdd
Request +---------------+ +---------------+ Response
| |
Contains | | Contains
| |
V V
+-------------+ +---------------+
| SPPP | | SPPP |
|XML Types | (6) | XML Types |
+-------------+ +---------------+
]]></artwork>
</figure>
<t>The SOAP operations supported by SPPP are normatively defined later in this
document. Each SOAP operation defines a request/input message and a
response/output message. Each such request and response message then
contains a single object that wraps the SPPP XML data types that comprise
the inputs and the outputs, respectively, of the SOAP operation.</t>
<t>SOAP faults are not used by the SPPP SOAP mapping. All SPPP success
and error responses are specified in the "Response Codes and Messages" section of this document.
However, if a SOAP fault were
to occur, perhaps due to failures in the SOAP message handling layer of a SOAP
library, the client application should capture and handle the fault. Specifics
on how to handle such SOAP faults, if they should occur, will be specific to
the chosen SOAP implementation. </t>
<t>SOAP 1.2 <xref target="SOAPREF"/> or higher and WSDL 1.1 <xref target="WSDLREF"/> or higher SHOULD be used.</t>
<t> SPPP is a request/reply protocol that allows a
client application to submit provisioning data and query
requests to a server. The SPPP data structures are designed
to be protocol agnostic. Concerns regarding encryption,
non-repudiation, and authentication are beyond the scope of
this document. For more details, please refer to the
"Transport Protocol Requirements" section in the protocol document. </t>
<t> As illustrated in the previous diagram, SPPP can be viewed as
a set of layers that collectively
define the structure of an SPPP request and response. Layers
1 and 2 represent the transport, envelope, and authentication
technologies. This
document defines layers 3, 4, 5, and 6 below. </t>
<t>
<list style="numbers">
<t> Layer 1: The transport protocol layer represents the communication
mechanism between the client and server. SPPP can be
layered over any transport protocol that provides a set
of basic requirements defined in the Transport Protocol
Requirements section. But this document specifies the required
mechanism.</t>
<t> Layer 2: The message envelope layer is optional, but can
provide features that are above the transport technology
layer but below the application messaging layer.
Technologies such as HTTP and SOAP are examples of
messaging envelope technologies. This document specifies the required
envelope technology.</t>
<t> Layers 3,4,5,6: The operation and message layers provides an
envelope-independent and transport-independent
wrapper for the SPPP data model objects that are being acted on (created,
modified, queried). </t>
</list>
</t>
</section>
<section anchor="HTTPFeatures" title="HTTP(s) Features and SPPP">
<t>SOAP is not tied to HTTP(s), however, for reasons described in the
introduction, HTTP(s) is a good choice as the transport mechanism for
the SPPP SOAP messages. HTTP 1.1 includes the "persistent connection"
feature, which allows multiple HTTP request/response pairs to be transported
across a single HTTP connection. This is an important performance
optimization feature, particularly when the connections is an HTTPS
connection where the relatively time consuming SSL handshake has occurred.
Persistent connections SHOULD be used for the SPPP HTTP connections.</t>
<t>HTTP 1.1 <xref target="RFC2616"/> or higher SHOULD be used.</t>
</section>
<section anchor="AuthenticationSessionManagement" title="Authentication and Session Management">
<t>To achieve integrity and privacy, conforming SPPP SOAP Clients and Servers MUST support SOAP over HTTP over TLS <xref target="RFC5246"/> as the secure transport mechanism. This combination of HTTP and TLS is referred to as HTTPS. And to accomplish authentication, conforming SOAP SPPP Clients and Servers MUST use HTTP Digest Authentication as defined in <xref target="RFC2617"/>. As a result, the communication session is established through the initial HTTP connection setup, the digest authentication, and the TLS handshake. When the HTTP connection is broken down, the communication session ends.</t>
</section>
<section anchor="basicdatastructures" title="SPPP SOAP Data Structures">
<t>SPPP over SOAP uses a set of XML based data structures for all the supported operations
and any parameters that those operations are applied to. As also mentioned earlier in this document, these XML structures
are envelope-independent and transport-independent. Refer the "Protocol Operations" section of document for
a description of all the operations that MUST be supported.</t>
<t>The following sections describe the definition all the XML data structures. </t>
<section anchor="concreteobjkeys" title="Concrete Object Key Types">
<t>Certain SPPP operations require an object key that uniquely identifies the object on which a given operation
needs to be performed. The following sub-sections define the various types of
concrete object key types used in certain operations: </t>
<section anchor="objectkey" title="Generic Object Key">
<t>
Most objects in SPPP are unqiuely identified by the attributes in the concrete ObjKeyType. The definition
of ObjKeyType is as below:</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="ObjKeyType">
<complexContent>
<extension base="spppb:ObjKeyType">
<sequence>
<element name="rant" type="spppb:OrgIdType"/>
<element name="name" type="spppb:ObjNameType"/>
<element name="type" type="spppb:ObjKeyTypeEnum"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The ObjKeyType has the data elements as described below:
<list style="symbols" hangIndent="5">
<t>rant: The identifier of the registrant organization that owns the object.</t>
<t>name: The character string that contains the name of the object.</t>
<t>type: The enumeration vaue that represents the type of SPPP object.</t>
</list>
</t>
</section>
<section anchor="pubidkey" title="Public Identity Object Key">
<t>
Public Identity type objects can further be of various sub-types like a TN, RN, TN Prefix, or a TN Range and cannot be cleanly identified
with the attributes in the generic ObjKeyType. The definition of PubIdKeyType is as below:</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="PubIdKeyType">
<complexContent>
<extension base="spppb:PubIdKeyType">
<sequence>
<element name="rant" type="spppb:OrgIdType"/>
<element name="dgName" type="spppb:ObjNameType" minOccurs="0"/>
<choice>
<element name="number"
type="spppb:NumberType"/>
<element name="range"
type="spppb:NumberRangeType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The PubIdKeyType has the data elements as described below:
<list style="symbols" hangIndent="5">
<t>rant: The identifier of the registrant organization that owns the object.</t>
<t>dgName: The name of the Destination Group that a Public Identifier is member of. Note that this is an optional attribute of the key as Public Identifiers may or may not be provisioned
as members of a Destination Group. </t>
<t>number: An element of type NumberType (refer protocol document) that contains the value and type of a
the number .</t>
<t>range: An element of type NumberRangeType (refer protocol document) that contains a rage of numbers.</t>
</list>
It is MUST that only one of the "number" and "range" elements appears in a PubIdKeyType instance.
</t>
</section>
<section anchor="rtegrpofferkey" title="Route Group Offer Key">
<t>
In addition to the attributes in the generic ObjKeyType, a Route Group Offer object is uniquely identified by the organization ID of the organization
to whom an Route Group has been offered. The definition of RteGrpOfferKeyType is as below:</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<complexType name="RteGrpOfferKeyType">
<complexContent>
<extension base="spppb:RteGrpOfferKeyType">
<sequence>
<element name="rteGrpKey" type="sppps:ObjKeyType"/>
<element name="offeredTo" type="spppb:OrgIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> The RteGrpOfferKeyType has the data elements as described below:
<list style="symbols" hangIndent="5">
<t>rteGrpKey: Identifies the Route Group that was offered.</t>
<t>offeredTo: The organization ID of the organization that was offered the Route Group object identified by the rteGrpKey.</t>
</list>
</t>
</section>
</section>
<section anchor="requestandresponse" title="Operation Request and Response Structures">
<t> An SPPP client interacts with an SPPP server by using one of
the supported transport mechanisms to send one or more
requests to the server and receive corresponding replies from
the server. The basic set of operations that an SPPP
client can submit to an SPPP server and the semantics of those operations are defined in the "Protocol Operations" section of the protocol document. The following
sub-sections describe the XML data structures that are used for each of those types of operations for a SOAP based SPPP implementation. </t>
<section anchor="addsandmods" title="Add Operation Structure">
<t>In order to add (or modify) an object in the registry, an authorized entity
can send the spppAddRequest to the registry.</t>
<t>An SPPP Add request is wrapped within the
<![CDATA[<spppAddRequest> ]]> element while an SPPP Add response is
wrapped within an <![CDATA[<spppAddResponse>]]> element.
The following sub-sections describe the spppAddRequest and spppAddResponse elements.
Refer the "SPPP SOAP Examples" section of this document for an example of Add operation on each type of SPPP object.</t>
<section anchor="addrqst" title="Add Request">
<t> An SPPP Add request definition is contained within the generic
<![CDATA[<spppAddRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppAddRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="obj" type="spppb:BasicObjType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<simpleType name="TransIdType">
<restriction base="string"/>
</simpleType>
<simpleType name="MinorVerType">
<restriction base="unsignedLong"/>
</simpleType>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppAddRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> obj: One or more elements of abstract type BasicObjType (defined in the protocol document). Each element contains all the attributes of an SPPP object that that the client is requesting the SPPP server to add. Refer the "Protocol Data Model Objects"
section of the protocol document for the XML structure of all concrete types, for various SPPP objects,
that extend from abstract BasicObjType and hence are eligible to be passed into this element. The elements are processed
by the SPPP server in the order in which they are included in the request.
With respect to handling of error conditions, it is a matter of policy
whether the objects are processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing BasicObjType elements in the
request at the first error and roll back any BasicObjType elements
that had already been processed for that add request.
In the "stop and commit" scenario the SPPP server would stop
processing BasicObjType elements in the request at the
first error but commit any BasicObjType elements
that had already been processed for that add request.
</t>
</list>
</t>
</section>
<section anchor="addresponse" title="Add Response">
<t> An SPPP add response object is contained within the generic
<![CDATA[<spppAddResponse>]]> element. This response structure is used for all
types of SPPP objects that are provisioned by the SPPP client.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppAddResponse">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="dtlResult" type="sppps:ObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="string"/>
</sequence>
</complexType>
<complexType name="ObjResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="obj" type="spppb:BasicObjType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppAddResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the request, and if an error occurred, it provides
information about the specific object(s) that
caused the error. </t>
<t> The data elements within the SPPP Add response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> dtlResult: An optional response code, response message,
and BasicObjType (as defined in the protocol document) triplet. This element will be present only if an object level error has occurred.
It indicates the error condition and the exact request object that contributed to the error. The response code will reflect the exact error.
See the Response Code section for further details.</t>
</list>
</t>
</section>
</section>
<section anchor="dels" title="Delete Operation Structure">
<t>In order to remove an object from the registry, an authorized entity
can send the spppDelRequest into the registry. An SPPP Del request is wrapped within the
<![CDATA[<spppDelRequest> ]]> element while a SPPP Del response is
wrapped within the generic <![CDATA[<spppDelResponse>]]> element.
The following sub-sections describe the spppDelRequest and spppDelResponse elements. Refer the "SPPP SOAP Examples" section of this document for an example of Delete operation on each type of SPPP object.</t>
<section anchor="delrqst" title="Delete Request">
<t> An SPPP Del request definition is contained within the generic
<![CDATA[<spppDelRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppDelRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="objKey" type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppDelRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> objKey: One or more elements of abstract type ObjKeyType (as defined in the protocol document). Each element contains attributes that uniquely identify
the object that the client is requesting the server to delete. Refer the "Concrete Object Keys" section of this document
for a description of all concrete object key types, for various SPPP objects, which are eligible to be passed into this element. The elements are processed
by the SPPP server in the order in which they are included in the request.
With respect to handling of error conditions, it is a matter of policy
whether the objects are processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing ObjKeyType elements in the
request at the first error and roll back any ObjKeyType elements
that had already been processed for that delete request.
In the "stop and commit" scenario the SPPP server would stop
processing ObjKeyType elements in the request at the
first error but commit any KeyParamType elements
that had already been processed for that delete request.
</t>
</list>
</t>
</section>
<section anchor="delresponse" title="Delete Response">
<t> An SPPP delete response object is contained within the generic
<![CDATA[<sppDeleteResponse>]]> element. This response structure is used for a delete request on all
types of SPPP objects that are provisioned by the SPPP client.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppDelResponse">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="dtlResult" type="sppps:ObjKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="string"/>
</sequence>
</complexType>
<complexType name="ObjKeyResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppDelResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the request, and if an error occurred, it provides
information about the specific object key(s) that
caused the error. </t>
<t> The data elements within the SPPP Delete response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> dtlResult: An optional response code, response message,
and ObjKeyType (as defined in the protocol document) triplet. This element will be present only if an specific object key level error has occurred.
It indicates the error condition and the exact request object key that contributed to the error. The response code will reflect the exact error.
See the Response Code section for further details.</t>
</list>
</t>
</section>
</section>
<section anchor="accepts" title="Accept Operation Structure">
<t>In SPPP, a Route Group Offer can be accepted or rejected by, or on behalf of, the registrant to
whom the Route Group has been offered (refer "Protocol Data Model Objects" section of the protocol document for a description
of the Route Group Offer object). The Accept operation is used to accept such Route Group Offers by, or on
behalf of, the Registrant. The request structure for an SPPP Accept operation is wrapped within the
<![CDATA[<spppAcceptRequest> ]]> element while an SPPP Accept response is
wrapped within the generic <![CDATA[<spppAcceptResponse>]]> element.
The following sub-sections describe the spppAcceptRequest and spppAcceptResponse elements. Refer the "SPPP SOAP Examples" section of this document for an example of Accept operation on a Route Group Offer.</t>
<section anchor="acceptrqst" title="Accept Request Structure">
<t> An SPPP Accept request definition is contained within the generic
<![CDATA[<sppAcceptRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppAcceptRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppAcceptRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType (as defined in this document). Each element contains attributes that uniquely identify
a Route Group Offer that the client is requesting the server to accept. The elements are processed
by the SPPP server in the order in which they are included in the request.
With respect to handling of error conditions, it is a matter of policy
whether the objects are processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing RteGrpOfferKeyType elements in the
request at the first error and roll back any RteGrpOfferKeyType elements
that had already been processed for that accept request.
In the "stop and commit" scenario the SPPP server would stop
processing RteGrpOfferKeyType elements in the request at the
first error but commit any RteGrpOfferKeyType elements
that had already been processed for that accept request.
</t>
</list>
</t>
</section>
<section anchor="acceptresponse" title="Accept Response">
<t> An SPPP accept response structure is contained within the generic
<![CDATA[<sppAcceptResponse>]]> element. This response structure is used for an Accept request on a Route Group Offer.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppAcceptResponse">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="dtlResult"
type="sppps:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="string"/>
</sequence>
</complexType>
<complexType name="RteGrpOfferKeyResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="rteGrpOfferKey" type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppAcceptResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the request, and if an error occurred, it provides
information about the specific Route Group Offer key(s) that
caused the error. </t>
<t> The data elements within the SPPP Accept response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> dtlResult: An optional response code, response message,
and RteGrpOfferKeyType (as defined in this document) triplet. This element will be present only if any specific Route Group Offer key level error has occurred.
It indicates the error condition and the exact request Route Group Offer key that contributed to the error. The response code will reflect the exact error.
See the Response Code section for further details.</t>
</list>
</t>
</section>
</section>
<section anchor="rejects" title="Reject Operation Structure">
<t>In SPPP, Route Group Offer can be accepted or rejected by, or on behalf of, the registrant to
whom the Route Group has been offered (refer "Protocol Data Model Objects" section of this document for a description
of the Route Group Offer object). The Reject operation is used to reject such Route Group Offers by, or on
behalf of, the Registrant. The request structure for an SPPP Reject operation is wrapped within the
<![CDATA[<spppRejectRequest> ]]> element while an SPPP Reject response is
wrapped within the generic <![CDATA[<spppRejecResponse>]]> element.
The following sub-sections describe the spppRejectRequest and spppRejecResponse elements. Refer the "SPPP SOAP Examples" section of this document for an example of Reject operation on a Route Group Offer.</t>
<section anchor="rejectrqst" title="Reject Request">
<t> An SPPP Reject request definition is contained within the generic
<![CDATA[<spppRejectRequest>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppRejectRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
maxOccurs="unbounded"/>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppRejectRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t>rteGrpOfferKey: One or more elements of type RteGrpOfferKeyType (as defined in this document). Each element contains attributes that uniquely identify
a Route Group Offer that the client is requesting the server to reject. The elements are processed
by the SPPP server in the order in which they are included in the request.
With respect to handling of error conditions, it is a matter of policy
whether the objects are processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing RteGrpOfferKeyType elements in the
request at the first error and roll back any RteGrpOfferKeyType elements
that had already been processed for that reject request.
In the "stop and commit" scenario the SPPP server would stop
processing RteGrpOfferKeyType elements in the request at the
first error but commit any RteGrpOfferKeyType elements
that had already been processed for that reject request.
</t>
</list>
</t>
</section>
<section anchor="rejectresponse" title="Reject Response">
<t> An SPPP reject response structure is contained within the generic
<![CDATA[<sppRejectResponse>]]> element. This response structure is used for an Reject request on a Route Group Offer.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppRejectResponse">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="overallResult" type="spppb:ResultCodeType"/>
<element name="dtlResult"
type="sppps:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="string"/>
</sequence>
</complexType>
<complexType name="RteGrpOfferKeyResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="rteGrpOfferKey" type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppRejectResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the request, and if an error occurred, it provides
information about the specific Route Group Offer key(s) that
caused the error. </t>
<t> The data elements within the SPPP Reject response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> dtlResult: An optional response code, response message,
and RteGrpOfferKeyType (as defined in this document) triplet. This element will be present only if any specific Route Group Offer key level error has occurred.
It indicates the error condition and the exact request Route Group Offer key that contributed to the error. The response code will reflect the exact error.
See the Response Code section for further details.</t>
</list>
</t>
</section>
</section>
<section anchor="batchopn" title="Batch Operation Structure">
<t>An SPPP Batch request XML structure allows the SPPP client to send any of
of Add, Del, Accept or Reject operations together in one single request. This gives an SPPP Client the
flexibility to use one single request structure to perform more than operations (verbs).
The batch request structure is wrapped within the
<![CDATA[<spppBatchRequest> ]]> element while a SPPP Batch response is
wrapped within the <![CDATA[<spppBatchResponse>]]> element.
This following sub-sections describe the spppBatchRequest and spppBatchResponse elements. Refer the "SPPP SOAP Examples" section of this document for an example of a batch operation.</t>
<section anchor="batchreq" title="Batch Request Structure">
<t> An SPPP Batch request definition is contained within the generic
<![CDATA[<spppBatchRequest>]]> element.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppBatchRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<choice minOccurs="1" maxOccurs="unbounded">
<element name="addObj" type="spppb:BasicObjType"/>
<element name="delObj" type="spppb:ObjKeyType"/>
<element name="acceptRteGrpOffer"
type="sppps:RteGrpOfferKeyType"/>
<element name="rejectRteGrpOffer"
type="sppps:RteGrpOfferKeyType"/>
</choice>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<sppBatchRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client-generated transaction ID
that, within the context of the SPPP client, identifies this
request. This value can be used at the discretion of the SPPP
client to track, log or correlate requests and their responses. SPPP server MUST echo back this value to the client in the corresponding response to the incoming request.
SPPP server will not check this value for uniqueness. </t>
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t>addObj: One or more elements of abstract type BasicObjType where each element identifies an object that needs to be added.</t>
<t>delObj: One or more elements of abstract type ObjKeyType where each element identifies a key for the object that needs to be deleted .</t>
<t>acceptRteGrpOffer: One or more elements of type RteGrpOfferKeyType where each element identifies a Route Group Offer that needs to be accepted.</t>
<t>rejectRteGrpOffer: One or more elements of type RteGrpOfferKeyType where each element identifies a Route Group Offer that needs to be rejected.</t>
</list>
</t>
<t>With respect to handling of error conditions, it is a matter of policy
whether the batch operation processed in a "stop and rollback" fashion or
in a "stop and commit" fashion. In the "stop and rollback" scenario,
the SPPP server would stop processing elements in the
request at the first error and roll back any elements
that had already been processed for that batch request.
In the "stop and commit" scenario the SPPP server would stop
processing elements in the request at the
first error but commit any elements
that had already been processed for that batch request. </t>
</section>
<section anchor="batchresponse" title="Batch Response">
<t> An SPPP batch response structure is contained within the generic
<![CDATA[<sppBatchResponse>]]> element. This response structure is used for an Batch request that contains many different types of SPPP operations.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppBatchResponse">
<complexType>
<sequence>
<element name="clientTransId" type="spppb:TransIdType"
minOccurs="0"/>
<element name="serverTransId" type="spppb:TransIdType"/>
<element name="overallResult" type="spppb:ResultCodeType"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="addResult"
type="sppps:ObjResultCodeType"/>
<element name="delResult"
type="sppps:ObjKeyResultCodeType"/>
<element name="acceptResult"
type="sppps:RteGrpOfferKeyResultCodeType"/>
<element name="rejectResult"
type="sppps:RteGrpOfferKeyResultCodeType"/>
</choice>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppBatchResponse>]]> contains the
elements necessary for an SPPP client to precisely determine the
overall result of various operations in the request, and if an error occurred, it provides
information about the specific objects or keys in the request that
caused the error. </t>
<t> The data elements within the SPPP Batch response are
described as follows: <list style="symbols" hangIndent="5">
<t> clientTransId: Zero or one client transaction ID. This
value is simply an echo of the client transaction ID that
SPPP client passed into the SPPP update request. When included
in the request, the SPPP server MUST return it in the corresponding
response message.</t>
<t> serverTransId: Exactly one server transaction ID that
identifies this request for tracking purposes. This
value MUST be unique for a given SPPP server. </t>
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t>addResult: One or more elements of type ObjResultCodeType where each element identifies the result code, result message and the specific object that the result relates to.</t>
<t>delResult: One or more elements of type ObjKeyResultCodeType where each element identifies the result code, result message and the specific object key that the result relates to.</t>
<t>acceptResult: One or more elements of type RteGrpOfferKeyResultCodeType where each element identifies the result code, result message and the specific Route Group Offer key that the result relates to.</t>
<t>rejectResult: One or more elements of type RteGrpOfferKeyResultCodeType where each element identifies the result code, result message and the specific Route Group Offer key that the result relates to.</t>
</list>
</t>
</section>
</section>
<section anchor="gets" title="Get Operation Structure">
<t> In order to query the details of an object from the Registry, an authorized entity
can send the spppGetRequest to the registry with a GetRqstType XML data structure containing one or more
object keys that uniquely identify the object whose details are being queried. The request strcuture for an SPPP Get operation is contained within the generic
<![CDATA[<spppGetRequest>]]> element while an SPPP Get response is
wrapped within the generic <![CDATA[<spppGetResponse>]]> element.
The following sub-sections describe the spppGetRequest and spppGetResponse element. Refer the examples section for an example of Get operation on each type of SPPP object</t>
<section anchor="getreq" title="Get Request">
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppGetRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="objKey"
type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppGetRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> objKey: One or more elements of abstract type ObjKeyType (as defined in the protocol document). Each element contains attributes that uniquely identify
the object that the client is requesting the server to query. Refer the "Concrete Object Keys" section of this document
for a description of all concrete object key types, for various SPPP objects, which are eligible to be passed into this element.
</t>
</list>
</t>
</section>
<section anchor="getresponse" title="Get Response">
<t>The spppGetResponse
element is described later in section titled "Generic Query Response". </t>
</section>
</section>
<section anchor="getrtegrpoffers" title="Get Route Group Offers Operation Structure">
<t> In addition to the ability to query the details of one or more Route Group offers using an a Route Group Offer key in the spppGetRequest, this operation
also provides an additonal, more flexible, structure to query for Route Group Offer objects. This additional structure is contained within the
<![CDATA[<getRteGrpOffersRequest>]]> element while the response is
wrapped within the generic <![CDATA[<spppGetResponse>]]> element.
The following sub-sections describe the getRteGrpOffersRequest and spppGetResponse elements.</t>
<section anchor="getrtegrpoffersrqst" title="Get Route Group Offers Request">
<t>Using the details passed into this structure, the server will
attempt to find Route Group Offer objects that satisfy all the criteria passed into the
request. If no criteria is passed in then the server will
return the list of Route Group Offer objects that belongs to the
registrant. If there are no matching Route Group Offers found then an empty result set
will be returned. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="getRteGrpOffersRequest">
<complexType>
<sequence>
<element name="minorVer" type="spppb:MinorVerType"
minOccurs="0"/>
<element name="offeredBy" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="offeredTo" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status" type="spppb:RteGrpOfferStatusType"
minOccurs="0"/>
<element name="rteGrpOfferKey" type="sppps:RteGrpOfferKeyType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<getRteGrpOffersRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using the
SPPP server menu operation described later in the document.</t>
<t> offeredBy: Zero or more organization IDs. Only offers
that are offered to the organization IDs
in this list should be included in the result set. The
result set is also subject to other query criteria in
the request.
</t>
<t> offeredTo: Zero or more organization IDs. Only offers
that are offered by the organization IDs
in this list should be included in the result set. The
result set is also subject to other query criteria in
the request.
</t>
<t> status: The status of the offer, offered or accepted.
Only offers in the specified status should be included
in the result set. If this element is not present then
the status of the offer should not be considered in the
query. The result set is also subject to other query
criteria in the request. </t>
<t> rteGrpOfferKey: Zero or more Route Group Offer Keys.
Only offers having one of these keys should be included
in the result set. The result set is also subject to
other query criteria in the request. </t>
</list>
</t>
</section>
<section anchor="getrtegrpoffersresponse" title="Get Route Group Offers Response">
<t>The spppGetResponse
element is described later in section titled "Generic Query Response". </t>
</section>
</section>
<section anchor="genericqueryresponse" title="Generic Query Response">
<t> An SPPP query response object is contained within the generic
<![CDATA[<spppGetResponse>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppGetResponse">
<complexType>
<sequence>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="resultObj"
type="spppb:BasicObjType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> An <![CDATA[<spppGetResponse>]]> contains the
elements necessary for the SPPP client to precisely determine the
overall result of the query, and details of any SPPP objects that matched the criteria
in the request. </t>
<t> The data elements within the SPPP query response are
described as follows: <list style="symbols" hangIndent="5">
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> resultObj: The set of zero or more objects that matched the
query criteria. If no objects matched the query criteria then the
result object(s) MUST be empty and the overallResult value MUST indicate
success (if no matches are found for the query criteria, the
response is considered a success).</t>
</list>
</t>
</section>
<section anchor="servermenuopn" title="Get Server Details Operation Structure">
<t>In order to query certain details of the SPPP server, like the SPPP server's status and the major/minor version supported by the server,
the Server Details operation structure SHOULD be used. This structure is contained within the
<![CDATA[<spppServerStatusRequest>]]> element while a SPPP server status response is
wrapped within the <![CDATA[<spppServerStatusResponse>]]> element.
This following sub-sections describe the spppServerStatusRequest and spppServerStatusResponse elements.</t>
<section anchor="servermenurqst" title="Get Server Details Request">
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppServerStatusRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppServerStatusRequest>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> minorVer: Zero or one minor version identifier, indicating the minor
version of the SPPP API that the client is attempting to use. This is
used in conjunction with the major version identifier in
the XML namespace to identify the version of SPPP that the client
is using. If the element is not present, the server assumes that
the client is using the latest minor version supported by the SPPP
server for the given major version. The versions supported by a
given SPPP server can be retrieved by the client using this same spppServerStatusRequest without passing in the minorVer element.</t>
</list>
</t>
</section>
<section anchor="servermenuresp" title="Get Server Details Response">
<t> An SPPP server details response structure is contained within the generic
<![CDATA[<spppServerStatusResponse>]]> element. </t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<element name="spppServerStatusResponse">
<complexType>
<sequence>
<element name="overallResult" type="sppps:ResultCodeType"/>
<element name="svcMenu" type="spppb:SvcMenuType"/>
</sequence>
</complexType>
</element>
]]>
</artwork>
</figure>
</t>
<t> The data elements within the <![CDATA[<spppServerStatusResponse>]]>
element are described as follows:
<list style="symbols" hangIndent="5">
<t> overallResult: Exactly one response code and message pair that
explicitly identifies the result of the request. See the
Response Code section for further details. </t>
<t> svcMenu: Exactly one element of type SvcMenuType which in turn contains the elements
to return the server status and major/minor version of the SPPP protocol supported by the SPPP server (refer protocol document for definition of SvcMenuType) .</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="resultcodes" title="Response Codes and Messages">
<t> This section contains the listing of response codes
and their corresponding human-readable text. These response codes
are in conformance with the response types defined in the section "Response Message Types"
of the protocol document.</t>
<t> The response code numbering scheme generally adheres to the
theory formalized in section 4.2.1 of <xref target="RFC5321"/>:
<list style="symbols" hangIndent="5">
<t> The first digit of the response code can only be 1 or 2:
1 = a positive result, 2 = a negative result. </t>
<t> The second digit of the response code indicates the
category: 0 = Protocol Syntax, 1 = Implementation Specific
Business Rule, 2 = Security, 3 = Server System. </t>
<t> The third and fourth digits of the response code
indicate the individual message event within the category
defines by the first two digits. </t>
</list>
</t>
<t> The response codes are also categorized as to whether they are
overall response codes that may only be returned in the "overallResult"
data element in SPPP responses, or object level response codes that
may only be returned in the "dtlResult" element of the SPPP
responses.</t>
<texttable anchor="Table1"
title="Response Codes Numbering Scheme and Messages">
<ttcol align="left" width="10%">Result Code</ttcol>
<ttcol align="left" width="30%">Result Message</ttcol>
<ttcol align="left" width="60%">Overall or Object Level</ttcol>
<c> 1000 </c>
<c> Request Succeeded.</c>
<c> Overall Response Code</c>
<c> 2001 </c>
<c> Request syntax invalid.</c>
<c> Overall Response Code</c>
<c> 2002 </c>
<c> Request too large.</c>
<c> Overall Response Code</c>
<c> 2003 </c>
<c> Version not supported.</c>
<c> Overall Response Code</c>
<c> 2103 </c>
<c> Command invalid.</c>
<c> Overall Response Code</c>
<c> 2301 </c>
<c> System temporarily unavailable.</c>
<c> Overall Response Code</c>
<c> 2302 </c>
<c> Unexpected internal system or server error.</c>
<c> Overall Response Code</c>
<c> 2104 </c>
<c> Attribute value invalid. AttrName:[AttributeName] AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
<c> 2105 </c>
<c> Object does not exist. AttrName:[AttributeName] AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
<c> 2106 </c>
<c> Object status or ownership does not allow for operation. AttrName:[AttributeName]
AttrVal:[AttributeValue]</c>
<c> Object Level Response Code</c>
</texttable>
<t> Each of the object level response messages are "parameterized" with the
following parameters: "AttributeName" and "AttributeValue". </t>
<t> The use of these parameters MUST adhere to the rules defined in "Response Message Types" section of the protocol document.
</t>
</section>
</section>
<section anchor="protocol_oper" title="Protocol Operations">
<t>Refer the "Protocol Operations" section of the protocol document for a description of all SPPP operations, and any necessary semantics that MUST be adhered to
in order to conform with the SPPP protocol specification.</t>
</section>
<section anchor="SPPPWSDL" title="SPPP SOAP WSDL Definition">
<t>The SPPP WSDL and data types are defined below. The WSDL design approach is commonly referred to as _Generic WSDL_.
It is generic in the sense that there is not a specific WSDL operation defined for each object type that is supported by the SPPP protocol.
There is a single WSDL structure for each type of SPPP operation. Each such WSDL structure contains exactly one input structure and one output structure that wraps any data elements
that are part of the incoming request and the outgoing response respectively. The spppSOAPBinding in the WSDL defines the binding style as _document_ and the encoding as _literal_.
It is this combination of _wrapped_ input and output data structures, _document_ binding style, and _literal_ encoding that characterize the Document Literal Wrapped style of WSDL specifications.</t>
<t>
Note: The following WSDL has been formatted (e.g., tabs, spaces) to meet I-D requirements.
</t>
<t>
<figure anchor="WSDL" title="WSDL">
<artwork align="left"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1">
<wsdl:types>
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1">
<annotation>
<documentation>
---- Import base schema ----
</documentation>
</annotation>
<import namespace="urn:ietf:params:xml:ns:sppp:base:1"
schemaLocation="spppbase.xsd"/>
<annotation>
<documentation>
---- Key type(s) extended
from base schema. ----
</documentation>
</annotation>
<complexType name="ObjKeyType">
<complexContent>
<extension base="spppb:ObjKeyType">
<sequence>
<element name="rant" type="spppb:OrgIdType"/>
<element name="name" type="spppb:ObjNameType"/>
<element name="type" type="spppb:ObjKeyTypeEnum"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RteGrpOfferKeyType">
<complexContent>
<extension base="spppb:RteGrpOfferKeyType">
<sequence>
<element name="rteGrpKey"
type="sppps:ObjKeyType"/>
<element name="offeredTo"
type="spppb:OrgIdType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="PubIdKeyType">
<complexContent>
<extension base="spppb:PubIdKeyType">
<sequence>
<element name="rant" type="spppb:OrgIdType"/>
<element name="dgName"
type="spppb:ObjNameType" minOccurs="0"/>
<choice>
<element name="number"
type="spppb:NumberType"/>
<element name="range"
type="spppb:NumberRangeType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<annotation>
<documentation>
---- Generic Request and
Response Definitions ----
</documentation>
</annotation>
<element name="spppAddRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="obj" type="spppb:BasicObjType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppDelRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="objKey"
type="spppb:ObjKeyType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppAcceptRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppRejectRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppGetRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="objKey"
type="spppb:ObjKeyType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppBatchRequest">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<choice minOccurs="1" maxOccurs="unbounded">
<element name="addObj" type="spppb:BasicObjType"/>
<element name="delObj" type="spppb:ObjKeyType"/>
<element name="acceptRteGrpOffer"
type="sppps:RteGrpOfferKeyType"/>
<element name="rejectRteGrpOffer"
type="sppps:RteGrpOfferKeyType"/>
</choice>
</sequence>
</complexType>
</element>
<element name="spppServerStatusRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="getRteGrpOffersRequest">
<complexType>
<sequence>
<element name="minorVer"
type="spppb:MinorVerType" minOccurs="0"/>
<element name="offeredBy"
type="spppb:OrgIdType" minOccurs="0"
maxOccurs="unbounded"/>
<element name="offeredTo" type="spppb:OrgIdType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status"
type="spppb:RteGrpOfferStatusType" minOccurs="0"/>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppAddResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="dtlResult"
type="sppps:ObjResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppDelResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="dtlResult"
type="sppps:ObjKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppAcceptResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="dtlResult"
type="sppps:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppRejectResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="dtlResult"
type="sppps:RteGrpOfferKeyResultCodeType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppBatchResponse">
<complexType>
<sequence>
<element name="clientTransId"
type="spppb:TransIdType" minOccurs="0"/>
<element name="serverTransId"
type="spppb:TransIdType"/>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="addResult"
type="sppps:ObjResultCodeType"/>
<element name="delResult"
type="sppps:ObjKeyResultCodeType"/>
<element name="acceptResult"
type="sppps:RteGrpOfferKeyResultCodeType"/>
<element name="rejectResult"
type="sppps:RteGrpOfferKeyResultCodeType"/>
</choice>
</sequence>
</complexType>
</element>
<element name="spppGetResponse">
<complexType>
<sequence>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="resultObj"
type="spppb:BasicObjType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="spppServerStatusResponse">
<complexType>
<sequence>
<element name="overallResult"
type="sppps:ResultCodeType"/>
<element name="svcMenu"
type="spppb:SvcMenuType"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation>
---- Operation Result Type
Definitions ----
</documentation>
</annotation>
<complexType name="ResultCodeType">
<sequence>
<element name="code" type="int"/>
<element name="msg" type="token"/>
</sequence>
</complexType>
<complexType name="ObjResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="obj" type="spppb:BasicObjType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ObjKeyResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="objKey" type="spppb:ObjKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="RteGrpOfferKeyResultCodeType">
<complexContent>
<extension base="sppps:ResultCodeType">
<sequence>
<element name="rteGrpOfferKey"
type="sppps:RteGrpOfferKeyType"/>
</sequence>
</extension>
</complexContent>
</complexType>
</xsd:schema>
</wsdl:types>
<wsdl:message name="spppAddRequestMsg">
<wsdl:part name="rqst" element="sppps:spppAddRequest"/>
</wsdl:message>
<wsdl:message name="spppDelRequestMsg">
<wsdl:part name="rqst" element="sppps:spppDelRequest"/>
</wsdl:message>
<wsdl:message name="spppAcceptRequestMsg">
<wsdl:part name="rqst" element="sppps:spppAcceptRequest"/>
</wsdl:message>
<wsdl:message name="spppRejectRequestMsg">
<wsdl:part name="rqst" element="sppps:spppRejectRequest"/>
</wsdl:message>
<wsdl:message name="spppBatchRequestMsg">
<wsdl:part name="rqst" element="sppps:spppBatchRequest"/>
</wsdl:message>
<wsdl:message name="spppGetRequestMsg">
<wsdl:part name="rqst" element="sppps:spppGetRequest"/>
</wsdl:message>
<wsdl:message name="spppGetRteGrpOffersRequestMsg">
<wsdl:part name="rqst" element="sppps:getRteGrpOffersRequest"/>
</wsdl:message>
<wsdl:message name="spppAddResponseMsg">
<wsdl:part name="rspns" element="sppps:spppAddResponse"/>
</wsdl:message>
<wsdl:message name="spppDelResponseMsg">
<wsdl:part name="rspns" element="sppps:spppDelResponse"/>
</wsdl:message>
<wsdl:message name="spppAcceptResponseMsg">
<wsdl:part name="rspns" element="sppps:spppAcceptResponse"/>
</wsdl:message>
<wsdl:message name="spppRejectResponseMsg">
<wsdl:part name="rspns" element="sppps:spppRejectResponse"/>
</wsdl:message>
<wsdl:message name="spppBatchResponseMsg">
<wsdl:part name="rspns" element="sppps:spppBatchResponse"/>
</wsdl:message>
<wsdl:message name="spppGetResponseMsg">
<wsdl:part name="rspns" element="sppps:spppGetResponse"/>
</wsdl:message>
<wsdl:message name="spppServerStatusRequestMsg">
<wsdl:part name="rqst" element="sppps:spppServerStatusRequest"/>
</wsdl:message>
<wsdl:message name="spppServerStatusResponseMsg">
<wsdl:part name="rspns" element="sppps:spppServerStatusResponse"/>
</wsdl:message>
<wsdl:portType name="spppPortType">
<wsdl:operation name="submitAddRqst">
<wsdl:input message="sppps:spppAddRequestMsg"/>
<wsdl:output message="sppps:spppAddResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitDelRqst">
<wsdl:input message="sppps:spppDelRequestMsg"/>
<wsdl:output message="sppps:spppDelResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitAcceptRqst">
<wsdl:input message="sppps:spppAcceptRequestMsg"/>
<wsdl:output message="sppps:spppAcceptResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitRejectRqst">
<wsdl:input message="sppps:spppRejectRequestMsg"/>
<wsdl:output message="sppps:spppRejectResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitBatchRqst">
<wsdl:input message="sppps:spppBatchRequestMsg"/>
<wsdl:output message="sppps:spppBatchResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitGetRqst">
<wsdl:input message="sppps:spppGetRequestMsg"/>
<wsdl:output message="sppps:spppGetResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitGetRteGrpOffersRqst">
<wsdl:input message="sppps:spppGetRteGrpOffersRequestMsg"/>
<wsdl:output message="sppps:spppGetResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<wsdl:input message="sppps:spppServerStatusRequestMsg"/>
<wsdl:output message="sppps:spppServerStatusResponseMsg"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="spppSoapBinding" type="sppps:spppPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="submitAddRqst">
<soap:operation soapAction="submitAddRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitDelRqst">
<soap:operation soapAction="submitDelRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitAcceptRqst">
<soap:operation soapAction="submitAcceptRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitRejectRqst">
<soap:operation soapAction="submitRejectRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitBatchRqst">
<soap:operation soapAction="submitBatchRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitGetRqst">
<soap:operation soapAction="submitGetRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitGetRteGrpOffersRqst">
<soap:operation soapAction="submitGetRteGrpOffersRqst"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<soap:operation soapAction="submitServerStatusRqst"
style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="spppService">
<wsdl:port name="spppPort" binding="sppps:spppSoapBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
]]></artwork>
</figure></t>
</section>
<section anchor="examples" title="SPPP SOAP Examples">
<t>This section shows XML message exchange between two SIP Service
Providers (SSP) and a registry. The SPPP
messages in this section are valid XML instances that conform to the
SOAP based SPPP schema version within this document. This section
relies on the XML data structures defined in the base SPPP protocol specification <xref target="I-D.draft-ietf-drinks-spprov"/>.
So refer to that document to understand XML object types embedded in these example messages.</t>
<t>In this sample use case scenario, SSP1 and SSP2 provision
resource data in the registry and use SPPP constructs to selectively
share the route groups. In the figure below, SSP2 has two ingress
SBE instances that are associated with the public identities that
SSP2 has the retail relationship with. Also, the two SBE instances
for SSP1 are used to show how to use SPPP to associate
route preferences for the destination ingress routes and exercise
greater control on outbound traffic to the peer's ingress SBEs.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
---------------+ +------------------
| |
+------+ +------+
| sbe1 | | sbe2 |
+------+ +------+
SSP1 | | SSP2
+------+ +------+
| sbe3 | | sbe4 |
+------+ +------+
iana-en:111 | | iana-en:222
---------------+ +------------------
| |
| |
| SPPP +------------------+ SPPP |
+------->| Registry |<--------+
+------------------+
]]>
</artwork>
</figure>
</t>
<section anchor="add_destgrp" title="Add Destination Group">
<t>SSP2 adds a destination group to the registry for use later. The
SSP2 SPPP client sets a unique transaction identifier 'txn_1479' for
tracking purposes. The name of the destination group is set to DEST_GRP_SSP2_1</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<!--Optional:-->
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:DestGrpType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>The registry processes the request and return a favorable
response confirming successful creation of the named
destination group. Also, besides returning a unique server transaction
identifier, Registry also returns the matching client transaction
identifier from the request message back to the SPPP client.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_rterecs" title="Add Route Records">
<t>SSP2 adds an ingress routes in the registry.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<!--Optional:-->
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:NAPTRType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rrName>RTE_SSP2_SBE2</urn1:rrName>
<urn1:order>10</urn1:order>
<urn1:flags>u</urn1:flags>
<urn1:svcs>E2U+sip</urn1:svcs>
<urn1:regx>
<urn1:ere>^(.*)$</urn1:ere>
<urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
</urn1:regx>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>The registry returns a success response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_rterecs_uritype" title="Add Route Records -- URIType">
<t>SSP2 adds another ingress routes in the registry and makes use of URIType</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:URIType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rrName>RTE_SSP2_SBE4</urn1:rrName>
<urn1:ere>^(.*)$</urn1:ere>
<urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>The registry returns a success response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_rtegrp" title="Add Route Group">
<t>SSP2 creates the grouping of the ingress routes and choses higher precedence for RTE_SSP2_SBE2 by setting a lower number for the "priority" attribute, a protocol agnostic precedence indicator.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:RteGrpType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rgName>RTE_GRP_SSP2_1</urn1:rgName>
<urn1:rrRef>
<urn1:rrKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_SSP2_SBE2</name>
<type>RteRec</type>
</urn1:rrKey>
<urn1:priority>100</urn1:priority>
</urn1:rrRef>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:isInSvc>true</urn1:isInSvc>
<urn1:priority>10</urn1:priority>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>To confirm successful processing of this request, registry returns a well-known result code '1000' to the SSP2 client.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_pi_corclaim" title="Add Public Identity -- Successful COR claim">
<t>SSP2 activates a TN public identity by associating it with a valid destination group. Further, SSP2 puts forth a claim that it is the carrier-of-record for the TN.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:TNType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:tn>+12025556666</urn1:tn>
<urn1:corInfo>
<urn1:corClaim>true</urn1:corClaim>
</urn1:corInfo>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Assuming that the registry has access to TN authority data and it performs the required checks to verify that SSP2 is in fact the service provider of record for the given TN, the request is processed successfully. In the response message, the registry sets the value of <cor> to "true" in order to confirm SSP2 claim as the carrier of record and the <corDate> reflects the time when the carrier of record claim is processed.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
<dtlResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
<obj xsi:type="ns2:TNType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
<ns2:tn>+12025556666</ns2:tn>
<ns2:corInfo>
<ns2:corClaim>true</ns2:corClaim>
<ns2:cor>true</ns2:cor>
<ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate>
</ns2:corInfo>
</obj>
</dtlResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_lrn" title="Add LRN">
<t>If another entity that SSP2 shares the routes with has access to Number Portability data, it may choose to perform route lookups by routing number. Therefore, SSP2 associates a routing number to a destination group in order to facilitate ingress route discovery.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:RNType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:rn>2025550000</urn1:rn>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response to the SPPP client.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_tn_range" title="Add TN Range">
<t>Next, SSP2 activates a block of ten thousand TNs and associate it to a destination group.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:TNRType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:range>
<urn1:startTn>+12026660000</urn1:startTn>
<urn1:endTn>+12026669999</urn1:endTn>
</urn1:range>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_tn_prefix" title="Add TN Prefix">
<t>Next, SSP2 activates a block of ten thousand TNs using the TNPType structure and identifying a TN prefix.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:TNPType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:tnPrefix>+1202777</urn1:tnPrefix>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_rte_grp_offer" title="Enable Peering -- Route Group Offer">
<t>In order for SSP1 to complete session establishment for a destination TN where the target subscriber has a retail relationship with SSP2, it first requires an asynchronous bi-directional handshake to show mutual consent. To start the process, SSP2 initiates the peering handshake by offering SSP1 access to its route group.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:RteGrpOfferType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rteGrpOfferKey xsi:type="urn:RteGrpOfferKeyType">
<rteGrpKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</urn1:rteGrpOfferKey>
<urn1:status>offered</urn1:status>
<urn1:offerDateTime>
2006-05-04T18:13:51.0Z
</urn1:offerDateTime>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and confirms that the SSP1 will now have the opportunity to weigh in on the offer and either accept or reject it. The registry may employ out-of-band notification mechanisms for quicker updates to SSP1 so they can act faster, though this topic is beyond the scope of this document.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_rte_grp_offer_accept" title="Enable Peering -- Route Group Offer Accept">
<t>SSP1 responds to the offer from SSP2 and agrees to have visibility to SSP2 ingress routes.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAcceptRequest>
<!--Optional:-->
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<rteGrpOfferKey>
<rteGrpKey>
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</rteGrpOfferKey>
</urn:spppAcceptRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry confirms that the request has been processed successfully. From this point forward, if SSP1 looks up a public identity through the query resolution server,
where the public identity is part of the destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 ingress SBE information will be shared with SSP1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAcceptResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12350</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAcceptResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="add_egress_rte" title="Add Egress Route">
<t>SSP1 wants to prioritize all outbound traffic to routes associated with "RTE_GRP_SSP2_1" route group through "sbe1.ssp1.example.com".</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppAddRequest>
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<obj xsi:type="urn1:EgrRteType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:egrRteName>EGR_RTE_01</urn1:egrRteName>
<urn1:pref>50</urn1:pref>
<urn1:regxRewriteRule>
<urn1:ere>^(.*@)(.*)$</urn1:ere>
<urn1:repl>\1\2?route=sbe1.ssp1.example.com</urn1:repl>
</urn1:regxRewriteRule>
<urn1:ingrRteRec xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>SSP2_RTE_REC_3</name>
<type>RteRec</type>
</urn1:ingrRteRec>
</obj>
</urn:spppAddRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Since peering has already been established, the request to add the egress route has been successfully completed.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppAddResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12345</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppAddResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="rte_grp_offer_reject" title="Remove Peering -- Route Group Offer Reject">
<t>SSP1 had earlier accepted to have visibility to SSP2 ingress routes. SSP1 now decides to no more maintain this visiblity and hence rejects the Route Group Offer.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1">
<soapenv:Header/>
<soapenv:Body>
<urn:spppRejectRequest>
<!--Optional:-->
<clientTransId>txn_1479</clientTransId>
<!--1 or more repetitions:-->
<rteGrpOfferKey>
<rteGrpKey>
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</rteGrpOfferKey>
</urn:spppRejectRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry confirms that the request has been processed successfully. From this point forward, if SSP1 looks up a public identity through the query resolution server,
where the public identity is part of the destination group by way of "RTE_GRP_SSP2_1" route association, SSP2 ingress SBE information will NOT be shared with SSP1 and hence
SSP2 ingress SBE will NOT be returned in the query response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppRejectResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<clientTransId>txn_1479</clientTransId>
<serverTransId>tx_12350</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppRejectResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="get_dest_grp" title="Get Destination Group">
<t>SSP2 uses the 'spppGetRequest' operation to tally the last provisioned record for destination group DEST_GRP_SSP2_1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppGetRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>DEST_GRP_SSP2_1</name>
<type>DestGrp</type>
</objKey>
</urn:spppGetRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<overallResult>
<code>1000</code>
<msg>success</msg>
</overallResult>
<resultObj xsi:type="ns2:DestGrpType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
</resultObj>
</ns3:spppGetResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="get_pub_id" title="Get Public Identity">
<t>SSP2 obtains the last provisioned record associated with a given TN.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppGetRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:PubIdKeyType">
<rant>iana-en:222</rant>
<number>
<urn1:value>+12025556666</urn1:value>
<urn1:type>TN</urn1:type>
</number>
</objKey>
</urn:spppGetRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<overallResult>
<code>1000</code>
<msg>success</msg>
</overallResult>
<resultObj xsi:type="ns2:TNType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
<ns2:tn>+12025556666</ns2:tn>
<ns2:corInfo>
<ns2:corClaim>true</ns2:corClaim>
<ns2:cor>true</ns2:cor>
<ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate>
</ns2:corInfo>
</resultObj>
</ns3:spppGetResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="get_rte_grp_request" title="Get Route Group Request">
<t>SSP2 obtains the last provisioned record for the route group RTE_GRP_SSP2_1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppGetRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</objKey>
</urn:spppGetRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<overallResult>
<code>1000</code>
<msg>success</msg>
</overallResult>
<resultObj xsi:type="ns2:RteGrpType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:rgName>RTE_GRP_SSP2_1</ns2:rgName>
<ns2:rrRef>
<ns2:rrKey xsi:type="ns3:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_SSP2_SBE2</name>
<type>RteRec</type>
</ns2:rrKey>
<ns2:priority>100</ns2:priority>
</ns2:rrRef>
<ns2:rrRef>
<ns2:rrKey xsi:type="ns3:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_SSP2_SBE4</name>
<type>RteRec</type>
</ns2:rrKey>
<ns2:priority>101</ns2:priority>
</ns2:rrRef>
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName>
<ns2:isInSvc>true</ns2:isInSvc>
<ns2:priority>10</ns2:priority>
</resultObj>
</ns3:spppGetResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="get_rte_grp_offers_rqst" title="Get Route Group Offers Request">
<t>SSP2 fetches the last provisioned route group offer to the <peeringOrg> SSP1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1">
<soapenv:Header/>
<soapenv:Body>
<urn:getRteGrpOffersRequest>
<offeredTo>iana-en:111</offeredTo>
</urn:getRteGrpOffersRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry processes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<overallResult>
<code>1000</code>
<msg>success</msg>
</overallResult>
<resultObj xsi:type="ns2:RteGrpOfferType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:rteGrpOfferKey
xsi:type="ns3:RteGrpOfferKeyType">
<rteGrpKey>
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</ns2:rteGrpOfferKey>
<ns2:status>offered</ns2:status>
<ns2:offerDateTime>
2006-05-04T18:13:51.0Z
</ns2:offerDateTime>
</resultObj>
</ns3:spppGetResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="get_egress_rte" title="Get Egress Route">
<t>SSP1 wants to verify the last provisioned record for the egress route called EGR_RTE_01.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppGetRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:111</rant>
<name>EGR_RTE_01</name>
<type>EgrRte</type>
</objKey>
</urn:spppGetRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<S:Body>
<ns3:spppGetResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<overallResult>
<code>1000</code>
<msg>success</msg>
</overallResult>
<resultObj xsi:type="ns2:EgrRteType">
<ns2:rant>iana-en:222</ns2:rant>
<ns2:rar>iana-en:223</ns2:rar>
<ns2:egrRteName>EGR_RTE_01</ns2:egrRteName>
<ns2:pref>50</ns2:pref>
<ns2:regxRewriteRule>
<ns2:ere>^(.*)$</ns2:ere>
<ns2:repl>sip:\1@sbe1.ssp1.example.com</ns2:repl>
</ns2:regxRewriteRule>
<ns2:ingrRteRec xsi:type="ns3:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteRec</type>
</ns2:ingrRteRec>
</resultObj>
</ns3:spppGetResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="del_dest_grp" title="Delete Destination Group">
<t>SSP2 initiates a request to delete the destination group DEST_GRP_SSP2_1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppDelRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>DEST_GRP_SSP2_1</name>
<type>DestGrp</type>
</objKey>
</urn:spppDelRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppDelResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppDelResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="del_pub_id" title="Delete Public Identity">
<t>SSP2 choses to de-activate the TN and remove it from the registry.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppDelRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:PubIdKeyType">
<rant>iana-en:222</rant>
<dgName>DEST_GRP_SSP2_1</dgName>
<number>
<urn1:value>+12025556666</urn1:value>
<urn1:type>TN</urn1:type>
</number>
</objKey>
</urn:spppDelRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppDelResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppDelResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="del_rte_grp_rqst" title="Delete Route Group Request">
<t>SSP2 removes the route group called RTE_GRP_SSP2_1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppDelRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</objKey>
</urn:spppDelRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppDelResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppDelResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="del_rte_grp_offers_rqst" title="Delete Route Group Offers Request">
<t>SSP2 no longer wants to share route group RTE_GRP_SSP2_1 with SSP1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppDelRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:RteGrpOfferKeyType">
<rteGrpKey>
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</objKey>
</urn:spppDelRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response. Restoring this resource sharing will require a new route group offer from SSP2 to SSP1 followed by a successful route group accept request from SSP1.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppDelResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppDelResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="del_egress_rte" title="Delete Egress Route">
<t>SSP1 decides to remove the egress route with the label EGR_RTE_01.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppDelRequest>
<!--1 or more repetitions:-->
<objKey xsi:type="urn:ObjKeyType">
<rant>iana-en:111</rant>
<name>EGR_RTE_01</name>
<type>EgrRte</type>
</objKey>
</urn:spppDelRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppDelResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppDelResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="batch_req" title="Batch Request">
<t>Following is an example of how some of the operations mentioned in previous sections
MAY be performed by an SPPP client as a batch in one single SOAP based SPPP request.</t>
<t>In the sample request below SSP1 wants to accept a Route Group Offer from SSP3, add
a Destination Group, add a NAPTR Route Rec, add a Route Group, add a Route Group Offer,
delete a previously provisioned TN type Public Identifier, delete a previously provisioned Route Group, and reject a Route Group Offer from SSP4.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:ietf:params:xml:ns:sppp:soap:1"
xmlns:urn1="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<urn:spppBatchRequest>
<clientTransId>txn_1467</clientTransId>
<minorVer>1</minorVer>
<acceptRteGrpOffer>
<rteGrpKey>
<rant>iana-en:225</rant>
<name>RTE_SSP3_SBE1_Offered</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:222</offeredTo>
</acceptRteGrpOffer>
<addObj xsi:type="urn1:DestGrpType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
</addObj>
<addObj xsi:type="urn1:NAPTRType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rrName>RTE_SSP2_SBE2</urn1:rrName>
<urn1:order>10</urn1:order>
<urn1:flags>u</urn1:flags>
<urn1:svcs>E2U+sip</urn1:svcs>
<urn1:regx>
<urn1:ere>^(.*)$</urn1:ere>
<urn1:repl>sip:\1@sbe2.ssp2.example.com</urn1:repl>
</urn1:regx>
</addObj>
<addObj xsi:type="urn1:RteGrpType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rgName>RTE_GRP_SSP2_1</urn1:rgName>
<urn1:rrRef>
<urn1:rrKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_SSP2_SBE2</name>
<type>RteRec</type>
</urn1:rrKey>
<urn1:priority>100</urn1:priority>
</urn1:rrRef>
<urn1:dgName>DEST_GRP_SSP2_1</urn1:dgName>
<urn1:isInSvc>true</urn1:isInSvc>
<urn1:priority>10</urn1:priority>
</addObj>
<addObj xsi:type="urn1:RteGrpOfferType">
<urn1:rant>iana-en:222</urn1:rant>
<urn1:rar>iana-en:223</urn1:rar>
<urn1:rteGrpOfferKey xsi:type="urn:RteGrpOfferKeyType">
<rteGrpKey xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_1</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:111</offeredTo>
</urn1:rteGrpOfferKey>
<urn1:status>offered</urn1:status>
<urn1:offerDateTime>
2006-05-04T18:13:51.0Z
</urn1:offerDateTime>
</addObj>
<delObj xsi:type="urn:PubIdKeyType">
<rant>iana-en:222</rant>
<dgName>DEST_GRP_SSP2_Previous</dgName>
<number>
<urn1:value>+12025556666</urn1:value>
<urn1:type>TN</urn1:type>
</number>
</delObj>
<delObj xsi:type="urn:ObjKeyType">
<rant>iana-en:222</rant>
<name>RTE_GRP_SSP2_Previous</name>
<type>RteGrp</type>
</delObj>
<rejectRteGrpOffer>
<rteGrpKey>
<rant>iana-en:226</rant>
<name>RTE_SSP4_SBE1_Offered</name>
<type>RteGrp</type>
</rteGrpKey>
<offeredTo>iana-en:222</offeredTo>
</rejectRteGrpOffer>
</urn:spppBatchRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>Registry completes the request successfully and returns a favorable response.</t>
<t>
<figure title="">
<artwork align="left">
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns3:spppBatchResponse
xmlns:ns2="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:ns3="urn:ietf:params:xml:ns:sppp:soap:1">
<serverTransId>tx_12354</serverTransId>
<overallResult>
<code>1000</code>
<msg>Request Succeeded.</msg>
</overallResult>
</ns3:spppBatchResponse>
</S:Body>
</S:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>SPPP is used to query and update session peering data and addresses, so
the ability to access this protocol should be limited to users and
systems that are authorized to query and update this data. Because this
data is sent in both directions, it may not be sufficient for just the client
or user to be authenticated with the server. The identity of the server
should also be authenticated by the client, which is often accomplished using
the TLS certificate exchange and validation described in <xref target="RFC2818"/>.
SPPP data may include sensitive
information, routing data, lists of resolvable addresses, etc. So when used
in a production setting and across non-secure networks, SPPP
should only be used over communications channels that provide strong
encryption for data privacy.</t>
<section anchor="IntegrityPrivacyAuthentication" title="Integrity, Privacy, and Authentication">
<t>The SPPP SOAP binding relies on an underlying secure transport for
integrity and privacy. Such transports are expected to include TLS/HTTPS.
In addition to the application level authentication imposed by an SPPP
server, there are a number of options for authentication within the transport
layer and the messaging envelope. These include TLS client certificates,
HTTP Digest Access Authentication, and digital signatures within SOAP headers. </t>
<t>At a miniumum, all conforming SPPP over SOAP implementations MUST
support HTTPS.</t>
</section>
<section anchor="Vulnerabilities" title="Vulnerabilities">
<t>The above protocols may have various vulnerabilities, and these may
be inherited by SPPP over SOAP. And SPPP itself may have vulnerabilities
because an authorization model is not explicitly specified in the current
specification.
</t>
<t>It is important that SPPP implementations implement an authorization
model that considers the source of each SPPP query or update request and
determines whether it is reasonable to authorize that source to perform that
specific query or update. </t>
</section>
<section anchor="DeploymentEnvironmentSpecifics" title="Deployment Environment Specifics">
<t>Some deployments of SPPP over SOAP could choose to use transports
without encryption. This presents vulnerabilities but could be
selected for deployments involving closed networks or debugging
scenarios. However, the vulnerabilities of such a deployment could be a
lack of integrity and privacy of the data transported over SPPP messages in
this type of deployment.</t>
</section>
</section>
<section anchor="IANAConsiderations" title="IANA Considerations">
<t>This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in <xref target="RFC3688"/>.
</t>
<t>URN assignments are requested: urn:ietf:params:xml:ns:sppp:soap</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
This document is a result of various discussions held by the DRINKS design team, which is comprised of the following individuals, in no specific order: Syed Ali (NeuStar), Sumanth Channabasappa (Cable Labs), David Schwartz (XConnect), Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Alexander Mayrhofer (enum.at GmbH), Vikas Bhatia (TNS, Inc.).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3688;
&rfc5246;
&rfc2617;
&rfc2616;
<reference anchor="I-D.draft-ietf-drinks-spprov">
<front>
<title>DRINKS Use cases and Protocol Requirements</title>
<author initials="J-F.M." surname="Mule"/>
<author initials="K.C." surname="Cartwright"/>
<author initials="S.A." surname="Ali"/>
<author initials="A.M." surname="Mayrhofer"/>
<author initials="V.B." surname="Bhatia"/>
<date month="June" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-drinks-spprov-12"/>
<format target="http://tools.ietf.org/html/draft-ietf-drinks-spprov-12" type="HTML" />
</reference>
<reference anchor="SOAPREF">
<front>
<title>SOAP Version 1.2 Part 1: Messaging Framework</title>
<author initials="M." surname="Gudgin"/>
<author initials="M." surname="Hadley"/>
<author initials="J." surname="Moreau"/>
<author initials="H." surname="Nielsen"/>
<date month="June" year="2002" />
</front>
<seriesInfo name="W3C Recommendation" value="REC-SOAP12-part1-20030624"/>
<format target="http://www.w3.org/TR/soap12-part1/" type="HTML" />
</reference>
</references>
<references title="Informative References">
&rfc2818; &rfc5321;
<reference anchor="WSDLREF">
<front>
<title>Web Services Description Language (WSDL) 1.1</title>
<author initials="E." surname="Christensen"/>
<author initials="F." surname="Curbera"/>
<author initials="G." surname="Meredith"/>
<author initials="S." surname="Weerawarana"/>
<date month="March" year="2001" />
</front>
<seriesInfo name="W3C Note" value="NOTE-wsdl-20010315"/>
<format target="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:33:40 |