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