Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7877

Session Peering Provisioning Framework (SPPF)

Pages: 57
Proposed Standard
Part 2 of 3 – Pages 18 to 40
First   Prev   Next

Top   ToC   RFC7877 - Page 18   prevText

6. Framework Data Model Objects

This section provides a description of the specification of each supported data model object (the nouns) and identifies the commands (the verbs) that MUST be supported for each data model object. However, the specification of the data structures necessary to support each command is delegated to an SPPF-conforming substrate "protocol" specification.

6.1. Destination Group

A Destination Group represents a logical grouping of Public Identifiers with common SED. The substrate protocol MUST support the ability to Add, Get, and Delete Destination Groups (refer to Section 7 for a generic description of various operations). A Destination Group object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).
Top   ToC   RFC7877 - Page 19
   The DestGrpType object structure is defined as follows:

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

   The DestGrpType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  dgName: The character string that contains the name of the
      Destination Group.

   o  ext: Point of extensibility described in Section 3.3.

6.2. Public Identifier

A Public Identifier is the search key used for locating the SED. In many cases, a Public Identifier is attributed to the end user who has a retail relationship with the SP or Registrant organization. SPPF supports the notion of the carrier-of-record as defined in [RFC5067]. Therefore, the Registrant under which the Public Identifier is being created can optionally claim to be a carrier-of-record. SPPF identifies three types of Public Identifiers: TNs, RNs, and URIs. SPPF provides structures to manage a single TN, a contiguous range of TNs, and a TN prefix. The substrate protocol MUST support the ability to Add, Get, and Delete Public Identifiers (refer to Section 7 for a generic description of various operations). A Public Identity object MUST be uniquely identified by attributes as defined in the description of "PubIdKeyType" in Section 5.2.2.
Top   ToC   RFC7877 - Page 20
   The abstract XSD type PubIdType is a generalization for the concrete
   Public Identifier schema types.  The PubIdType element "dgName"
   represents the name of a Destination Group of which a given Public
   Identifier may be a member.  Note that this element may be present
   multiple times so that a given Public Identifier may be a member of
   multiple Destination Groups.  The PubIdType object structure is
   defined as follows:

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

   A Public Identifier may be a member of zero or more Destination
   Groups.  When a Public Identifier is a member of a Destination Group,
   it is intended to be associated with SED through the SED Group(s)
   that is associated with the Destination Group.  When a Public
   Identifier is not member of any Destination Group, it is intended to
   be associated with SED through the SED Records that are directly
   associated with the Public Identifier.
Top   ToC   RFC7877 - Page 21
   A TN is provisioned using the TNType, an extension of PubIdType.
   Each TNType object is uniquely identified by the combination of its
   value contained within the <tn> element and its Registrant ID.
   TNType is defined as follows:

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

   <complexType name="CORInfoType">
    <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
    </sequence>
   </complexType>

   <simpleType name="NumberValType">
    <restriction base="token">
     <maxLength value="20"/>
     <pattern value="\+?\d\d*"/>
    </restriction>
   </simpleType>

   TNType consists of the following attributes:

   o  tn: Telephone number to be added to the Registry.

   o  sedRecRef: Optional reference to SED Records that are directly
      associated with the TN Public Identifier.  Following the SPPF data
      model, the SED Record could be a protocol-agnostic URIType or
      another type.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).  This is done by setting the
      value of the <corClaim> element of the CORInfoType object
      structure to "true".  The other two parameters of the CORInfoType,
      <cor> and <corDate>, are set by the Registry to describe the
Top   ToC   RFC7877 - Page 22
      outcome of the carrier-of-record claim by the Registrant.  In
      general, inclusion of the <corInfo> parameter is useful if the
      Registry has the authority information, such as the number
      portability data, etc., in order to qualify whether the Registrant
      claim can be satisfied.  If the carrier-of-record claim disagrees
      with the authority data in the Registry, whether or not a TN Add
      operation fails is a matter of policy and is beyond the scope of
      this document.

   An RN is provisioned using the RNType, an extension of PubIDType.
   The Registrant organization can add the RN and associate it with the
   appropriate Destination Group(s) to share the route information.
   This allows SSPs to use the RN search key to derive the Ingress
   Routes for session establishment at the runtime resolution process
   (see [RFC6116]).  Each RNType object is uniquely identified by the
   combination of its value inside the <rn> element and its Registrant
   ID.  RNType is defined as follows:

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

   RNType has the following attributes:

   o  rn: The RN used as the search key.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).

   TNRType structure is used to provision a contiguous range of TNs.
   The object definition requires a starting TN and an ending TN that
   together define the span of the TN range, including the starting and
   ending TN.  Use of TNRType is particularly useful when expressing a
   TN range that does not include all the TNs within a TN block or
   prefix.  The TNRType definition accommodates the open number plan as
   well such that the TNs that fall in the range between the start and
   end TN may include TNs with different length variance.  Whether the
   Registry can accommodate the open number plan semantics is a matter
   of policy and is beyond the scope of this document.  Each TNRType
   object is uniquely identified by the combination of its value that,
Top   ToC   RFC7877 - Page 23
   in turn, is a combination of the <startTn> and <endTn> elements and
   its Registrant ID.  The TNRType object structure definition is as
   follows:

   <complexType name="TNRType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="range" type="sppfb:NumberRangeType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="NumberRangeType">
    <sequence>
     <element name="startTn" type="sppfb:NumberValType"/>
     <element name="endTn" type="sppfb:NumberValType"/>
    </sequence>
   </complexType>

   TNRType has the following attributes:

   o  startTn: The starting TN in the TN range.

   o  endTn: The last TN in the TN range.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).
Top   ToC   RFC7877 - Page 24
   In some cases, it is useful to describe a set of TNs with the help of
   the first few digits of the TN, also referred to as the TN prefix or
   a block.  A given TN prefix may include TNs with different length
   variance in support of the open number plan.  Once again, whether the
   Registry supports the open number plan semantics is a matter of
   policy, and it is beyond the scope of this document.  The TNPType
   data structure is used to provision a TN prefix.  Each TNPType object
   is uniquely identified by the combination of its value in the
   <tnPrefix> element and its Registrant ID.  TNPType is defined as
   follows:

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

   TNPType consists of the following attributes:

   o  tnPrefix: The TN prefix.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).

   In some cases, a Public Identifier may be a URI, such as an email
   address.  The URIPubIdType object is comprised of the data element
   necessary to house such Public Identifiers.  Each URIPubIdType object
   is uniquely identified by the combination of its value in the <uri>
   element and its Registrant ID.  URIPubIdType is defined as follows:

   <complexType name="URIPubIdType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>
Top   ToC   RFC7877 - Page 25
   URIPubIdType consists of the following attributes:

   o  uri: The value that acts as the Public Identifier.

   o  ext: Point of extensibility described in Section 3.3.

6.3. SED Group

SED Group is a grouping of one or more Destination Groups, the common SED Records, and the list of peer organizations with access to the SED Records associated with a given SED Group. It is this indirect linking of Public Identifiers to their SED that significantly improves the scalability and manageability of the peering data. Additions and changes to SED information are reduced to a single operation on a SED Group or SED Record rather than millions of data updates to individual Public Identifier records that individually contain their peering data. The substrate protocol MUST support the ability to Add, Get, and Delete SED Groups (refer to Section 7 for a generic description of various operations). A SED Group object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document).
Top   ToC   RFC7877 - Page 26
   The SedGrpType object structure is defined as follows:

   <complexType name="SedGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpName" type="sppfb:ObjNameType"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="dgName" type="sppfb:ObjNameType"
                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"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="SedRecRefType">
    <sequence>
     <element name="sedKey" type="sppfb:ObjKeyType"/>
     <element name="priority" type="unsignedShort"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>

   The SedGrpType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  sedGrpName: The character string that contains the name of the SED
      Group.  It uniquely identifies this object within the context of
      the Registrant ID (a child element of the base element as
      described above).

   o  sedRecRef: Set of zero or more objects of type SedRecRefType that
      house the unique keys of the SED Records (containing the SED) that
      the SedGrpType object refers to and their relative priority within
      the context of this SED Group.
Top   ToC   RFC7877 - Page 27
   o  dgName: Set of zero or more names of DestGrpType object instances.
      Each dgName name, in association with this SED Group's Registrant
      ID, uniquely identifies a DestGrpType object instance whose
      associated Public Identifiers are reachable using the SED housed
      in this SED Group.  An intended side effect of this is that a SED
      Group cannot provide session establishment information for a
      Destination Group belonging to another Registrant.

   o  peeringOrg: Set of zero or more peering organization IDs that have
      accepted an offer to receive this SED Group's information.  Note
      that this identifier "peeringOrg" is an instance of OrgIdType.
      The set of peering organizations in this list is not directly
      settable or modifiable using the addSedGrpsRqst operation.  This
      set is instead controlled using the SED Offer and Accept
      operations.

   o  sourceIdent: Set of zero or more SourceIdentType object instances.
      These objects, described further below, house the source
      identification schemes and identifiers that are applied at
      resolution time as part of source-based routing algorithms for the
      SED Group.

   o  isInSvc: A boolean element that defines whether this SED Group is
      in service.  The SED contained in a SED Group that is in service
      is a candidate for inclusion in resolution responses for Public
      Identities residing in the Destination Group associated with this
      SED Group.  The session establishment information contained in a
      SED Group that is not in service is not a candidate for inclusion
      in resolution responses.

   o  priority: Priority value that can be used to provide a relative
      value weighting of one SED Group over another.  The manner in
      which this value is used, perhaps in conjunction with other
      factors, is a matter of policy.

   o  ext: Point of extensibility described in Section 3.3.

   As described above, the SED Group contains a set of references to SED
   Record objects.  A SED Record object is based on an abstract type:
   SedRecType.  The concrete types that use SedRecType as an extension
   base are NAPTRType, NSType, and URIType.  The definitions of these
   types are included in "SED Record" (Section 6.4 of this document).

   The SedGrpType object provides support for source-based routing via
   the peeringOrg data element and more granular source-based routing
   via the source identity element.  The source identity element
   provides the ability to specify zero or more of the following in
   association with a given SED Group: a regular expression that is
Top   ToC   RFC7877 - Page 28
   matched against the resolution client IP address, a regular
   expression that is matched against the root domain name(s), and/or a
   regular expression that is matched against the calling party URI(s).
   The result will be that, after identifying the visible SED Groups
   whose associated Destination Group(s) contains the lookup key being
   queried and whose peeringOrg list contains the querying
   organization's organization ID, the resolution server will evaluate
   the characteristics of the Source URI, Source IP address, and root
   domain of the lookup key being queried.  The resolution server then
   compares these criteria against the source identity criteria
   associated with the SED Groups.  The SED contained in SED Groups that
   have source-based routing criteria will only be included in the
   resolution response if one or more of the criteria matches the source
   criteria from the resolution request.  The source identity data
   element is of type SourceIdentType, whose structure is defined as
   follows:

   <complexType name="SourceIdentType">
    <sequence>
     <element name="sourceIdentRegex" type="sppfb:RegexType"/>
     <element name="sourceIdentScheme"
              type="sppfb:SourceIdentSchemeType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>

   <simpleType name="SourceIdentSchemeType">
    <restriction base="token">
     <enumeration value="uri"/>
     <enumeration value="ip"/>
     <enumeration value="rootDomain"/>
    </restriction>
   </simpleType>

   The SourceIdentType object is composed of the following data
   elements:

   o  sourceIdentScheme: The source identification scheme that this
      source identification criteria applies to and that the associated
      sourceIdentRegex should be matched against.

   o  sourceIdentRegex: The regular expression that should be used to
      test for a match against the portion of the resolution request
      that is dictated by the associated sourceIdentScheme.

   o  ext: Point of extensibility described in Section 3.3.
Top   ToC   RFC7877 - Page 29

6.4. SED Record

SED Group represents a combined grouping of SED Records that define SED. However, SED Records need not be created to just serve a single SED Group. SED Records can be created and managed to serve multiple SED Groups. As a result, a change, for example, to the properties of a network node used for multiple routes would necessitate just a single update operation to change the properties of that node. The change would then be reflected in all the SED Groups whose SED Record set contains a reference to that node. The substrate protocol MUST support the ability to Add, Get, and Delete SED Records (refer to Section 7 for a generic description of various operations). A SED Record object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document). The SedRecType object structure is defined as follows: <complexType name="SedRecType" abstract="true"> <complexContent> <extension base="sppfb:BasicObjType"> <sequence> <element name="sedName" type="sppfb:ObjNameType"/> <element name="sedFunction" type="sppfb:SedFunctionType" minOccurs="0"/> <element name="isInSvc" type="boolean"/> <element name="ttl" type="positiveInteger" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType> <simpleType name="SedFunctionType"> <restriction base="token"> <enumeration value="routing"/> <enumeration value="lookup"/> </restriction> </simpleType> The SedRecType object is composed of the following elements: o base: All first-class objects extend BasicObjType (see Section 5.1).
Top   ToC   RFC7877 - Page 30
   o  sedName: The character string that contains the name of the SED
      Record.  It uniquely identifies this object within the context of
      the Registrant ID (a child element of the base element as
      described above).

   o  sedFunction: As described in [RFC6461], SED falls primarily into
      one of two categories or functions: LUF and LRF.  To remove any
      ambiguity as to the function a SED Record is intended to provide,
      this optional element allows the provisioning party to make its
      intentions explicit.

   o  isInSvc: A boolean element that defines whether or not this SED
      Record is in service.  The session establishment information
      contained in a SED Record that is in service is a candidate for
      inclusion in resolution responses for TNs that are either directly
      associated to this SED Record or for Public Identities residing in
      a Destination Group that is associated to a SED Group, which, in
      turn, has an association to this SED Record.

   o  ttl: Number of seconds that an addressing server may cache a
      particular SED Record.

   As described above, SED Records are based on abstract type
   SedRecType.  The concrete types that use SedRecType as an extension
   base are NAPTRType, NSType, and URIType.  The definitions of these
   types are included below.  The NAPTRType object is comprised of the
   data elements necessary for a Naming Authority Pointer (NAPTR) (see
   [RFC3403]) that contains routing information for a SED Group.  The
   NSType object is comprised of the data elements necessary for a DNS
   name server that points to another DNS server that contains the
   desired routing information.  The NSType is relevant only when the
   resolution protocol is ENUM (see [RFC6116]).  The URIType object is
   comprised of the data elements necessary to house a URI.

   The data provisioned in a Registry can be leveraged for many purposes
   and queried using various protocols including SIP, ENUM, and others.
   As such, the resolution data represented by the SED Records must be
   in a form suitable for transport using one of these protocols.  In
   the NAPTRType, for example, if the URI is associated with a
   Destination Group, the user part of the replacement string <uri> that
   may require the Public Identifier cannot be preset.  As a SIP
   Redirect, the resolution server will apply <ere> pattern on the input
   Public Identifier in the query and process the replacement string by
   substituting any back references in the <uri> to arrive at the final
   URI that is returned in the SIP Contact header.  For an ENUM query,
   the resolution server will simply return the values of the <ere> and
   <uri> members of the URI.
Top   ToC   RFC7877 - Page 31
   <complexType name="NAPTRType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="order" type="unsignedShort"/>
       <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
       <element name="svcs" type="sppfb:SvcType"/>
       <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
       <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="NSType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="hostName" type="token"/>
       <element name="ipAddr" type="sppfb:IPAddrType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="IPAddrType">
    <sequence>
     <element name="addr" type="sppfb:AddrStringType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
    <attribute name="type" type="sppfb:IPType" default="IPv4"/>
   </complexType>

   <simpleType name="IPType">
    <restriction base="token">
     <enumeration value="IPv4"/>
     <enumeration value="IPv6"/>
    </restriction>
   </simpleType>

   <complexType name="URIType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="ere" type="token" default="^(.*)$"/>
Top   ToC   RFC7877 - Page 32
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <simpleType name="flagsType">
    <restriction base="token">
     <length value="1"/>
     <pattern value="[A-Z]|[a-z]|[0-9]"/>
    </restriction>
   </simpleType>

   The NAPTRType object is composed of the following elements:

   o  order: Order value in an ENUM NAPTR, relative to other NAPTRType
      objects in the same SED Group.

   o  svcs: ENUM service(s) that is served by the SBE.  This field's
      value must be of the form specified in [RFC6116] (e.g.,
      E2U+pstn:sip+sip).  The allowable values are a matter of policy
      and are not limited by this protocol.

   o  regx: NAPTR's regular expression field.  If this is not included,
      then the repl field must be included.

   o  repl: NAPTR replacement field; it should only be provided if the
      regx field is not provided; otherwise, the server will ignore it.

   o  ext: Point of extensibility described in Section 3.3.

   The NSType object is composed of the following elements:

   o  hostName: Root-relative host name of the name server.

   o  ipAddr: Zero or more objects of type IpAddrType.  Each object
      holds an IP Address and the IP Address type ("IPv4" or "IPv6").

   o  ext: Point of extensibility described in Section 3.3.

   The URIType object is composed of the following elements:

   o  ere: The POSIX Extended Regular Expression (ere) as defined in
      [RFC3986].
Top   ToC   RFC7877 - Page 33
   o  uri: the URI as defined in [RFC3986].  In some cases, this will
      serve as the replacement string, and it will be left to the
      resolution server to arrive at the final usable URI.

6.5. SED Group Offer

The list of peer organizations whose resolution responses can include the SED contained in a given SED Group is controlled by the organization to which a SED Group object belongs (its Registrant) and the peer organization that submits resolution requests (a data recipient, also known as a peering organization). The Registrant offers access to a SED Group by submitting a SED Group Offer. The data recipient can then accept or reject that offer. Not until access to a SED Group has been offered and accepted will the data recipient's organization ID be included in the peeringOrg list in a SED Group object, and that SED Group's peering information becomes a candidate for inclusion in the responses to the resolution requests submitted by that data recipient. The substrate protocol MUST support the ability to Add, Get, Delete, Accept, and Reject SED Group Offers (refer to Section 7 for a generic description of various operations). A SED Group Offer object MUST be uniquely identified by attributes as defined in the description of "SedGrpOfferKeyType" in "Derived Object Key Types" (Section 5.2.2 of this document).
Top   ToC   RFC7877 - Page 34
   The SedGrpOfferType object structure is defined as follows:

   <complexType name="SedGrpOfferType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
       <element name="status" type="sppfb:SedGrpOfferStatusType"/>
       <element name="offerDateTime" type="dateTime"/>
       <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="SedGrpOfferKeyType" abstract="true">
    <annotation>
     <documentation>
     -- Generic type that represents the key for a SED Group Offer. Must
        be defined in concrete form in a substrate "protocol"
        specification. --
     </documentation>
    </annotation>
   </complexType>

   <simpleType name="SedGrpOfferStatusType">
    <restriction base="token">
     <enumeration value="offered"/>
     <enumeration value="accepted"/>
    </restriction>
   </simpleType>

   The SedGrpOfferType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  sedGrpOfferKey: The object that identifies the SED that is or has
      been offered and the organization to which it is or has been
      offered.

   o  status: The status of the offer, offered or accepted.  The server
      controls the status.  It is automatically set to "offered"
      whenever a new SED Group Offer is added and is automatically set
      to "accepted" if and when that offer is accepted.  The value of
      the element is ignored when passed in by the client.
Top   ToC   RFC7877 - Page 35
   o  offerDateTime: Date and time in UTC when the SED Group Offer was
      added.

   o  acceptDateTime: Date and time in UTC when the SED Group Offer was
      accepted.

6.6. Egress Route

In a high-availability environment, the originating SSP likely has more than one egress path to the ingress SBE of the target SSP. If the originating SSP wants to exercise greater control and choose a specific egress SBE to be associated to the target ingress SBE, it can do so using the EgrRteType object. An Egress Route object MUST be uniquely identified by attributes as defined in the description of "ObjKeyType" in "Generic Object Key Type" (Section 5.2.1 of this document). Assume that the target SSP has offered, as part of its SED, to share one or more Ingress Routes and that the originating SSP has accepted the offer. In order to add the Egress Route to the Registry, the originating SSP uses a valid regular expression to rewrite the Ingress Route in order to include the egress SBE information. Also, more than one Egress Route can be associated with a given Ingress Route in support of fault-tolerant configurations. The supporting SPPF structure provides a way to include route precedence information to help manage traffic to more than one outbound egress SBE. The substrate protocol MUST support the ability to Add, Get, and Delete Egress Routes (refer to Section 7 for a generic description of various operations). The EgrRteType object structure is defined as follows: <complexType name="EgrRteType"> <complexContent> <extension base="sppfb:BasicObjType"> <sequence> <element name="egrRteName" type="sppfb:ObjNameType"/> <element name="pref" type="unsignedShort"/> <element name="regxRewriteRule" type="sppfb:RegexParamType"/> <element name="ingrSedGrp" type="sppfb:ObjKeyType" minOccurs="0" maxOccurs="unbounded"/> <element name="svcs" type="sppfb:SvcType" minOccurs="0"/> <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/> </sequence> </extension> </complexContent> </complexType>
Top   ToC   RFC7877 - Page 36
   The EgrRteType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  egrRteName: The name of the Egress Route.

   o  pref: The preference of this Egress Route relative to other Egress
      Routes that may get selected when responding to a resolution
      request.

   o  regxRewriteRule: The regular expression rewrite rule that should
      be applied to the regular expression of the ingress NAPTR(s) that
      belongs to the Ingress Route.

   o  ingrSedGrp: The ingress SED Group that the Egress Route should be
      used for.

   o  svcs: ENUM service(s) that is served by an Egress Route.  This
      element is used to identify the ingress NAPTRs associated with the
      SED Group to which an Egress Route's regxRewriteRule should be
      applied.  If no ENUM service(s) is associated with an Egress
      Route, then the Egress Route's regxRewriteRule should be applied
      to all the NAPTRs associated with the SED Group.  This field's
      value must be of the form specified in [RFC6116] (e.g.,
      E2U+pstn:sip+sip).  The allowable values are a matter of policy
      and are not limited by this protocol.

   o  ext: Point of extensibility described in Section 3.3.

7. Framework Operations

In addition to the operation-specific object types, all operations MAY specify the minor version of the protocol that when used in conjunction with the major version (which can be, for instance, specified in the protocol Namespace) can serve to identify the version of the SPPF protocol that the client is using. If the minor version is not specified, the latest minor version supported by the SPPF server for the given major version will be used. Additionally, operations that may potentially modify persistent protocol objects SHOULD include a transaction ID as well.
Top   ToC   RFC7877 - Page 37

7.1. Add Operation

Any conforming substrate "protocol" specification MUST provide a definition for the operation that adds one or more SPPF objects into the Registry. If the object, as identified by the request attributes that form part of the object's key, does not exist, then the Registry MUST create the object. If the object does exist, then the Registry MUST replace the current properties of the object with the properties passed in as part of the Add operation. Note that this effectively allows modification of a preexisting object. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from amongst the response messages defined in "Response Message Types" (Section 5.3 of this document).

7.2. Delete Operation

Any conforming substrate "protocol" specification MUST provide a definition for the operation that deletes one or more SPPF objects from the Registry using the object's key. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from amongst the response messages defined in "Response Message Types" (Section 5.3 of this document). When an object is deleted, any references to that object must of course also be removed as the SPPF server implementation fulfills the deletion request. Furthermore, the deletion of a composite object must also result in the deletion of the objects it contains. As a result, the following rules apply to the deletion of SPPF object types: o Destination Groups: When a Destination Group is deleted, any cross-references between that destination group and any SED Group must be automatically removed by the SPPF implementation as part of fulfilling the deletion request. Similarly, any cross- references between that Destination Group and any Public Identifier must be removed by the SPPF implementation. o SED Groups: When a SED Group is deleted, any references between that SED Group and any Destination Group must be automatically removed by the SPPF implementation as part of fulfilling the deletion request. Similarly, any cross-references between that SED Group and any SED Records must be removed by the SPPF
Top   ToC   RFC7877 - Page 38
      implementation as part of fulfilling the deletion request.
      Furthermore, SED Group Offers relating to that SED Group must also
      be deleted.

   o  SED Records: When a SED Record is deleted, any cross-references
      between that SED Record and any SED Group must be removed by the
      SPPF implementation as part of fulfilling the deletion request.
      Similarly, any reference between that SED Record and any Public
      Identifier must be removed by the SPPF implementation.

   o  Public Identifiers: When a Public Identifier is deleted, any
      cross-references between that Public Identifier and any referenced
      Destination Group must be removed by the SPPF implementation as
      part of fulfilling the deletion request.  Any references to SED
      Records associated directly to that Public Identifier must also be
      deleted by the SPPF implementation.

   Deletes MUST be atomic.

7.3. Get Operations

At times, on behalf of the Registrant, the Registrar may need to get information about SPPF objects that were previously provisioned in the Registry. A few examples include logging, auditing, and pre- provisioning dependency checking. This query mechanism is limited to aid provisioning scenarios and should not be confused with query protocols provided as part of the resolution system (e.g., ENUM and SIP). Any conforming "protocol" specification MUST provide a definition for the operation that queries the details of one or more SPPF objects from the Registry using the object's key. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from among the response messages defined in Section 5.3. If the response to the Get operation includes an object(s) that extends the BasicObjType, the Registry MUST include the "cDate" and "mDate", if applicable.

7.4. Accept Operations

In SPPF, a SED Group Offer can be accepted or rejected by, or on behalf of, the Registrant to which the SED Group has been offered (refer to Section 6.5 of this document for a description of the SED Group Offer object). The Accept operation is used to accept the SED Group Offers. Any conforming substrate "protocol" specification MUST provide a definition for the operation to accept SED Group Offers by,
Top   ToC   RFC7877 - Page 39
   or on behalf of, the Registrant, using the SED Group Offer object
   key.

   Not until access to a SED Group has been offered and accepted will
   the Registrant's organization ID be included in the peeringOrg list
   in that SED Group object, and that SED Group's peering information
   becomes a candidate for inclusion in the responses to the resolution
   requests submitted by that Registrant.  A SED Group Offer that is in
   the "offered" status is accepted by, or on behalf of, the Registrant
   to which it has been offered.  When the SED Group Offer is accepted,
   the SED Group Offer is moved to the "accepted" status and the data
   recipient's organization ID is added into the list of peerOrgIds for
   that SED Group.

   If the entity that issued the command is not authorized to perform
   this operation, an appropriate error message MUST be returned from
   amongst the response messages defined in "Response Message Types"
   (Section 5.3 of this document).

7.5. Reject Operations

In SPPF, a SED Group Offer object can be accepted or rejected by, or on behalf of, the Registrant to which the SED Group has been offered (refer to "Framework Data Model Objects", Section 6 of this document, for a description of the SED Group Offer object). Furthermore, that offer may be rejected, regardless of whether or not it has been previously accepted. The Reject operation is used to reject the SED Group Offer. When the SED Group Offer is rejected, that SED Group Offer is deleted, and, if appropriate, the data recipient's organization ID is removed from the list of peeringOrg IDs for that SED Group. Any conforming substrate "protocol" specification MUST provide a definition for the operation to reject SED Group Offers by, or on behalf of, the Registrant, using the SED Group Offer object key. If the entity that issued the command is not authorized to perform this operation, an appropriate error message MUST be returned from among the response messages defined in "Response Message Types" (Section 5.3 of this document).

7.6. Get Server Details Operation

In SPPF, the Get Server Details operation can be used to request certain details about the SPPF server that include the SPPF server's current status and the major/minor version of the SPPF protocol supported by the SPPF server.
Top   ToC   RFC7877 - Page 40
   Any conforming substrate "protocol" specification MUST provide a
   definition for the operation to request such details from the SPPF
   server.  If the entity that issued the command is not authorized to
   perform this operation, an appropriate error message MUST be returned
   from among the response messages defined in "Response Message Types"
   (Section 5.3 of this document).



(page 40 continued on part 3)

Next Section