NDMU Protocol Future Development

1
NDM-U Protocol Future Development

• There continues to be an interest in moving
  beyond the D-interface for NDM-U.
• It is useful to consider the currently specd
  capabilities and some future development options,
  including
• Revisiting the SOAP specification and D-interface
  Push.
• Addressing the B-interface, which also may
  address a subset of A-interface scenarios.
• Addressing prepay interactions.

2
NDM-U 3.1 Specd interfaces

• The D-interface is officially specd by NDM-U
  3.1. With a single concrete transfer protocol,
  based on files. In this form only usage data
  exchange, no control is defined.
• The current File Transfer Protocol could be
  thought of as a pass through to the C-interface.
• May be sufficient for batch mode exchange of
  usage with BSS.

3
NDM-U 3.1 SOAP Interface and Xfer Primitives

• The current NDM-U, section 4.4.3 defines
  abstract primitives to provide some control on
  the D-interface (e.g. subscriptions management)
  and enable document push.
• The concrete mapping of the control primitives
  to SOAP is not currently normative nor
  implemented.
• Interest among billing or mediation players to
  utilize this is unclear.

4
NDM-U Interfaces Streaming Protocol

• The current NDM-U spec (sec. 2.4) defines the
  interaction between an IR and IS/IT as streaming
  IPDR records (the B-interface), but leaves the
  mechanism unspecified.
• The model is basically unidirectional. I.e.
  limited interaction back to recorder.
• Consider the possibility of having embedded
  IPDR Recorders in some service elements, as a
  means to address an IPDR A-interface.
• The XDR binding was designed to easily enable
  basic streaming.

5
B-interface use case

• Service Elements which need to avoid storage
  overhead, and deliver usage information in a
  timely manner and compact format, and want to
  take advantage of IPDR service definition model
  and standard formats. Possible candidates
  include
• Content servers
• VoIP gateways
• WAP gateways
• CMTS Servers
• Probes or other Middleboxes (see RFC3234)

6
NDM-U and Prepay

• Prepay involves control. The basic scenario
  involves a Service Element requesting credit to
  deliver a service, a system (mediation?, BSS?)
  interpreting this request, performing rating and
  balance checking/impact, followed by a response
  enabling delivery of service, or denial of
  service in the event of low balance.
• The current definition of A- and D-interfaces
  and the role of an IPDR Recorder, IPDR
  Transmitter and BSS appear overly stretched.
  A different object and interface model may be
  required.

7
Recommendations

• Build a simple B-interface specification
  utilizing the streaming model supported by the
  XDR mapping. Must make provisions for reliable
  delivery and security.
• This expands the applicability of IPDR to many
  service elements, and meets requirements laid out
  in NDM-U section 2.4.2.1.
• Ignore SOAP binding for now, as it doesnt expand
  applicability as much as B-interface.
• This does not expose us to broader changes
  implied by prepay support. For a good discussion
  of prepay requirements seehttp//www.ietf.org/in
  ternet-drafts/draft-hakala-diameter-credit-control
  -03.txt