RFC 7878

Session Peering Provisioning (SPP) Protocol over SOAP

Pages: 83
Proposed Standard

Part 3 of 4 – Pages 44 to 62

RFC7878 - Page 44 prevText

10.  SPPP over SOAP Examples

   This section shows an XML message exchange between two SIP Service
   Providers (SSPs) and a Registry.  The messages in this section are
   valid XML instances that conform to the SPPP over SOAP schema version
   within this document.  This section also relies on the XML data
   structures defined in the SPPF specification [RFC7877], which should
   also be referenced to understand XML object types embedded in these
   example messages.

   In this sample use-case scenario, SSP1 and SSP2 provision resource
   data in the Registry and use SPPF constructs to selectively share the
   SED Groups.  In the figure below, SSP2 has two ingress Signaling Path
   Border Element (SBE) instances that are associated with the Public
   Identities with which SSP2 has the retail relationship.  Also, the
   two SBE instances for SSP1 are used to show how to use SPPF to
   associate route preferences for the destination Ingress Routes and
   exercise greater control on outbound traffic to the peer's ingress
   SBEs.

      ---------------+                      +------------------
                     |                      |
                 +------+               +------+
                 | sbe1 |               | sbe2 |
                 +------+               +------+
       SSP1          |                      |           SSP2
                 +------+               +------+
                 | sbe3 |               | sbe4 |
                 +------+               +------+
      iana-en:111    |                      |     iana-en:222
      ---------------+                      +------------------
              |                                     |
              |                                     |
              | SPPF   +------------------+   SPPF  |
              +------->|     Registry     |<--------+
                       +------------------+

                      Example Use-Case Infrastructure

10.1.  Add Destination Group

   SSP2 adds a Destination Group to the Registry for later use.  The
   SSP2 SPPF client sets a unique transaction identifier "txn_1479" for
   tracking purposes.  The name of the Destination Group is set to
   DEST_GRP_SSP2_1.

RFC7878 - Page 45

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
   xmlns:urn1="urn:ietf:params:xml:ns:sppf: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>

   The Registry processes the request and returns a favorable response
   confirming successful creation of the named Destination Group.  In
   addition to returning a unique server transaction identifier, the
   Registry returns the matching client transaction identifier from the
   request message back to the SPPF client.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 46

10.2.  Add SED Records

   SSP2 adds SED Records in the form of Ingress Routes to the Registry.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
   xmlns:urn1="urn:ietf:params:xml:ns:sppf: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:sedName>SED_SSP2_SBE2</urn1:sedName>
       <urn1:isInSvc>true</urn1:isInSvc>
       <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>

RFC7878 - Page 47

   The Registry returns a success response.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

10.3.  Add SED Records -- URIType

   SSP2 adds another SED Record to the Registry and makes use of
   URIType.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
   xmlns:urn1="urn:ietf:params:xml:ns:sppf: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:sedName>SED_SSP2_SBE4</urn1:sedName>
       <urn1:isInSvc>true</urn1:isInSvc>
       <urn1:ere>^(.*)$</urn1:ere>
       <urn1:uri>sip:\1;npdi@sbe4.ssp2.example.com</urn1:uri>
      </obj>
     </urn:spppAddRequest>
    </soapenv:Body>
   </soapenv:Envelope>

RFC7878 - Page 48

   The Registry returns a success response.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 49

10.4.  Add SED Group

   SSP2 creates the grouping of SED Records (e.g., Ingress Routes) and
   chooses a higher precedence for SED_SSP2_SBE2 by setting a lower
   number for the "priority" attribute, a protocol agnostic precedence
   indicator.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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:SedGrpType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:sedGrpName>SED_GRP_SSP2_1</urn1:sedGrpName>
       <urn1:sedRecRef>
        <urn1:sedKey xsi:type="urn:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_SSP2_SBE2</name>
         <type>SedRec</type>
        </urn1:sedKey>
        <urn1:priority>100</urn1:priority>
       </urn1:sedRecRef>
       <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>

RFC7878 - Page 50

   To confirm successful processing of this request, the Registry
   returns a well-known result code "1000" to the SSP2 client.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

10.5.  Add Public Identifier -- Successful COR Claim

   SSP2 activates a TN Public Identifier by associating it with a valid
   Destination Group.  Further, SSP2 puts forth a claim that it is the
   carrier-of-record (COR) for the TN.

   <soapenv:Envelope
   xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
   xmlns:urn1="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 51

   Assuming that the Registry has access to TN authority data and it
   performs the required checks to verify that SSP2 is in fact the SP 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 the SSP2 claim as the carrier-of-record, and the
   <corDate> reflects the time when the carrier-of-record claim is
   processed.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1">
      <clientTransId>txn_1479</clientTransId>
      <serverTransId>tx_12345</serverTransId>
      <overallResult>
       <code>1000</code>
       <msg>Request Succeeded.</msg>
      </overallResult>
      <detailResult>
       <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>
      </detailResult>
     </ns3:spppAddResponse>
    </S:Body>
   </S:Envelope>

RFC7878 - Page 52

10.6.  Add LRN

   If another entity that SSP2 shares SED (e.g., routes) with has access
   to Number Portability data, it may choose to perform route lookups by
   RN.  Therefore, SSP2 associates an RN to a Destination Group in order
   to facilitate Ingress Route discovery.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 53

   The Registry completes the request successfully and returns a
   favorable response to the SPPF client.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

10.7.  Add TN Range

   Next, SSP2 activates a block of ten thousand TNs and associates it to
   a Destination Group.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 54

   The Registry completes the request successfully and returns a
   favorable response.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

10.8.  Add TN Prefix

   Next, SSP2 activates a block of ten thousand TNs by using the TNPType
   structure and identifying a TN prefix.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 55

   The Registry completes the request successfully and returns a
   favorable response.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 56

10.9.  Enable Peering -- SED Group Offer

   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 bidirectional handshake to show
   mutual consent.  To start the process, SSP2 initiates the peering
   handshake by offering SSP1 access to its SED Group.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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:SedGrpOfferType">
       <urn1:rant>iana-en:222</urn1:rant>
       <urn1:rar>iana-en:223</urn1:rar>
       <urn1:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType">
        <sedGrpKey xsi:type="urn:ObjKeyType">
         <rant>iana-en:222</rant>
         <name>SED_GRP_SSP2_1</name>
         <type>SedGrp</type>
        </sedGrpKey>
        <offeredTo>iana-en:111</offeredTo>
       </urn1:sedGrpOfferKey>
       <urn1:status>offered</urn1:status>
       <urn1:offerDateTime>
         2006-05-04T18:13:51.0Z
       </urn1:offerDateTime>
      </obj>
     </urn:spppAddRequest>
    </soapenv:Body>
   </soapenv:Envelope>

RFC7878 - Page 57

   The 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.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 58

10.10.  Enable Peering -- SED Group Offer Accept

   SSP1 responds to the offer from SSP2 and agrees to have visibility to
   SSP2 SED (e.g., Ingress Routes).

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppAcceptRequest>
      <!--Optional:-->
      <clientTransId>txn_1479</clientTransId>
       <!--1 or more repetitions:-->
      <sedGrpOfferKey>
       <sedGrpKey>
        <rant>iana-en:222</rant>
        <name>SED_GRP_SSP2_1</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:111</offeredTo>
      </sedGrpOfferKey>
     </urn:spppAcceptRequest>
    </soapenv:Body>
   </soapenv:Envelope>

RFC7878 - Page 59

   The Registry confirms that the request has been processed
   successfully.  From this point forward, if SSP1 looks up a Public
   Identifier through the query resolution server, where the Public
   Identifier is part of the Destination Group by way of
   "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
   be shared with SSP1.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

RFC7878 - Page 60

10.11.  Add Egress Route

   SSP1 wants to prioritize all outbound traffic to the Ingress Route
   associated with the "SED_GRP_SSP2_1" SED Group record, through
   "sbe1.ssp1.example.com".

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"
    xmlns:urn1="urn:ietf:params:xml:ns:sppf: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:ingrSedGrp xsi:type="urn:ObjKeyType">
        <rant>iana-en:222</rant>
        <name>SED_GRP_SSP2_1</name>
        <type>SedGrp</type>
       </urn1:ingrSedGrp>
      </obj>
     </urn:spppAddRequest>
    </soapenv:Body>
   </soapenv:Envelope>

RFC7878 - Page 61

   Since peering has already been established, the request to add the
   Egress Route has been successfully completed.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

10.12.  Remove Peering -- SED Group Offer Reject

   Earlier, SSP1 had accepted having visibility to SSP2 SED.  SSP1 now
   decides to no longer maintain this visibility; hence, it rejects the
   SED Group Offer.

   <?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1">
    <soapenv:Header/>
    <soapenv:Body>
     <urn:spppRejectRequest>
      <!--Optional:-->
      <clientTransId>txn_1479</clientTransId>
       <!--1 or more repetitions:-->
      <sedGrpOfferKey>
       <sedGrpKey>
        <rant>iana-en:222</rant>
        <name>SED_GRP_SSP2_1</name>
        <type>SedGrp</type>
       </sedGrpKey>
       <offeredTo>iana-en:111</offeredTo>
      </sedGrpOfferKey>
     </urn:spppRejectRequest>
    </soapenv:Body>
   </soapenv:Envelope>

RFC7878 - Page 62

   The Registry confirms that the request has been processed
   successfully.  From this point forward, if SSP1 looks up a Public
   Identifier through the query resolution server, where the Public
   Identifier is part of the Destination Group by way of
   "SED_GRP_SSP2_1" SED association, SSP2 ingress SBE information will
   not be shared with SSP1; hence, an SSP2 ingress SBE will not be
   returned in the query response.

   <?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:sppf:base:1"
      xmlns:ns3="urn:ietf:params:xml:ns:sppf: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>

(page 62 continued on part 4)