Subject: [DMM] FPC - Changes to ServiceGroup (dropping ServiceEndpoint)

From: Lyle Bertz <[email-masked]>
Date: Tue, 27 Mar 2018 12:19:37 -0500

This is the last change for FPC and was mentioned last week. This is the
Background, Motivation & Summary.   As discussed, we will focus on
examples, editing and NMDA.

Comments are appreciated.

FPC Authors

BACKGROUND
The selection of a DPN, User Plane Function or even Diameter applications
is initially performed via RFC 3958.  This Simple Name Pointer (S-NAPTR)
has the following format.

;;               order pref flags
IN NAPTR   100   10.   “”     “[ [app-service] *(":" app-protocol)]” ( ;
service
                      “”                      ; regex
                      “<interface>.<hostname>”  ;  replacement
                                          )

NOTE - I am using a interface.hostname example here but other replacement
strings apply.  Please look @ the RFC for detail.

This solution has worked well for the selection of an interface it merely
guarantees the application service and application protocol(s) are
provided.  In production networks operators have failed to negotiate links
based upon RFC 3958 when a Feature or Setting that is relevant to the
application user’s needs are not met.   One workaround could be placed into
the DNS entry but then it requires a new RFC or use of the regex (and a new
RFC).   It is still not a viable option if the protocol dynamically
negotiates, shuts off features (for example during overload), etc.  In this
case the DNS record would have to be in sync with DNS.

It is best to characterize the use of RFC 3958 as a mechanism by which a
Client can find an application and application protocol endpoint but it
does not guarantee a successful connection.  This results in retry attempts
at the risk of timeouts in the Control plane.

MOTIVATION
The motivation for ServiceGroup/ServiceEndpoint is to provide an
information model that enables a simple selection mechanism that can be
executed by FPC Client or Agent that provide a high probability of
successful connectivity.    However, there is a lot of overlap between the
ServiceGroup and ServiceEndpoint and we have eliminated ServiceEndpoint
while making modifications.

Below is the new language.

   A Service-Group is collection of DPN interfaces serving some data-
   plane purpose *including but not limited to DPN Interface selection to
   fulfill a Mobility-Context.*  Each Group contains a list of DPNs
(referenced by
   DPN-Key) and selected interfaces (referenced by Interface-Key).  The
   Interfaces are listed explicitly (rather than referred implicitly by
   its specific DPN) so that every Interface of a DPN is not required to
   be part of the Group.  The information provided is sufficient to ensure
that
   the Protocol, Settings and Features relevant to successful connectivity
is
   present in the model.
        |
        +-[Service-Group] <G-Key>, <Name> (O) <Set>
        |           +-[Extensible: FALSE]
        |           +-[Role] <U-Key>
        |           +-[Protocol] <Set>
        |           +-[Features] <Set> (O)
        |           +-[Settings] <Set> (O)
        |           +-[DPN-Key] <Set>
        |           |           +-[Referenced-Interface] <Set>
        |           |           |       +-[Interface-Key] <L-Key>
        |           |           |       +-[Peer-Service-Group-Key] <Set> (O)

                          Figure 8: Service Group

   Each Service-Group contains the following information:

   Service-Group (Key):  A unique ID of the Service-Group

   Service-Group (Name):  a human-readable display string
   Role:   the role (MAG, LMA, PGW, AMF etc.) of the device hosting the
      interfaces of the DPN Group.

    Protocol: The set of protocols supported by this interface (e.g.,
         PMIP, S5-GTP, S5-PMIP etc.).   The protocol is MAY be ‘gtp’ but
many
    protocols implement specific message sets, e.g. s5-pmip, s8-pmip.
    When a protocol implements such message sub-subsets the
    Protocol value MUST include this information.
     Features (optional): a set of static features which further
         determine the suitability of the interface to the desired
         operation for which selection is underway.

     Settings (optional): configurable settings that further
         determine the suitability of an interface for the specific
         request.  For example: SequenceNumber=ON/OFF.*
     DPN-Key (Key):  a key used to identify the DPN.
               Referenced-Interface: <Set>  The *DPN* Interfaces and peer
Service-Groups
                      associated with them.  Each entry contains
             Interface-Key:   a key that is used together with the DPN-Key,
to
                    create a key that is referred to be the interface
definition of
                 DPNs
             Peer-Service-Group-Key:   Enables location of the peer Service
                    Group for this Interface.

IN the DPN definition the Settings value is also present but has a slightly
different definition.

Settings (optional): configurable settings of an interface that
    does not determine the suitability of an interface for the specific
         request.

As a cross check, COMPATIBILITY with RFC 3958 can be maintained

;;               order pref flags
IN NAPTR   100   10.   “”     “[ [<FPC Role>] *(":" <FPC Protocol>)]” ( ;
service
                      “”                      ; regex
                      “<FPC Interface-Key (or Displayable Name)>.<hostname
of DPN>”  ;  replacement
                                          )