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
)
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
