A NDM-U B-Interface Proposal Jeff Meyer, Hewlett-Packard July 6, 2002 Introduction - Background on current definition of B-interface (record vs. document boundary). See NDM-U 3.1 secton 2.4.1 and 2.4.2 content. - Concept of an "embedded IPDR recorder" to address SE's. An IPDR based A-interface can be accomplished via the currently defined D-interface (file based), or via the newly defined B-interface. - current status of usage delivery from SE's: proprietary implementations, GTP', RADIUS extensions, Diameter Extensions, IPFix. All could benefit from IPDR's standard service definition model, extensibility model, and XML/XDR mapping. And a common, simple, underlying delivery mechanism. - Note on XML vs. XDR format. XML's document oriented nature makes it appropriate at the D-interface, but less practical at the B-interface. The XDR encoding, however, enables both document and streaming models, so it can be applied at both the B- and D-interface. - Goals: - provide a low complexity and efficient interface to stream IPDR records addressing A-interface requirements identify in NDM-U 3.1. - Build on IPDR's existing capabilities and strengths. - minimize impact on existing IPDR specfications - support for custom vendor features - address minimal storage requirements - address reliability - Nongoals: - define control mechanisms to perform administration across B-interface - address prepay scenarios. Trivial TCP Delivery - Design of NDM-U's XDR specification allows for streamed delivery of IPDR records over a TCP connection, without change to the definition (or Java reference implementation, the C reference library does require some modifications). Protocol Procedures o SE initiates a TCP connection to a configured destination and port (may make use of SVRLOC or DNS, ala Diameter). o SE should recognize ICMP no port or TCP rejections and timeouts as indicating the server is unavailable. May try alternate servers. o Upon connection establishment, deliver header and any record descriptors known a priori. o For each service usage event to be recorded, provide an IPDR record of a type compliant with a previously delivered Descriptor. o The SE will continue delivering usage until either: a. The underlying TCP connection indicates a failure. b. Some administrative control function, not defined in this spec, is delivered to shutdown the SE (or usage reporting). o During graceful termination the SE will deliver a DocEnd prior to closing the TCP connection. Illustration An XDR IPDR document is structured as binary data elements as follows: +----------------+ | Header | +----------------+ | Descriptor | +----------------+ | Usage Event | +----------------+ ... +----------------+ | Usage Event | +----------------+ | Doc End | +----------------+ Rather than writing these into a file, the information is written onto a TCP connection. The actual network communication may be structured as: Time t0: <-- TCP Conn Established --> +----------------+ | Header | +----------------+ -- transmitted --> | Descriptor | +----------------+ Time t1 (one or more usage event(s) recorded): +----------------+ | Usage Event | -- transmitted --> +----------------+ ... +----------------+ | Usage Event | +----------------+ Time t2 (more usage event(s) recorded): +----------------+ | Usage Event | -- transmitted --> +----------------+ ... +----------------+ | Usage Event | +----------------+ Continues until some terminating control message arrives and finally at time tn: +----------------+ | Doc End | -- transmitted --> +----------------+ <-- TCP Connection Release --> Note that additional descriptor stream elements MAY be transmitted in the stream along with Usage Events at any time. Security Considerations - Security can be accomplished by using either IPSec or TLS mechanisms when establishing the underlying TCP connection. This is the same security policy used by Diameter, sec (x.x.x) Because the use of IPSec and TLS are transparent to the from the perspective of TCP connection endpoints, the protocol specified here is unchanged. Acknowledged TCP Delivery - A key issue with the trivial scheme is that if the connection is not terminated gracefully, there is no information about which IPDR Records may have been lost in transit. - Some IPDR record producing entities will want to reliably deliver the records to another entity for persistence (i.e. the B-interface). In the event of communication failure with one persistence entity, it is important to identify records which were sent, but need to be retransmitted to another store. The entity producing these records should be prepared to hold onto the records until receiving an acknowledgement from the receiving entity. - In order to support these additional requirements on the B-interface, the existing XDR specification can be trivially modified to: a. reflect a new version of the protocol (version 4). b. add two new "StreamElement" objects to the current set: RecordDescriptor IPDRRecord IPDRDocEnd IPDRAck /* introduced v4 */ IPDRDisconnect /* introduced v4 */ - The new Ack and Disconnect elements contain the following information: BEGIN IDL FRAGMENT ------------------ /* IPDRAck (Version 4 StreamElement) * * An IPDRAck element may be sent by either the producer or * consumer to acknowledge the delivery of IPDR records and * to distinguish between idle channels and broken connections. */ struct IPDRAck { hyper curTime; /* 64-bit time representation, indicates * the current GMT time at the time sent. */ int lastSeqNum; /* The last record sequence number seen * (for consumer) or sent (for producer). * A value of -1 indicates no sequence * numbers seen. */ int timeoutHint; /* Specifies a hint as to how often some * acknowledgement or record should be sent * in the stream to enable faster detection of * disconnect. Expressed in milliseconds. * A value of -1 indicates no ack is requested. * A value of 0 indicates a request for a single * Ack to be transmitted by the peer, ASAP. */ int ipdrCountHint; /* Used only by a producing system to indicate * how many outstanding records should go * unacknowledged. A value of 0 indicates * no ack is requested. Consumers should * always send a value of 0. */ }; /* IPDRDisconnect (Version 4 StreamElement) * * An IPDRDisconnect element is similar to the DocEnd element, * but is more appropriate when communicating over a network * connection. It may be sent by either the producer or consumer * and provides additional information about the status of the * connection. */ struct IPDRDisconnect { hyper curTime; /* 64-bit time representation, indicates * the current GMT time at the time sent. */ int lastSeqNum; /* The last record sequence number seen * (for consumer) or sent (for producer). * A value of -1 indicates no sequence * numbers seen. */ int reasonCode; /* An integer code representing the cause * of the disconnect. * * Reusing the HTTP response code numbering scheme: * 100-199 - informational * 200-299 - client request successful * 300-399 - redirection * 400-499 - client request error * 500-599 - server errors * * Reason codes defined are: * 200 - Normal shutdown request. * 201 - Disconnect in response to peer * disconnect request. * 400 - Restart connection request. * 401 - Stream integrity check error. * 402 - Timeout. * 500 - Server error, shutdown request. */ UTF8String reasonString; /* A string providing additional information * about the disconnect. May be empty. */ }; END IDL FRAGMENT ---------------- Procedures for Reliable Streaming - Same TCP connection model used as in Trivial Streaming. - Ack stream element is written by producer after initial output of header and descriptors to indicate frequency of response acks. - The server contacted should, after seeing an inital ack in the input stream, begin sending a special "IPDRDoc" back to the IPDR Recorder on the same TCP connection. - The server IPDRDoc is used only for control information. It does not contain any IPDR records. - The header information in the server generated IPDRDoc will be restricted as follows: - version shall be 4, version 3 implies trivial protocol. - IPDRRecorderInfo shall use a URI to describe the system which is generating this control IPDRDoc. - defaultNameSpaceURI, otherNameSpaces and serviceDefinitionURIs shall all be empty as indicated by their length fields set to zero. - docId shall match the docId sent by the IPDRRecorder initiating the connection. - After sending the header an initial Ack should be sent. This should indicate any preferences the server has for "hearbeat" acks. These will indicate that the IPDR Recorder is still present during idle periods. It will also allow the detection of inactivity timeouts outside of the underlying TCP mechanism. TCP traditionally takes a very forgiving timeout policy, with system defaults often taking many minutes to mark the TCP connection as failed. Enabling the application a mechanism under their control, operators can more directly control fail over policy. - The timeoutHint and ipdrCountHint sent by the IPDR Recorder suggest values which the consuming application should use to determine the frequency of Ack's being delivered in the control document. If the receiving entity has not sent an Ack within the time period in the timeoutHint, the receiving entity SHOULD send an Ack with the current sequence number and system time sent. The previously used hint values should be repeated. If the receiving entity has not sent an Ack since receiving ipdrCountHit number of records, it SHOULD send an ack with the current sequence number and system time sent. The previously used hint values should be repeated. - Note that the lastSeqNum field is dependent on the use of the seqNum attribute in the IPDRRecords. seqNum is defined in the IPDRDoc base schema, but is optional. A system wishing to maintain records for retransmission on failure must use the seqNum field in order to identify potentially lost records. - As the sequence number approaches the value of 2^31-1 (2524971007), the IPDR Recorder should close and re-establish the connection to avoid rollover. A new document id should be used on the subsequent connection. Illustration Time t0: <-- TCP Conn Established --> +----------------+ | Header | +----------------+ -- transmitted --> | Descriptor | +----------------+ | Ack | +----------------+ +----------------+ | Header | <-- transmitted +----------------+ | Ack | +----------------+ Time t1 (one or more usage event(s) recorded): +----------------+ | Usage Event | -- transmitted --> +----------------+ ... +----------------+ | Usage Event | +----------------+ Time t2 (either time or volume hint triggers Ack): +----------------+ <-- transmitted | Ack | +----------------+ Time t3 (idle period has exceeded hint): +----------------+ | Ack | -- transmitted --> +----------------+ Basic scenario continues until some terminating control message arrives and finally at time tn: +----------------+ | Disconnect | -- transmitted --> +----------------+ +----------------+ <-- transmitted | Disconnect | +----------------+ <-- TCP Connection Release --> Note that additional descriptor stream elements MAY be transmitted in the stream along with Usage Events at any time. Failover Procedure - If an IPDR Recorder determines that it has lost communication with the current peer on the B-interface, it SHOULD: o send a DISCONNECT message with a reason code of 402 and close the current TCP connection o establish a TCP connection with an alternate server. o send a document header using the SAME documentId sent on the previous failed connection. o send the necessary descriptors and Ack stream elements o write the records which were not acknowledged on the previous connection, repeating the sequence numbers used on the previous delivery. o write a DISCONNECT message with reasonCode of 200 into the stream. o follow standard connect procedures to create a new docId and TCP connection to deliver subsequent messages. Note that this connection MAY be created at any time, it may even have been created prior to failure detection, as a "hot standby". Other Underlying Transports The procedures described above, trivial and acknowledged, are only defined on top of TCP connections. It appears that a similar mapping can be used for other reliable transports such as SCTP (RFCxxxx), or HTTP. However these are not currently addressed. These alternatives may prove to have advantages over basic TCP connections in some scenarios. For example Diameter specifies SCTP for some of its unique protocol characteristics. HTTP may be appealing from the perspective of firewall traversal and web services integration. If so, details on binding to these alternate protocols should be developed. In addition to reliable transports, some scenarios may benefit from a mapping to UDP. RADIUS, Netflow and SFlow have all been built on UDP to either eliminate overhead in their protocol stack or to work around some issues with TCP failure procedures. Such a mapping might be addressed by transmitting a full IPDRDoc on each UDP packet. The use of the abbreviated header (as in the ControlStream) could allow for sufficient payload. The Ack scheme would provide the ability to detect some communication errors. However, misordered or gaps in the delivery of IPDR Records would require a more complex retransmission scheme and probably additional information in the Ack payload. Unreliable transport support is a possible area for future development. References NDM-U 3.1 Specification, IPDR.org http://www.ipdr.org/documents/NDM-U_3.1.pdf RADIUS Accounting, Rigney, IETF Informational RFC 2866, http://www.ietf.org/rfc/rfc2866.txt Diameter Base Protocol, draft specification, Calhoun et al, http://www.diameter.org/drafts/latest/draft-ietf-aaa-diameter-11.txt Diameter Credit Control Application, draft specification, Hakala et al, http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-03.txt Requirements for IP Flow Export, draft specification, Quittek et al, http://ipfix.doit.wisc.edu/req/draft-ietf-ipfix-reqs-04.txt 3G call and event data for the Packet Switched (PS) domain, 3GPP, 3GPP TS 32.015 V3.9.0 (2002-03), ftp://ftp.3gpp.org/specs/archive/32_series/32.015/32015-390.zip GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface, 3GPP, 3GPP TS 29.060 V5.2.0 (2002-06), ftp://ftp.3gpp.org/specs/archive/29_series/29.060/29060-520.zip sFlow Protocol, IETF Informational RFC 3176, Phaal et al, http://www.ietf.org/rfc/rfc3176.txt PacketCable Event Messages Specification, CableLabs, PKT-SP-EM-I03-011221 http://www.packetcable.com/specs/PKT-EM-I03-011221.pdf DOCSIS Operations Support System Interface Specification, CableLabs, SP-OSSIv2.0-I02-020617, http://www.cablemodem.com/Specs/SP-OSSIv2.0-I02-020617.pdf