Internet-Draft Vishal Verma
Document: draft-verma-sdmp-00.txt Sonim Technologies
Expires:1st August,2003 1st Feb,2003
STATIC DICTIONARY MANIPULATION PROTOCOL
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes protocol with which content at endpoints can
be synchronized with logical entity named as content controller(CoC).
One of the application of this protocol includes management and
synchronization of static dictionary at SigComp devices.Protocol deals
with management and synchronization of content among devices in the
network and is independent of content format.
Verma V. [Page 1]
Internet draft SDMP 1 Feb 2003
TABLE OF CONTENTS
1. INTRODUCTION.................................................3
2. TERMINOLOGY .................................................3
3. ABBREVIATIONS................................................4
4. SDMP ARCHITECTURE OVERVIEW...................................4
5. SDMP FUNCTIONALITIES.........................................5
5.1 FUNCTIONALITIES OF DEVICE.................................5
5.1.1 MANDATORY REQUIREMENTS...............................5
5.1.2 OPTIONAL REQUIREMENTS................................5
5.2 FUNCTIONALITIES OF CONTENT CONTROLLER.....................5
5.1.1 MANDATORY FUNCTIONALITIES............................5
5.1.2 OPTIONAL FUNCTIONALITIES.............................6
6. SDMP COMMAND.................................................6
6.1 COMMAND FORMAT............................................6
6.2 SDMP FIELDS...............................................7
6.2.1 TYPE..................................................7
6.2.2 VERSION...............................................7
6.2.3 COMMAND CODE..........................................7
6.2.4 COMMAND ID............................................7
6.2.5 CONTENT ID............................................7
6.2.6 CONTENT-LENGTH........................................7
6.2.7 DESTINATION,SOURCE IDENTIFIER.........................8
6.2.8 MAX MESSAGE SIZE......................................8
6.2.9 NUM OF COMMANDS.......................................8
6.2.10 REASON................................................8
6.2.11 SEQUENCE NUMBER.......................................8
6.2.12 TRANSPORT TYPE........................................8
6.3 COMMAND TYPE...............................................9
6.3.1 CREATE................................................9
6.3.2 DESTROY...............................................9
6.3.3 SYNCHRONIZE...........................................9
6.3.4 OVERWRITE.............................................10
7. SDMP RESPONSE................................................10
8. TRANSPORT LAYER CONSIDERATIONS...............................11
9. RETRANSMITION OF SDMP MESSAGES...............................11
10. SIGNALLING EXAMPLES..........................................11
10.1 Content creation(invoked by CoC).........................11
10.2 Content creation(invoked by device)......................12
11. SECURITY CONSIDERATION.......................................13
12. REFERENCES ..................................................13
12.1 NORMATIVE REFERENCES.....................................13
12.2 INFORMATIVE REFERENCES...................................14
14. CONTACT......................................................14
Verma V. [Page 2]
Internet draft SDMP 1 Feb 2003
1. INTRODUCTION
Signalling compression(SigComp)[SIGCOMP] provides mechanism to
compress SIP[SIP],SDP[SDP] protocol messages. Decreased message size
helped in reducing call setup time and better utilization of
bandwidth links. SigComp employs the use of static dictionary which
resolves operation code in message into protocol text but static
dictionary based compression/decompression requires static dictionary
synchronization among all SigComp endpoints.
If static dictionary were to upgrade or change,it had to be
upgraded manually at the server as well as all the SigComp enabled
devices in the network which is sometimes nearly impossible. In case
of any minor,major changes in dictionary content will require major
administrative efforts. This document describes mechanism known as
SDMP with which content at SigComp device can be synchronized.SDMP
defines two logical entities namely Content Controller(CoC) and
(SigComp enabled)device. Coc and SigComp device interacts using SDMP
protocol.
SDMP Applications include but not limited to:
Management of dictionary content at SigComp devices using static
dictionary based compression.
SDMP features are following:
* Byte based protocol
* Content can be manipulated from centralized element CoC .
* Requires SDMP support at CoC and SigComp device
* Independent of content format
* Supports retransmition of protocol messages
SDMP provides following advantages
1. Easier maintenance of content at devices in the network.
2. Reduces the compression errors due to unsysnchronized dictionary
between CoC and SigComp device and helps in improving call setup
time.
3. Independent of static dictionary format
2. TERMINOLOGY
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in RFC 2119 [1] and indicate
requirement levels for the protocol.
Verma V. [Page 3]
Internet draft SDMP 1 Feb 2003
3. ABBREVIATIONS
CoC Content controller
SigComp Signalling Compression
SIP Session Initiation Protocol
SDP Session Description Protocol
SDMP Static Dictionary Manipulation Protocol
4. SDMP Achitecture overview
|---------| |----------| |------------|
| SIP UA | | | | |
| + | SDMP Command | | SDMP Command | |
| SigComp |<------------->| Content |<-------------->|SIP ENTITITY|
| Devices | |Controller| |(PROXY, |
| | | (CoC) | | REGISTER, |
| | | | | REDIRECT, |
| | |----------| | UA) |
| | | |
| | | |
| | | |
| | SIP Messages | |
| |<----------------------------------------->| |
| | | |
| | | |
|---------| |------------|
Diagram 1 Interaction between CoC and SigComp enabled devices
Verma V. [Page 4]
Internet draft SDMP 1 Feb 2003
|----------------------------------------|
| APPLICATION LAYER |
|----------------------------------------|
| SDMP |
|----------------------------------------|
| TRANSPORT LAYER |
|----------------------------------------|
| IP LAYER |
|----------------------------------------|
| PHYSICAL LAYER |
|----------------------------------------|
Diagram 2 Layered Diagram Showing SDMP layer
5. SDMP functionalities
5.1 Functionalities of device
5.1.1 Mandatory functionalities
* creation,deletion and updation of content using SDMP
* support TCP and UDP as transport layer protocols
* Support retransmition of SDMP messages
5.1.2 Optional functionalities
* Verfication of security credentials before executing operation
5.2 Functionalities of CoC
Content controller(CoC) is logical entity which synchronizes content
at all devices in the network. CoC identifies content based upon
unique identifier and manages the content based upon this id known
as content id. However, policy to generate and assign an identifier
to content is out of scope of this document. CoC can co-exist with
other SIP entities like proxy,registrar, redirect server etc. CoC may
share content with other CoC(s). However, mechanism of content sharing
with other CoC(s) is out of scope of this document.
5.2.1 Mandatory functionalities
* Creation of content at device in the network
* Content synchronization,deletion at all devices in the network
* Overwriting old content with new one
* Support TCP and UDP as transport layer protocols
Verma V. [Page 5]
Internet draft SDMP 1 Feb 2003
5.2.2 Optional functionalities
* Verification of security credentials for SDMP commands sent by
devices
* Support retransmition of SDMP messages
* Grant access rights to devices for managing content
6. SDMP Command
6.1 SDMP Command Format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| General SDMP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDMP Command specific Header |
| (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Diagram 3. SDMP Command Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | v | cmd code | seq number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| content identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max content size | Num of commands |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CT| TT | R | Reason | content-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Diagram 4. General SDMP Header
where v = SDMP version,
CT = content -type
TT = Transport type,
R = Reserved for future use
Verma V. [Page 6]
Internet draft SDMP 1 Feb 2003
6.2 SDMP Fields
6.2.1 Type
Type is 5 bit field indicates message header type for SDMP commands,
it must be set to 11110.
6.2.2 Version
Version field indicates SDMP version used. This field must be set to
0, indicating SDMP version 0.
6.2.3 Command code
Command code is 8 bit integer indicates SDMP command issued .
Following are SDMP command values
|--------------------------|
| SDMP Command | Value |
|--------------------------|
| INVALID CMD | 0 |
| RESPONSE | 1 |
| CREATE | 2 |
| DESTROY | 3 |
| SYNCHRONIZE | 4 |
| OVERWRITE | 5 |
|--------------------------|
6.2.4 command-id
Command id identifies SDMP command .Command-id is unique 32 bit
integer.Policy to generate and manage command id is out of scope of
this document.SDMP command response must contain same command-id as
request .
6.2.5 content-id
Content id uniquely identifies content at CoC .SDMP command may
contain content id on which operation needs to be performed.
Content-id is 32 bit integer.SigComp device may send a command to CoC
specifying content id as 0,in this case CoC will load default content
to device.Policy of generation and managing of content id is out of
scope of this document.
6.2.6 content-length
Content length is 16 bit integer which indicates message size
excluding SDMP general command header.
Verma V. [Page 7]
Internet draft SDMP 1 Feb 2003
6.2.7 Destination, source identifier
These are 32 bit integer identifies destinatination,source of command.
For example, if command issued from CoC to device then source id will
be CoC id and destination id will be the device id.
6.2.8 Maximum content size
Maximum content size indicates the size of content to be loaded .This
field must be set to content size in first command but may be zero in
subsequent commands which . Device checks for necessary resources available to
store content and then sends back either SUCCESS or "insufficient
resources".
6.2.9 Number of commands
This field indicates number of commands device should expect from CoC
before device assume operation completed. CoC will indicated this
parameter in initial command to device. Device may override this
value based on its data receiving capability,MTU limitations etc
and indicate new value in response message.
6.2.10 Reason
Reason is 8 bit field .It is relevant only when command code is set
to 1 i.e SDMP response.This field contains detailed information about
SDMP response (refer to section 7 for details).
6.2.11 Sequence number
Content loading,updation to device may take more than one SDMP command
because of MTU limitations of network .In this situation content will
be divided into serveral SDMP commands with same command code,
content-id but incrementing sequence number indicating continuation
of previous SDMP command.
6.2.12 Transport type
Transport type is 3 bit field .It indicates transport layer protocol
used for sending SDMP command SDMP response should use same transport
layer protocol as SDMP command .Following are the transport type
values used in SDMP protocol header.
|----------------------------|
| Transport type | value |
|------------------|---------|
| UDP | 0 |
| TCP | 1 |
| SCTP | 2 |
|----------------------------|
Verma V. [Page 8]
Internet draft SDMP 1 Feb 2003
6.3 SDMP Command type
6.3.1 CREATE
Create commmand creates the content on device. This command can be
sent by CoC to device or from device to CoC. Multiple CREATE
commands may be needed to load single content because of MTU
limitation or device's data receiving capability.CREATE command can
be issued from device to CoC. CoC may issue this command at the
time of device startup. Device may issue this command in case its
local copy of content gets currupted due to power failure etc. or
device wants to change the content. If issued from device, content id
may be set to zero.Response from CoC will contain a valid content id
that must be remembered by device. In this situation CoC will load
default content to the device. Device may also request particular
content by mentioning valid content id .Reponse to this request may
be success or content not found.Criteria to choose default content
among various available content at CoC is out of scope of this
document.
6.3.2 DESTROY
DESTROY command will delete the content present on device. This
command can only be issued by CoC to device .Device is not allowed to
delete content at CoC. DELETE command must contain a valid content id
available on device.No additional command specific header is required
for DESTROY command Response to command can be success or content not
found. If content id is set to all 1's means all the content available
at device must be deleted.
6.3.3 SYNCHRONIZE
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source offset | Destination offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Diagram 6. SYNCHRONIZE COMMAND HEADER
SYNCHRONIZE command may be issued from CoC to device.This command can
also be issued by device to CoC .This command will be issued by CoC
in case content has been modified at CoC and CoC wants all registered
devices to synchronize with the change.Changed content can be
conveyed by mentioning src ,dest offset and data changed from src
offset to dest offset of content. Response to this command will be
Verma V. [Page 9]
Internet draft SDMP 1 Feb 2003
either "success" or "Invalid offset" from device. Device may also
request synchronization of part of content by sending SYNCHRONIZE
command to CoC mentioning source,destination offset.If response is
SUCCESS then CoC will invoke SYNCHRONIZE operation for mentioned
content-id from source to destination offset.
6.3.4 OVERWRITE
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| new content id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max size of new content | Num of commands to be issued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Diagram 7. OVERWRITE COMMAND
OVERWRITE command overwrites the content with new ones. This command
combines the deletion of old content and uploading of new content
into one command.This command will be issued by CoC to device but not
from device to CoC.Security credentials may be supplied by CoC.
Response to this command may be success, creadential required or
invalid content.
7 SDMP RESPONSE
SDMP commands may be issued by CoC, SigComp enabled device or any SIP
entity which supports SDMP .Receiver of SDMP command must issue
reponse to command with same command id ,content id,seq identifier,
command src id,command dest id and command code set to 1 with valid
value in reason field of general SDMP header.Following are the reason
codes for SDMP responses.
|------------------------------------------------|
| Reason code | Reason phrase |
|------------------------------------------------|
| 1 | Success |
| 2 | Undefined error |
| 3 | Invalid content identifier |
| 4 | Insufficient resource |
| 5 | Invalid input |
| 6 | Invalid extension |
| 7 | Invalid offset |
| 8 | Set max message size |
| 9 | Security credentials required |
| 10 | Invalid security credentials |
|------------------------------------------------|
Verma V. [Page 10]
Internet draft SDMP 1 Feb 2003
8. Transport layer considerations
SDMP command can be transmitted over UDP or TCP .Criteria to choose
reliable or unreliable delievery is out of scope of this document.
SDMP response must use same transport layer protocol as its command.
9 Retransmition of SDMP Commands
Retransmitions of SDMP commands must be supported at CoC and device.
Retransmitted SDMP message(command or response) must contain same
parameters as originally transmitted message .Default timer value
for SDMP messages should be 500 milli-second.However, timer values
can be changed based upon round trip time of network.
10. SIGNALLING EXAMPLES
10.1 Content creation(invoked by CoC)
Device CoC
| |
| CREATE(1) |
|<---------------------------------|
| |
| SUCCESS(1) |
|--------------------------------->|
| |
| CREATE(2) |
|<---------------------------------|
| SUCCESS(2) |
|--------------------------------->|
| |
| CREATE (3) |
|<---------------------------------|
| |
| CREATE(3) |
|<---------------------------------|
| |
| SUCCESS(3) |
|--------------------------------->|
| |
| |
Diagram 8. Content creation (invoked by CoC)
In the above example content creation is invoked by CoC by sending
CREATE command to device with following parameters
Verma V. [Page 11]
Internet draft SDMP 1 Feb 2003
CoC->Device
Command code = 2
sequence number = 1
from = some id
to = some device id
command id = some_random_number
transport type = 0
max content size = 3000
Number of commands to wait = 3
device will check for necessary resources and send back SUCCESS to
CoC with following parameters
Device->CoC
Command code = 1
sequence number = 1
command id = same as command
Reason = success
same for sequence number =2
CREATE with sequence number = 3 lost in the network so CoC
retransmitted the message and received SUCCESS from device
10.2 Content creation(invoked by device)
Device CoC
| |
| CREATE |
|--------------------------------->|
| SUCCESS |
|<---------------------------------|
| |
| CREATE(1) |
|<---------------------------------|
| SUCCESSS |
|--------------------------------->|
| |
| CREATE(2) |
|<---------------------------------|
| SUCCESS |
|--------------------------------->|
| |
Diagram 9. Content creation (invoked by device)
Verma V. [Page 12]
Internet draft SDMP 1 Feb 2003
In the above example device requests content creation from CoC by
sending CREATE command with following parameters
msg header type = 30(11110 in binary)
sequence number = 0
Command code = 2
Command id = some command id
content id = 0
from= some device id
to= some CoC id
transport type = 0
After receiving CREATE command CoC may verify device's security
credentials and after successfull verification sends back SUCCESS
response with following parameters
msg header type = 30
sequence number = 0
command code = 1
Command id = same as previous request
content id = default content id
from = some device id
to= some CoC id
transport type = 0
After receiving successfull response from CoC,device will store content
id mentioned in response.After sending response CoC will invoke content
loading on to device with same procedure as in section 10.1
11. SECURITY CONSIDERATIONS
This DOCUMENT does not introduce any known additional security risk.
12. REFRENCES
12.1 NORMATIVE REFERENCES
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[SIGCOMP] Price R., Bormann, C., Christoffersson, J., Hannu, H.,
Liu, Z. and J. Rosenberg, "Signaling Compression
(SigComp)", RFC 3320, January 2003.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Verma V. [Page 13]
Internet draft SDMP 1 Feb 2003
12.2 INFORMATIVE REFERENCES
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
13 CONTACT
Vishal Verma
Sonim Technologies
49, Race Course Road
2nd Floor ,Khaniza Bhavan,
Bangalore-560001
Karnataka,INDIA
Mobile: +91- 9845347841
Office: +91-080-2384192 ext 220
Home : +91-080-5251169
This Internet-Draft expires August 1st, 2003.
Verma V. [Page 14]
Internet draft SDMP 1 Feb 2003