Subject: [drinks] Proposed changes to SPPF model

From: David Schwartz <[email-masked]>
Date: Wed, 29 Feb 2012 19:34:48 +0200

In the current model, the relationship between the routes and the identities (phone numbers) is encapsulated for all practical purposes in the RteGrp object. It is for this reason that all aspects of peering as well are sitting in the RG as this is the focal point of the resolution process. While it is understandable why this is so (optimize the use case that is most common --> grouping of numbers and their associated routing options) it is severely limiting for other relationships that don't fit this profile (e.g. TNType to RteRec). As a result, if we want to associate a TNType with a RteRec and yet retain all the properties associated with a RteGrp (e.g. peeringOrgs) we need to either have a TNType - RG relationship (bypassing the DG and kinda breaking the model), Have a DG with just 1 PI and risk countless useless DGs just sitting around for this purpose, or associate the TNType directly with the RteRec and lose the peering properties afforded by the RG concept.

What is proposed is a slight change to the model which abstracts the association between the RG and DG to a higher layer represented by RteElement and IDElement respectively (both are abstract) extending the association capabilities to 1-1 relationships as well. Instead of the RteGrp containing the association information, this information is relegated to the RteElement as shown in the figure below…

                                      ****************
                                     * BasicObjType *
                                     ****************
                                    ^                ^
                                   /                  \
                                  /                    \
                     **************                    **************
                     * IDElement  *<-------------------* RteElement *
                     **************                    **************
                      ^         ^                       ^         ^
                     /           \                     /           \
                    /             \                   /             \
               ***********    ***********        ***********    ***********
               *  PubID  *--->* DestGrp *        * RteGrp  *--->* RteRec  *
               ***********    ***********        ***********    ***********

As can be seen in this figure, we still maintain the PI to DestGrp and RteGrp to RteRec relationships as well the RteGrp to DestGrp relationship (albeit indirectly). What we gain, however is a direct relationship between the RteRec and the PI which we were missing in the previous model.

I will send the actual XSD in a followup post for further clarity.

:D

---

From: David Schwartz <[email-masked]>
Date: Thu, 1 Mar 2012 03:53:29 +0200

Here are the XSD changes that go along with the previous email - thanks to Mickael for writing this up.

Only the modified types are shown below. This model allows us to define 4 types of associations (as opposed to 1 in the current model) between identifiers and routes. These are:

·           Public identifier - route record

·           Public identifier - route group

·           Destination group - route record

·           Destination group - route group                 // only one that is supported in current model

The PubIdElemType is an abstract type that may represent a single public identifier or a group of public identifiers (namely a destination group).
<complexType name="PubIdElemType" abstract="true">
   <complexContent>
       <extension base="sppfb:BasicObjType">
       </extension>
    </complexContent>
</complexType>

The base type of the PubIdType is now replaced by PubIdElemType.

<complexType name="PubIdType" abstract="true">
    <complexContent>
       <extension base="sppfb:PubIdElemType">
          <sequence>
             <element name="dgName" type="sppfb:ObjNameType" minOccurs="0"/>
          </sequence>
       </extension>
    </complexContent>
</complexType>

The base type of the DestGrpType is now replaced by PubIdElemType.

<complexType name="DestGrpType">
    <complexContent>
       <extension base="sppfb:PubIdElemType">
          <sequence>
             <element name="dgName" type="sppfb:ObjNameType"/>
          </sequence>
       </extension>
    </complexContent>
</complexType>

The TNType is modified since a telephone number can now be associated to routes through the association between PubIdElemType and RouteElemType. The other types of public identifiers remain unchanged.

<complexType name="TNType">
   <complexContent>
      <extension base="sppfb:PubIdType">
         <sequence>
            <element name="tn" type="sppfb:NumberValType"/>
            <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
         </sequence>
      </extension>
   </complexContent>
</complexType>

The RouteElemType is an abstract type that may represent a single route record or a group of route records (namely a route group). You will note that elements associated with peering as well as elements appearing in both RteRec and RteGrp (e.g. Priority) have been moved into this item from the RteGrp

<complexType name="RouteElemType" abstract="true">
   <complexContent>
       <extension base="sppfb:BasicObjType">
          <sequence>
             <element name="pubIdElements" type="sppfb:PubIdElemType"
                           minOccurs="0" maxOccurs="unbounded"/>
              <element name="peeringOrg" type="sppfb:OrgIdType"
                           minOccurs="0" maxOccurs="unbounded"/>
             <element name="sourceIdent"
                           type="sppfb:SourceIdentType"
                           minOccurs="0" maxOccurs="unbounded"/>
             <element name="isInSvc" type="boolean"/>
             <element name="priority" type="unsignedShort"/>
          </sequence>
       </extension>
   </complexContent>
</complexType>

The base type of RteRecType is now replaced by RouteElemType.
<complexType name="RteRecType" abstract="true">
     <complexContent>
           <extension base="sppfb:RouteElemType">
               <sequence>
                   <element name="rrName" type="sppfb:ObjNameType"/>
               </sequence>
       </extension>
     </complexContent>
</complexType>

The base type of the RteGrpType is now replaced by RouteElemType.
<complexType name="RteGrpType">
     <complexContent>
           <extension base="sppfb:RouteElemType">
              <sequence>
                   <element name="rgName" type="sppfb:ObjNameType"/>
                   <element name="rrRef" type="sppfb:RteRecRefType"
                     minOccurs="0" maxOccurs="unbounded"/>
                   <element name="ext" type="sppfb:ExtAnyType"
                      minOccurs="0"/>
              </sequence>
            </extension>
     </complexContent>
</complexType>

On Feb 29, 2012, at 7:34 PM, David Schwartz wrote:

                                      ****************
                                     * BasicObjType *
                                     ****************
                                    ^                ^
                                   /                  \
                                  /                    \

---

From: David Schwartz <[email-masked]>
Date: Thu, 1 Mar 2012 04:33:50 +0200

Here is another change that I would like to propose/discuss…

There are many elements in the model that serve as "attributes" of their container elements. They provide some additional information that in SQL terminology would form the basis of the "where" command. Examples include the corInfo element present in the different types of public identifiers, the priority of a route group and the isInSvc flag of a route group.  There are many additional and useful attributes that are not in the draft (e.g. capacity associated with a route) and while one can always use the built in extensibility mechanism to add additional attributes, the lifecycle of attributes (CRUD) is not defined and as such interoperability is affected.

What I would like to propose is the following. Create an "Attribute" object (example provided below) and allow BasicObjType to add 0 or more such elements thereby enabling any element to take advantage of this specific extension and more importantly future-proffing this protocol. In the SOAP document define the attribute operations (CRUD) and in parallel, write another draft specifying an attribute profile for SPPF which includes the currently "known" attributes such as "priority" and "corInfo". (alternatively, the existing attributes such as corInfo can stay in this draft and the attribute element be used for new attributes).

The current proposal for attributes distinguishes between two kinds of attributes: name-value (e.g. priority=5) and flag attribute (e.g. corInfo).

        ****************  [0..n]  *************
       * BasicObjType *--------->* Attribute *
       ****************          *************
                                   ^       ^
                                  /         \
                                 /           \
                         **********      ***********
                         *  Flag  *      * NameVal *
                         **********      ***********

The AttributeType is an abstract type that represents additional information relating to a BasicObjType

<complexType name="AttributeType" abstract="true">

     <complexContent>

         </sequence>

       </extension>

     </complexContent>

</complexType>

The NameValueType is an attribute of type name=val
<complexType name="NameValueType" abstract="true">

     <complexContent>

           <extension base="sppfb:AttributeType">

               <sequence>

                   <element name="name" type="sppfb:ObjNameType"/>

                   <element name="value" type="sppfb:AttrValueType"

                         minOccurs="0"/>

               </sequence>

       </extension>

     </complexContent>

</complexType>

<simpleType name="AttrValueType">

     <restriction base="token"/>

</simpleType>

The FlagType is an attribute that is boolean true if present

<complexType name="FlagType" abstract="true">

     <complexContent>

           <extension base="sppfb:AttributeType">

               <sequence>

                   <element name="name" type="sppfb:ObjNameType"/>

               </sequence>

       </extension>

     </complexContent>

</complexType>

The BasicObjType is modified as follows
<complexType name="BasicObjType" abstract="true">

      <sequence>

          <element name="rant" type="sppfb:OrgIdType"/>

          <element name="rar" type="sppfb:OrgIdType"/>

          <element name="cDate" type="dateTime"

                             minOccurs="0"/>

          <element name="mDate" type="dateTime"

                             minOccurs="0"/>

          <element name="attributes" type="sppfb:AttributeType"

                             minOccurs="0"/>

      </sequence>

</complexType>

(Thanks to Mickael for XSD code)

Thoughts?

                                      ****************
                                     * BasicObjType *
                                     ****************
                                    ^                ^
                                   /                  \
                                  /                    \